GitHub Security Integration

Connecting Uleska to GitHub Actions Pipelines


Adding Uleska security testing into your GitHub Actions pipelines and scaling it across all of your teams is easy with the following steps.


Step 1: Choose which projects to test

First of all, choose a project into your Uleska account to automate testing for from GitHub. This can be hooked to your current projects, or tied to a few sandbox repos while your trying things out (see our page on sandbox testing you can quickly set up).

Choose your application and version with the relevant GIT repo, container image:tag, or dynamic URL, and the set of testing tools you want to run.

Then grab an authentication token for your account.  Copy this token and we'll use it in step 2.


Step 2: add the uleska cli to your github actions yaml


GitHub runs it's CI pipelines through GitHub Actions and you can add the Uleska CLI command into your YAML to run and report on all the security tools you have configured in Uleska.

First of all, add the Uleska auth token to your GitHub Actions secret variables as in the GitHub Actions documentation.  In our steps below we've used the variable name '$ULESKA_TOKEN' to retrieve this auth token in the YAML.

As mentioned, you can use the Uleska CLI to invoke Uleska from your GitHub Action pipeline, and this in turns runs and reports on all of the security tools you've configured in your ToolKit.

In Step 1 you will have some applications and projects, now we can reference these to be tested.  Go to the Uleska UI and grab the application and version name you are using (note these can also be retrieved via our API and CLI):


Depending on the toolkit (/version) of security testing tools you want to run, you can now add the Uleska template call into your project YAML files to specify where and when to run security:

Let's add the Uleska CLI call into our YAML to run the testing toolkit for your application and version.   Go to your YAML action under .github/workflows and add the following code where you want to run your testing (note: be sure to arrange the spacing to be relevant for your YAML): 

    # Run security testing
    - name: Run Uleska automation

        ULESKA_TOKEN: $
      run: |
        python3 -m pip install uleska-automate
        uleska-automate --uleska_host
--application_name appName --version_name versionName --token $ULESKA_TOKEN --test_and_results --toolkit_name "toolkitName"--fail_if_CVSS_over 8


Note: The above uleska-automate command should all be on one line.  It is broken up here for display purposes.

The Uleska CLI uses Python3 to run, and this command lets us specify how our pipelines are going to run security testing:

  • appName and versionName are given by each of your project teams to indicate the application and security toolkit to run.
  • is the hostname to use if you're using the Uleska SaaS, or replace with your  Uleska instance.
  • scanType of 'test_and_compare' runs the suite of security tools in the toolkit and highlights differences from the last scan (new issues or fixed issues).  See the CLI documentation for more details.
  • toolKitName is the security pattern of tools and configuration you wish to test with.
  • fail_if_CVSS_over is some optional risk, quantity, CVSS, and other thresholds you can set to 'break-the-build' depending on the issues returned by the toolkit.  Again see the CLI documentation for more details.

Note this command runs testing against the existing configuration.  If you want to use the Uleska CLI to dynamically update your repos, URLs, etc, based on what's running through the pipeline, then you can modify this template.


STEP 3: see the results of all your tests in one place


Now when you run your GitHub Actions pipelines, the security testing ToolKit setup in Uleska is run every time, and the results are compared with the last scan, or overall.  The output can be view in the CI/CD output, as well as in Uleska.

github output


This not only gives you great visibility of the existing and new issues being returned by the security tools (well, the one that haven't been marked as duplicates or false positives within Uleska), but you also get automated control on release go/no-go that goes way beyond simple HIGH/MEDIUM/LOW.

Here you can see the new issues found in this latest scan run, and see the build was stopped because one of the new issues was too high a risk.  Remember all of these issues can be seen and triaged in the Uleska Platform.


STEP 4: Change your security testing without affecting your CI/cd pipeline yaml


Now you have the Uleska CLI hook into your project YAML, that's all you will need to change on your YAML files.  Now if you want to change or add new security tools, modify profiles, etc, you can do that all from within the Uleska UI, giving you more flexibility around security testing, without constantly needing to update CI/CD code.