Connecting Uleska to Azure DevOps CI/CD Pipelines

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

Step 1: Choose which projects to test

First of all, choose a project into your Uleska account to automate testing for from ADO  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: Create an ADO template

Azure DevOps allows you to create templates so you can re-use jobs and steps across all your projects and teams.  This is great for security testing with Uleska because it allows your teams to add all the security testing into their YAML files with just a few lines of code.

First of all, add the Uleska auth token to your ADO secret variables as in the Azure DevOps documentation.  In our steps below we've used the variable name 'ULESKA-TOKEN' to retrieve this auth token in the template.

Let's create a template that will use the Uleska CLI to call the testing toolkit for your application and version.  Create a 'uleska-template.yaml' file in your relevant template directory:

parameters:
  appName: ''
  versionName: ''
  uleskaHost: 'https://cloud.uleska.com/'
  scanType: '--test_and_compare'
  maxIssueRisk: 10000
  maxOverallRisk: 780000

steps:
# Run Uleska Security testing
- task: UsePythonVersion@0
  inputs:
    versionSpec: '3.x'
    addToPath: true

- script: |
    python3 -m pip install requests uleska-automate
    uleska-automate --uleska_host ${{parameters.uleskaHost}} --application_name ${{parameters.appName}} --version_name ${{parameters.versionName}} --token $(ULESKA-TOKEN) ${{parameters.scanType}} --fail_if_issue_risk_over ${{parameters.maxIssueRisk}} --fail_if_risk_over ${{parameters.maxOverallRisk}}
    displayName: 'Uleska Security testing'

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 template 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 (see Step 3).
• uleskaHost is the hostname where your Uleska instance is running, either in the cloud, or on premise.
• 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.
• maxIssueRisk and maxOverallRisk are some of the 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 template 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: Call Uleska from your project yaml

Now each of your teams can use the Uleska ADO template to call the suite of security testing tools setup for their projects.

In Step 1 you will have created 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 specific where and when to run security:

    # Run Uleska Source Code Analysis testing

    - template: uleska-template.yaml

      parameters:

        appName: '$(appName)'

        versionName: 'SAST'

For example, you'd likely run source code security testing tools (SAST) after the source code has compiled, or Container security tools after the Dockerfile or image has been updated.  Your dynamic testing would be in staging, and Cloud/Infrastructure testing at deployment.

see the results of all your tests in one place

Now when you run your pipelines, the security testing suite setup in Uleska is run every time, and the results are compared with the last scan, or overall.

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