Integrating Invicti Enterprise with Azure Pipelines

Azure DevOps is a web-based DevOps manager that provides CI/CD pipeline features called Azure Pipelines.

You can integrate Invicti Enterprise with Azure Pipelines using cURL or PowerShell scripts generated by our Integration Script Generator, in order to enable our advanced integration functionality.

There are two scenarios to integrate Invicti Enterprise with Azure Pipelines:

1. Using the Invicti Enterprise Extension for Azure DevOps
2. Generating and using Invicti Enterprise’s Azure Integration Scripts

Prerequisites

• Getting the User ID and Token from Invicti Enterprise

How to get the User ID and Token

1. Log in to Invicti Enterprise.
2. Select your name in the upper right-hand corner, then API Settings.

3. On the API Settings page, enter your password.
4. Copy the User ID and Token information, as you need them for integration.

Scenario 1. Using the Invicti Enterprise Extension for Azure DevOps

Step 1. Deploy the Invicti Enterprise Extension for Azure DevOps into your organization

1. Log in to Invicti Enterprise.
2. From the main menu, select Integrations > New Integration.
3. From the Continuous Integration Systems, select Azure Pipelines.
4. From the Use Extension tab, select View Extension. This takes you to the Visual Studio Marketplace.

5. On the Visual Studio page, select Get it free.

6. From the Select an Azure DevOps organization drop-down, select your organization, then Install.

Azure DevOps shows you the success message. Select Proceed to the organization to go to your project.

Step 2. Create a Service Connection for Invicti Enterprise

How to create a Service Connection for Invicti Enterprise

1. Log in to your Azure DevOps account.
2. Select the project you want to create the service connection.
3. From the sidebar, select Project Settings.
4. Select Pipelines > Service connections.

5. From the Service connections page, select New service connection, then the Invicti Enterprise service type.
6. Select Next.
7. In the New Invicti Enterprise service connection panel, do the following:
   • Into the User ID field, enter the User ID that you retrieved in the How to get the User ID and API Token step.
   • Into the Token field, enter the Token information that you retrieved in the How to get the User ID and API Token step.
   • Enter a friendly name for your new service connection
   • Select Save.

Step 3. Configure your pipeline

1. Log in to your Azure DevOps account.
2. Navigate to your project.
3. If you do not have any pipelines, do the following:
   • Select Create Pipeline.
   • Choose Azure Repos Git.
   • Select your project. (For this example, the project name is InvictiExample.)
   • Choose Starter pipeline.
   • Adjust the pool section to match your agent, then select Save.
   • Set your commit message, then select Save to commit this basic starter pipeline to your codebase.
4. Go to your list of pipelines, then select Options for the pipeline you wish to work with, then select Edit.

5. In the Task assistant panel, select Invicti Enterprise.
6. To configure the task, do the following:
   • Set the Invicti Enterprise Connection to your service connection
   • From the ScanTypes field, select your choice.
   • From the list of websites, select your website.
   • Select your Websites Scan Profile from the drop-down list (not visible if your ScanType is set to Full (With primary profile).
   • Set your preferred Build fail and scan stop settings
   • Set your preferred Report Settings.
   • Select Add. This will add a task definition section to your pipeline YML file. Move the task definition to the steps section; the final result should resemble the following:
   • Select Save to save your pipeline, and confirm the commit message by clicking the Save button again.
   • Select Run to start your pipeline

Scenario 2. Generating and using Invicti Enterprise’s Azure Integration Scripts

Azure Pipelines fields

This table lists and explains the Azure Pipelines fields on the New Azure Pipelines Integration page.

Invicti Enterprise uses cURL and PowerShell command-line tools to integrate with Azure Pipelines. In order to integrate with Invicti Enterprise, the Pipeline agent’s execution environment must support cURL or PowerShell.

How to generate Invicti Enterprise’s Azure Pipelines Integration Scripts

1. Log in to Invicti Enterprise.
2. From the main menu, go to Integrations > New Integration > Azure Pipelines.
3. Choose the Use Integration Script tab.
4. From the Integration Script Generator section, select the relevant Scan Settings:
   • From the Scan Type field, select an option.
   • From the Website drop-down, select a website.
   • From the Scan Profile drop-down, select a scan profile (this is not displayed if you select Full with Primary Profile as the Scan Type).
   • Enable the Stop the scan if the Build fails, if required.
   • Enable the Fail the Build if one of the selected scan severity is detected, if required. (For further information, see Using Build Fail in Azure Pipelines Project.)

Please note that the default settings do not enable the Stop the scan if the build fails or the Fail the build if one of the selected scan severity is detected options. This would limit the communication between Azure Pipelines and Invicti Enterprise to a one-way request, which simply triggers a scan to start, without monitoring any feedback from the scanning engine. 

You must enable one or both of the following 2 options to generate a script that will monitor the feedback from the scanner, so the pipeline can know if the build has failed if issues with high enough severity are identified.

5. In the PowerShell field, select Copy to copy the PowerShell script.
   • If you are using a Linux agent in your Azure DevOps Project, copy the script in the cURL field, and retain it for the next step.
   • If you are using a Windows agent in your Azure DevOps Project, copy the script in the PowerShell field, and retain it for the next step.

Step 2. Deploy the Integration Script into your Azure DevOps Pipeline

1. Log in to your Azure DevOps account.
2. Navigate to your project.
3. Go to your list of pipelines, then select Options for the pipeline you wish to work with, then select Edit.
4. Edit your pipeline step and add the integration script, similar to the following example:

5. Select Variables.
   • Set the USERID variable:
     • Into the Name field, enter USERID.
     • Into the Value field, enter the User ID that you retrieved in the How to get the User ID and API Token step.
     • Select OK.
   • Set the APITOKEN variable:
     • Into the Name field, enter APITOKEN.
     • Into the Value field, enter the Token that you retrieved in the How to get the User ID and API Token step.
     • Select OK.
   • Select Save to save your variables.
6. Select Save to save your pipeline.
7. Adjust your Commit message as necessary, then select Save.

This trigger a run of the pipeline, and therefore add an immediate scan request to Invicti Enterprise as shown in the following screenshot:

All future pipeline runs now also trigger a scan request to Invicti Enterprise.

Customizing your Integration Script

You may add extra steps or logic to your Integration Scripts by invoking custom or additional calls to the Invicti Enterprise API. For more detailed information about the Invicti Enterprise Cloud API, visit Invicti API Documentation.

Checking Pipeline Results

Build Fail Errors

Your pipeline summary page shows you when a build fails following an issue being detected by Invicti Enterprise via the Errors panel.

Scan Reports for Executed Pipelines

If you have enabled the generation of reports for completed scans, the scan report is visible in the Pipeline report in a customer tab titled Invicti Enterprise Scan Report:

Checking Scan Results

The Recent Scans page lists all scans performed. By default, the most recently triggered scan will show at the top of the list.

Examine the Scan Report

Select Report on the scan triggered by your Azure DevOps Pipeline to go to the scan summary.

The Scan Summary page displays a general overview of the issues in your web application. 

Using Build Fail in Azure Pipelines Project

It is possible to configure a failure in the Azure Pipelines build to stop the scan when a vulnerability severity is detected.

Build Fail Logic

The build fail parameters operates in the AND logic. To fail a build, all selected parameters have to be met. For instance, if you select Critical from the severity drop-down and select the Confirmed checkbox, the build fails only if these two conditions are met.

This can be configured using the Severity, Confirmed, False Positive, and Accepted Risk parameters.

1. Scan Severity: With this option, you choose which severity will fail this build when found in a related scan. If you choose “DoNotFail”, the detected vulnerability does not affect your Azure build. The options for Scan Severity are: DoNotFail, Critical, High or above, Medium or above, Low or above, Best Practice or above.
2. Confirmed: With this option, you choose to fail this build when a vulnerability found in a related scan is confirmed.
   For example, if you choose the Medium or above option from the Scan Severity drop-down and select the Is Confirmed checkbox, the build fails only if the vulnerability has medium or higher severity and that vulnerability is confirmed. Otherwise, the build continues.
3. False Positive: With this option, you choose not to fail this Azure build when the scan identifies a vulnerability set as a False Positive.
   For example, if you choose the Medium or above option from the Scan Severity drop-down and select the False Positive checkbox, the build will not fail if the vulnerability has medium or higher severity and that vulnerability is false positive. Otherwise, the build fails.
4. Accepted Risk: With this option, you choose not to fail this Azure build when the scan identifies a vulnerability set as an Accepted Risk.
   For example, if you choose the Medium or above option from the Scan Severity drop-down and select the Accepted Risk checkbox, the build will not fail if the vulnerability has medium or higher severity and that vulnerability is accepted risk. Otherwise, the build fails.