Skip to main content

Azure DevOps Extension

Use the Veracode Azure DevOps Extension to add security scanning to build or release pipelines. The extension includes the following tasks:

  • Veracode Upload and Scan task that uploads your application code for Static Analysis and downloads the scan results.
  • Veracode Flaw Importer task that imports the results from Static Analysis, Dynamic Analysis, or SCA scans of the same application code into Azure DevOps as work items.

Supported versions​

Veracode has tested the following versions (if listed), but the integration might work with other versions.

  • Azure DevOps (Cloud)
  • The Upload and Scan task supports Azure DevOps Server 2019–2022
  • The Flaw Importer task supports Azure DevOps Server 2019–2020

Supported libraries​

Veracode has tested the following versions, but the integration might work with other versions.

Java 8 and 11

Prerequisites​

Before you begin, ensure you have:

Install the Azure DevOps Extension​

Install the Veracode Azure DevOps Extension from the Microsoft Visual Studio Marketplace.

To complete this task:

  1. Go to the Visual Studio Marketplace.
  2. Search for veracode.
  3. In the search results, select the link for the Azure DevOps extension.
  4. Follow the instructions to download and install the extension.

After you install the extension, for Azure DevOps Services, the extension can update to the latest version automatically. For on-premise Azure DevOps Server, you must update the extension manually.

Check your extension version​

You can check the version of the Veracode Azure DevOps Extension installed on your on-premise Azure DevOps Server to determine whether to update the extension manually. For Azure DevOps Services, which are hosted in the cloud, the extension can update to the latest version automatically.

Before you begin:

You have installed the Veracode Azure DevOps Extension on your on-premise Azure DevOps Server.

To complete this task:

  1. Go to the Visual Studio Marketplace.
  2. Select Azure DevOps from the top of the page.
  3. Search for veracode.
  4. In the search results, select the link for the Veracode Azure DevOps Extension.
  5. Under More Info, in the Version field, make a note of the current extension version.
  6. Sign in to your on-premise Azure DevOps Server.
  7. Go to the Extensions page to view a list of the installed extensions.
  8. Locate and select the Veracode extension. The Extensions details page shows the version of the installed extension.
  9. Compare the installed version to the latest version available on the Visual Studio Marketplace.

Create a service connection​

You can create a service connection in Azure DevOps for the Veracode Azure DevOps Extension to access Veracode.

Before you begin:

Ensure you have:

To complete this task:

  1. In your Azure DevOps project, go to the Project Settings page.
  2. Select Service connections > Create service connection.
  3. In the New service connection window, select Veracode Platform > Next.
  4. In the New Veracode Platform service connection window, enter your Veracode API credentials and a name for the service connection.
  5. Select Save to save the service connection.

Hide a proxy password​

You can add a variable in Azure DevOps to hide a proxy password and prevent that password from being shown in console logs of build or release pipelines.

To complete this task:

  1. In your Azure DevOps, go to the Build or Release window and select the Variables tab.
  2. Select + Add to add a new variable.
  3. Enter the variable name in the Name field and enter the proxy password in the Value field.
  4. To hide the password, select the lock icon , so that the icon changes to locked.
  5. For the Veracode Flaw Importer task, in the Proxy Settings field, add the password as a variable. For example, if the variable name is pwd, enter $(pwd).
  6. For the Veracode Upload and Scan task, in the Optional Arguments field, enter the password as a variable. For example, if the variable name is pwd, enter $(pwd).

The proxy password is now hidden from the console logs when you run the pipeline.

Add scanning to build pipelines​

Add the Upload and Scan task to integrate Veracode Static Analysis into your Azure DevOps build pipelines.

Before you begin:

Ensure you have:

  • Generated Veracode API credentials. If your credentials contain variables, you must start each variable with a $ and wrap the variable value in parentheses. For example, you enter the id variable as $(Id).

  • The extension uses the variable names VERACODE_API_KEY_ID and VERACODE_API_KEY_SECRET for the API credentials. If you use custom variables in your pipelines, ensure that none of your variable names conflict with these variable names for the API credentials.

  • Before uploading an application, you must package it to include the required debug symbols, as described in the packaging requirements.

  • If you want to upload multiple artifacts for scanning, you have prepared one or more ZIP archives:

    a. Add the artifacts to one or more ZIP archives.

    b. Ensure the ZIP archives are in the same upload file path location.

    c. Prepare the ZIP archives for uploading to Veracode using a separate build step or build steps in your pipeline.

If you have an ASP.NET application, see the configuration instructions. The following .NET project includes an example precompilation step: https://github.com/veracode/verademo-dotnet/blob/main/azure-pipelines.yml.

To complete this task:

  1. In your Azure DevOps project, select the Tasks tab and navigate to your build definition.

  2. Select Add a task....

  3. Search the list for the Veracode Upload and Scan task. Then, select Add to add it to the build definition.

  4. Select the Veracode Upload and scan task. The Veracode Upload and Scan window opens.

  5. For Connection Details, select a connection source for connecting to Veracode:

    • Service Connection: select an existing service connection that uses your Veracode API credentials or select New to create a new service connection. For a new connection, in the New service connection window, by default, the Server URL field is populated with the URL for accessing Veracode. Enter your Veracode API credentials, a name for the service connection and, then, click Save. The new connection is selected in the Select Service Connection dropdown menu.
    • Credentials: enter your Veracode API credentials.

  6. For Veracode Scan Settings, enter the name of the associated application profile (case-sensitive), a unique scan name, and the filepath to the application artifact or the folder containing the artifacts to upload to Veracode.

    For a .NET application, if you have additional published projects from a solution, include them in the archive to upload and analyze. Add any JavaScript files to a separate ZIP archive according to the packaging instructions in the packaging requirements. Include only the file types for languages and platforms that Veracode can scan in a ZIP archive to improve uploading and scan speed. See the Microsoft Archive Files task.

    If this is not an existing Veracode application, select the Create Application Profile checkbox in the Advanced Scan Settings section to have Veracode create an application profile.

  7. For Advanced Scan Settings:

    • If you are using a development sandbox, enter a sandbox name or select Create Sandbox to create one.
    • In the Optional Arguments field, enter any optional parameters to apply to the Upload and Scan action. For example, you can use the optional parameters to include and exclude files during the scan.

    The following example specifies to:

    • Identify the scan as high importance.
    • Include all DLL files.
    • Scan in a sandbox named mysandbox, which Veracode creates if the sandbox does not exist.
    • Delete a scan with a status of incomplete, no modules defined, failed, or cancelled.
    -criticality high -include *.dll *.exe -createsandbox true -sandboxname mysandbox -deleteIncompleteScan 1
    note

    Do not enclose any of the values in single or double quotations.

    You can hide a proxy password during the Upload and Scan action.

    If the application profile does not exist, select the Create Application Profile checkbox to create it. You can select the Fail build if Upload and Scan build step fails checkbox to prevent the build from continuing if the Upload and Scan build step fails.

  8. For Veracode Scan Results: select the Import Results upon Scan Completion checkbox to import the scan results. You can select the option under it to stop the build if the scan results indicate that the application has failed your security policy.

    Selecting either checkbox reserves an assigned build agent to wait until the scan has completed successfully and the scan results are available. With one or both checkboxes selected, you can enter the build agent wait time, in minutes, for failing the build if no scan results are available. The value range is 30 to 1440 (24 hours) and the default is 360 (6 hours). If you enter a value outside this range, the build fails.

    If neither checkbox is selected, the build agent uploads the binaries to Veracode and continues to the next build task in the task list.

  9. Optionally, to add debugging to your pipeline, add a new variable and enter these values in the New variable window:

    • Name: system.debug
    • Value: true

  10. If you want to use the Veracode Azure DevOps flaw import feature in your build definition, configure the additional related build variables.

  11. To view the scan results, in your build definition, select the Veracode Scan Summary tab.

Add scanning to build pipelines using YAML​

Use YAML to add the Upload and Scan task and integrate Veracode Static Analysis into your Azure DevOps build pipelines.

Before you begin:

  • Before uploading an application, you must package it to include the required debug symbols, as described in the packaging requirements.

  • Generated Veracode API credentials. If your credentials contain variables, you must start each variable with a $ and wrap the variable value in parentheses. For example, you enter the id variable as $(Id).

  • The extension uses the variable names VERACODE_API_KEY_ID and VERACODE_API_KEY_SECRET for the API credentials. If you use custom variables in your pipelines, ensure that none of your variable names conflict with these variable names for the API credentials.

  • If you want to upload multiple artifacts for scanning, you have prepared one or more ZIP archives:

    a. Add the artifacts to one or more ZIP archives.

    b. Ensure the ZIP archives are in the same upload file path location.

    c. Prepare the ZIP archives for uploading to Veracode using a separate build step or build steps in your pipeline.

If you have an ASP.NET application, you can configure a pipeline for building and scanning ASP.NET applications.

To complete this task:

  1. In your Azure DevOps project, navigate to the YAML file for the pipeline in which to add the Veracode task.

  2. Select Show assistant.

  3. Search for veracode, then select the Veracode Upload and Scan task.

  4. In the Veracode Upload and Scan window, in the Connection Details section, select a connection source for connecting to Veracode:

    • Service Connection: select an existing service connection that uses your Veracode API credentials or create a new service connection.
    • Credentials: enter your Veracode API credentials.

  5. In the Veracode Scan Settings section, enter the name of the associated application profile, a unique scan name, and the filepath to either the application artifact or the folder containing the artifacts to upload to Veracode.

    For a .NET application, if you have additional published projects from a solution, include them in the archive to upload and analyze. Add any JavaScript files to a separate ZIP archive according to the packaging instructions in the packaging requirements. Include only the file types for languages and platforms that Veracode can scan in a ZIP archive to improve uploading and scan speed. See the Microsoft Archive Files task.

    If this is not an existing Veracode application, select the Create Application Profile checkbox in the Advanced Scan Settings section to have Veracode create an application profile.

    note

    Application names in Azure DevOps are case-sensitive.

  6. In the Advanced Scan Settings section, if you are using a development sandbox, enter a sandbox name or select Create Sandbox to create one.

    In the Optional Arguments field, enter any optional parameters to apply to the Upload and Scan action. For example, you can use the optional parameters to include and exclude files during the scan.

    The following example specifies to:

    • Include all DLL files.
    • Scan in a sandbox named mysandbox, which Veracode creates if the sandbox does not exist.
    • Delete a scan with a status of incomplete, no modules defined, failed, or canceled.
    -include *.dll -createsandbox true -sandboxname mysandbox -deleteIncompleteScan 1
    note

    Do not enclose any of the values in single or double quotations.

    You can hide a proxy password during the Upload and Scan action.

    If the application profile does not exist, select the Create Application Profile checkbox to create it. You can select the Fail build if Upload and Scan build step fails checkbox to prevent the build from continuing if the Upload and Scan build step fails.

  7. In the Veracode Scan Results section, select the Import Results upon Scan Completion checkbox to import the scan results. You can select the option under it to stop the build if the scan results indicate that the application has failed your security policy.

    Selecting either checkbox reserves an assigned build agent to wait until the scan has completed successfully and the scan results are available. With one or both checkboxes selected, you can enter the build agent wait time, in minutes, for failing the build if no scan results are available. The value range is 30 to 1440 (24 hours) and the default is 360 (6 hours). If you enter a value outside this range, the build fails.

    If neither checkbox is selected, the build agent uploads the binaries to Veracode and continues to the next build task in the task list.

  8. Select Add to add the Upload and Scan task to the YAML file in your build pipeline.

    This example shows a YAML file for building and scanning a .NET application. It specifies to access Veracode using a service connection. For more information, see Upload and Scan YAML properties.

    # .NET Desktop
    # Build and run tests for .NET Desktop or Windows classic desktop solutions.
    # Add steps that publish symbols, save build artifacts, and more:
    # https://docs.microsoft.com/azure/devops/pipelines/apps/windows/dot-net

    trigger:
    - master

    pool:
      vmImage: 'windows-latest'

    variables:
       solution: '**/*.sln'
       buildPlatform: 'Any CPU'
       buildConfiguration: 'Debug' # required as part of Veracode packaging for task: VSBuild@1
     
    steps:
    - task: NuGetToolInstaller@1
     
    - task: NuGetCommand@2
      inputs:
        restoreSolution: '$(solution)'
     
    - task: VSBuild@1
      inputs:
        solution: '$(solution)'
        platform: '$(buildPlatform)'
        configuration: '$(buildConfiguration)'
     
    - task: VSTest@2
      inputs:
        platform: '$(buildPlatform)'
        configuration: '$(buildConfiguration)'
     
    - task: DownloadPipelineArtifact@2
      inputs:
        patterns: '**/*.exe,**/*.dll,**/*.pdb' # ensures Veracode gets the PDB files for Static Analyisis
     
    # This task makes the pipeline build artifacts available in a known location for upload to Veracode
    - task: PublishPipelineArtifact@1
      inputs:
        targetPath: $(System.DefaultWorkingDirectory)/bin/Debug
        artifactName: Debug
         
    - task: Veracode@3
      inputs:
        ConnectionDetailsSelection: 'Service Connection' # access Veracode with service connection or Veracode API credentials
        AnalysisService: 'Veracode Service Account' # service connection name for accessing Veracode
        veracodeAppProfile: '$(system.teamProject)' # Veracode application profile to scan
        version: '$(build.buildNumber)' # name of the scan to run
        filepath: '$(System.DefaultWorkingDirectory)/bin/Debug' # filepath or folderpath of files to upload to Veracode
        optargs: '-criticality high -include *.dll -createsandbox true -sandboxname mysandbox -deleteIncompleteScan 1' # scan criticality is high, include DLL modules, exclude EXE modules, create sandbox mysandbox during scan, delete a scan with status of incomplete, no modules defined, failed, or cancelled 
        createSandBox: false # true to scan of new development sandbox
        createProfile: true # false to enforce using existing profiles
        failBuildIfUploadAndScanBuildStepFails: false # true to fail build if Upload and Scan task fails to start
        importResults: true # required to view Veracode results in Azure DevOps
        failBuildOnPolicyFail: false # true to fail the build if application fails policy
        maximumWaitTime: '360' # wait time, in minutes, to fail the build if no scan results available

  9. Optionally, to add debugging to your pipeline, add a new variable and enter these values in the New variable window:

    • Name: system.debug
    • Value: true

  10. To view the scan results, in your build definition, select the Veracode Scan Summary tab.

To use the Veracode Azure DevOps flaw import feature in your build definition, configure the additional related build variables.

Upload and Scan YAML properties​

The following table describes the properties and their values for adding the Veracode Upload and Scan task to an Azure DevOps build pipeline using YAML.

PropertyTypeDescription
ConnectionDetailsSelection
Required		StringOne of these methods for connecting to Veracode:
  • Service Connection to use an existing service connection that includes your Veracode API credentials. Include AnalysisService to specify a service connection name.
  • Credentials to enter your Veracode API credentials. Include apiId to enter your API ID and apiKey to enter your API key.
veracodeAppProfile
Required		StringName of the application profile. The name is case-sensitive.
version
Required		StringName of the scan. You can enter the $buildnumber or $projectname variables to dynamically bind the build number or project name to the scan name, instead of using a fixed scan name.
filepath
Required		StringFilepath to either an application artifact or a folder containing multiple artifacts to upload to Veracode.You can also upload multiple artifacts using one or more ZIP archives. To prepare the artifacts:
  1. Add the artifacts to one or more ZIP archives.
  2. Ensure the ZIP archives are in the same upload file path location.
  3. Prepare the ZIP archives for uploading to Veracode using a separate build step or build steps in your pipeline.
For a .NET application, if you have additional published projects from a solution, include them in the archive to upload and analyze. Add any JavaScript files to a separate ZIP archive according to the packaging instructions in the packaging requirements. Include only the file types for languages and platforms that Veracode can scan in a ZIP archive to improve uploading and scan speed. Microsoft provides this Archive Files task: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/archive-files?view=azure-devops.
AnalysisServiceStringIf you set ConnectionDetailsSelection to Endpoint, the name of the service connection for accessing Veracode.
If a service connection does not exist, you can create a new service connection.
apiIdStringIf you set ConnectionDetailsSelection to Credentials, your Veracode API ID.
apiKeyStringIf you set ConnectionDetailsSelection to Credentials, your Veracode API key.
sandboxNameStringFor development sandbox scans, the name of the sandbox in which to run the scan. If the sandbox does not exist, include createSandBox to create it with the specified name.
createSandBoxBooleanFor development sandbox scans, create a sandbox for the specified Veracode application. Set to true to create a sandbox. Set to false to not create a sandbox.
optargsStringAny optional parameters from the uploadandscan API to include in the scan. For example:

'-criticality high -include *.dll -exclude *.exe -createsandbox true -sandboxname mysandbox -deleteIncompleteScan 1'

Proxy example:

'-pport 8282 -phost abc.proxy.com -puser proxyuser -ppassword proxypassword'



NOTE:
Do not enclose any of the values in single or double quotations.
createProfileBooleanCreate a Veracode application profile, if one does not exist, for the specified application profile name. Set to true to create a profile. Set to false to not create a profile.
failBuildIfUploadAndScanBuildStepFailsBooleanFail the build if the Veracode Upload and Scan build step fails to start. Set to true to fail the build. Set to false to allow the build to continue.
importResultsBooleanImport scan results into Azure DevOps after the scan completes. Set to true to import results. Set to false to not import results. You can view the results on the Veracode Scan Summary tab.
failBuildOnPolicyFailBooleanFail the build if the scan results indicate that the application has failed your security policy. Set to true to fail the build. Set to false to not fail the build.
maximumWaitTimeIntegerBuild agent wait time, in minutes, to fail the build if no scan results are available. The value range is 30 to 1440 (24 hours) and the default is 360 (6 hours). If you enter a value outside this range, the build fails.

Build and scan ASP.NET applications​

You can configure the Veracode Azure DevOps Extension in Visual Studio to scan ASP.NET applications as part of your Azure DevOps build process.

Before you begin:

To complete this task:

  1. Open the ASP.NET application in Visual Studio.
  2. Add the veracode.pubxml file that contains Veracode-specific settings to the PublishProfiles folder.
  3. View the veracode.pubxml file to verify your configuration. Veracode uses the information in this file to generate the necessary artifacts for scanning an application.
  4. Check in the changes to your repository.
  5. In Azure DevOps, open your Azure DevOps project.
  6. Select the Build tab and navigate to your build definition.
  7. Select the Build solution task.
  8. In the MSBuild Arguments field, enter the path of your application PUBXML file. For example, /p:PublishProfile=veracode.pubxml
  9. Complete the Azure DevOps build configuration for Static Analysis.

Add scanning to release pipelines and import findings​

You can configure the Veracode Azure DevOps Extension to add the Veracode Upload and Scan task and the Veracode Flaw Importer task to a release pipeline in Azure DevOps.

To complete this task:

  1. In your Azure DevOps, select the Release tab.

  2. Create a new release and enter the definition name.

  3. On the Definition page, select the Environment tab and configure the Veracode Upload and Scan or Veracode Flaw Importer tasks. If you want to view a summary report of scan results, you must add the Veracode Upload and Scan task.

    note

    The build object is not available in the release pipeline. Therefore, if you intend to use the Veracode Upload and Scan task in the release pipeline, you must enter the scan name manually. If you do not enter it manually, the scan name variable does not convert to text and the build name appears as $(build.buildNumber).

  4. Save the definition and select Release > Create Release.

  5. On the Release tab, select the release you just created.

  6. For the Veracode Upload and Scan task, in the Environments section, select the environment that contains the task.

  7. From the Actions menu, select Deploy to start the build in the release pipeline.

After the scan is complete, in your build definition, you can select the Veracode Scan Summary tab to view the scan results.

Import findings into Azure DevOps​

You can add the Veracode Flaw Importer task to your Azure DevOps build pipelines. The task uses the Veracode Azure DevOps Extension to automatically import flaws and vulnerabilities as work items.

You can also use YAML to configure Azure DevOps pipelines for importing flaws.

Before you begin:

Before you can import flaws or vulnerabilities into Azure DevOps, you must meet these prerequisites:

  • Ensure these projects are in the same Azure DevOps organization:
    • The project to which the running release or build job belongs, where the Flaw Importer task is running
    • The project to which you want to import the flaws or vulnerabilities
  • You have installed the Veracode Azure DevOps Extension.
  • You have generated Veracode API credentials. If your credentials contain variables, you must start each variable with a $ and wrap the variable value in parentheses. For example, you enter the id variable as $(Id).
  • The Veracode Flaw Importer generates work items based on the Agile, Scrum, and CMMI process templates in Azure DevOps. You can customize the default fields in the process templates, such as changing the state names to match the names of your actual states and their transition values. When configuring the Flaw Importer you can specify the custom fields to add to work items when importing flaws or vulnerabilities. If you use custom process templates, and you also want to add custom fields to generated work items, before specifying the custom fields ensure you have configured the required predefined variables in your build or release configurations.
  • Ensured that all required Veracode IP addresses for the Veracode APIs and integrations are on the allowlist for your organization. The extension uses these addresses to authenticate with Veracode. To update your allowlist, you might need to contact your IT team.
  • If you are using customized work item types that contain required fields, you must do one or both of the following to ensure all flaws import successfully.
    • In each customized work item type, specify the default value for the required field. The required field must not be blank.
    • Select different work item types that do not contain required fields.

To complete this task:

  1. In your Azure DevOps project, go to your build definition.

  2. Add Veracode Flaw Importer as a build task.

  3. Select the Import flaws task to open the Veracode Flaw Importer window.

  4. In the Flaw Importer window, from the Connection Details section, select a connection source for connecting to Veracode:

    • Service Connection: select an existing service connection that uses your Veracode API credentials or select New to create a new service connection. For a new connection, in the New service connection window, by default, the Server URL is populated with the URL for accessing Veracode. Enter your Veracode API credentials, a name for the service connection and, then, click Save. The new connection is selected in the Select Service Connection dropdown menu.
    • Credentials: enter your Veracode API credentials. If you use variables for your credentials, you must start each variable with a $ and wrap the variable value in parentheses. For example, for a variable named id, enter $(Id).

  5. In the Flaw Source section, enter the application profile name (case-sensitive) and sandbox name, if applicable, for which you want to import flaws from Veracode. If you remediate SCA vulnerabilities in a sandbox, the integration can only close the corresponding work items after you promote the sandbox to a policy scan.

  6. In the Work Item Settings section, from the Scan Type dropdown menu, select the scan types from which to import flaws or vulnerabilities.

  7. From the Import dropdown menu, select the flaw type to import as work items:

    • All Flaws: includes mitigated and remediated flaws and vulnerabilities from all scans. During the import process, the extension changes the state of the work items for all mitigated and remediated flaws to resolved or closed. After you fix or remediate the flaw, during the next scan, its status changes to fixed or mitigated in the Detailed Report. During the next import, the related work items change to closed. This option imports all flaws without any restrictions.
    • All Unmitigated Flaws: includes flaws and vulnerabilities from all scans.
    • All Flaws Violating Policy: includes all open flaws and vulnerabilities from all scans that affect policy.
    • All Unmitigated Flaws Violating Policy: includes open flaws and vulnerabilities from all scans that affect policy. The default.

    When you generate new work items for imported flaws, the extension also imports mitigation and annotation comments. If you add comments to a previously imported flaw with work items, the extension does not import the new comments to work items during subsequent imports.

  8. From the Work Item Type dropdown menu, select the work item type to generate for all imported flaws.

    note

    The Scrum process template does not support the Issue work item type.

  9. In the Area Path field, enter the path to the area where you want to group the work items by team, product, or feature area. You can enter up to five levels in the path. To enter the area paths, use the format <project name>\<area 1>\<area 2>. The value in <project name> is the name of the project in the Build Pipeline or Release Pipeline task for which you want to import flaws.

  10. Optionally, select the Overwrite Area Path in Work Items on Import checkbox to replace the area path in new and existing work items with the value in the Area Path field. If you clear this checkbox, existing work items retain their current area path.

  11. In the Iteration Path field, enter the path to the area where you want to group work items into sprints, milestones, or other events or periods. Similar to the value in the Area Path field, use the format <project name>\<iteration 1>.

  12. In the Add Custom Tag field, enter a custom tag name to add user-defined tags to all work items that the current build generates.

  13. Optionally, to add useful information about imported findings as tags in work items, select one or more of the following options:

    • Add CVE as a Tag: for SCA scans, adds the CVE ID for the finding.
    • Add CWE as a Tag: adds the CWE ID for the finding.
    • Add Build ID as a Tag: adds the build number of the build that contains the finding.
    • Add Scan Name as a Tag: adds the name of the scan that found the finding.
    • Add Scan Type as a Tag: adds the scan type, such as Static or SCA, that found the finding.
    • Add Severity as a Tag: adds the severity of the finding.
    • Add Due Date as a Tag: For Static Analysis and Dynamic Analysis scans, adds the due date for your team to fix the finding.

  14. In the Flaw Import Limit section, enter the maximum number of flaws to import at one time. The default is 1000.

  15. For Custom Fields, if you are using customized process templates with custom fields, you can specify the custom fields to add to new, but not existing, work items. Enter key-value pairs to specify each field name and value. Add each key-value pair separated with a colon on a new line.

    For example, to add Agile-based custom fields for story points (3), priority (1), work estimate (4), and test system information (My Test System), add these values:

    <_field reference name_>.StoryPoints:3
    <_field reference name_>.Priority:1
    <_field reference name_>.OriginalEstimate:4
    <_field reference name_>.SystemInfo:My Test System

    For field reference name, ensure the field names match the field reference names in Azure and that all values are valid for a given field type. If there are any mismatch or validation errors, you can only see these errors in the console after importing flaws.

  16. In the Advanced Scan Settings section, configure these options:

    • Proxy Settings: if you use a proxy to access Veracode, enter the proxy settings. For example:

      -phost abc.com - pport 5252 -puser proxyuser -ppassword proxypassword
      note

      Do not enclose any of the values in single or double quotations.

    • Team Foundation Server Password: do not change this value from the default of $(password).

  17. Optionally, to add debugging to your pipeline, add a new variable and enter these values in the New variable window:

    • Name: system.debug
    • Value: true

  18. Select Save & queue to save your configurations and add the build to your queue.

To keep the status of imported findings in your ticketing system in sync with the status of the actual findings in the Veracode Platform, you must routinely run the integration.

After the Flaw Import task has completed successfully, the work items related to flaws or vulnerabilities in a given application appear in Azure DevOps. In Azure DevOps, you can search on the Work or Queries pages, for example, to find the work items you created.

Identify a field reference name​

  1. In Azure DevOps, select Organization settings.
  2. Under Boards, select Process.
  3. On the All processes page, on the Processes tab, select the relevant process template.
  4. On the Work item types tab, select the type of work items you want to create.
  5. Locate the custom field you want to configure.
  6. From the three-dot menu on the field, select Edit.
  7. In the Edit window, select Options.
  8. Make a note of the value you see after Field Reference Name: and any value you see in the Default value field.

Import findings using customized process templates​

You can use customized process templates to automatically import flaws and vulnerabilities as work items into Azure DevOps. In an Azure DevOps project, when you customize one or more objects in a process template, that template changes to a customized process template.

If you want to add custom fields to the generated work items, you must configure the predefined variables in this section before specifying the custom fields in the Veracode Flaw Importer.

Your customized process template can include names of work item types that the default process template does not support. For example, you can customize the default Scrum process template to include an Issue work item type.

To complete this task:

  1. In your Azure project, go to your build or release configuration, and configure the following predefined variables on the Variables tab.

    note

    The names of these predefined variables must match the variable names in your customized process templates.

    • enableCustomProcessTemplate: enter true to enable.

    • customWorkItemType: enter one of these work item types:

      • Agile
      • Bug
      • Epic
      • Feature
      • Issue
      • Task
      • Test Case

    • customPTActiveStatus: enter the state for in progress or active work.

    • customPTNewStatus: enter the state for new or proposed work.

    • customPTResolvedStatus: enter the state for resolved work.

    • customPTDesignStatus: enter the state for work in design or test.

    • customPTCloseStatus: enter the state for completed work.

    You configure these variables for the work item type (WIT) of which you are creating work items in your build or release configuration. The variables ensure that flaws import correctly if the status of a work item changes. See the Azure DevOps documentation for information on the work item states.

    For example, on the States tab, you might have a Bug work item with these state changes:

    • For Proposed: Introducing
    • For In Progress: Working
    • For Resolved: Fixed
    • For Completed: Closed

    In your build or release configuration, on the Variables tab, you configure these pipeline variables in the customized process template for the Bug work item:

    • enableCustomProcessTemplate: enter true
    • customWorkItemType: enter Bug
    • customPTActiveStatus: enter Working
    • customPTNewStatus: enter Introducing
    • customPTResolvedStatus: enter Fixed
    • customPTCloseStatus: enter Closed

  2. Optionally, to add debugging to your pipeline, add a new variable and enter these values in the New variable window:

    • Name: system.debug
    • Value: true

  3. Select Save & queue to save your configurations and add the build to your queue.

After the flaw import task has completed successfully, the work items related to flaws in a given application appear in Azure DevOps. In Azure DevOps, you can search on the Work or Queries pages, for example, to find the work items you created.

Next steps:

You can use a variable to prevent a password from appearing in a console log.

Import findings using YAML​

You can use YAML to add the Veracode Flaw Importer task to your Azure DevOps build pipelines. The task uses the Veracode Azure DevOps Extension to automatically import flaw and vulnerabilities as work items.

If you do not want to use YAML, you can use the standard interface.

Before you begin:

Before you can import flaws or vulnerabilities into Azure DevOps, you must meet these prerequisites:

  • Ensure these projects are in the same Azure DevOps organization:
    • The project to which the running release or build job belongs, where the Flaw Importer task is running
    • The project to which you want to import the flaws
  • You have installed the Veracode Azure DevOps Extension.
  • You have generated Veracode API credentials. If your credentials contain variables, you must start each variable with a $ and wrap the variable value in parentheses. For example, you enter the id variable as $(Id).
  • The Veracode Flaw Importer generates work items based on the Agile, Scrum, and CMMI process templates in Azure DevOps. You can customize the default fields in the process templates, such as changing the state names to match the names of your actual states and their transition values. When configuring the Flaw Importer you can specify the custom fields to add to work items when importing flaws. If you import flaws using custom process templates, and you also want to add custom fields to generated work items, before specifying the custom fields ensure you have configured the required predefined variables in your build or release configurations.
  • If you are using customized work item types that contain required fields, you must do one or both of the following to ensure all flaws import successfully.
    • In each customized work item type, specify the default value, or leave it blank, for the required field.
    • Select different work item types that do not contain required fields.

To complete this task:

  1. In your Azure DevOps project, navigate to the YAML file for the pipeline in which to add the Veracode task.

  2. Select Show assistant.

  3. Search for veracode. Then, select the Veracode Flaw Importer task.

  4. In the Flaw Importer window, from the Connection Details section, select a connection source for connecting to Veracode:

    • Service Connection: select an existing service connection that uses your Veracode API credentials or select New to create a new service connection. For a new connection, in the New service connection window, by default, the Server URL is populated with the URL for accessing Veracode. Enter your Veracode API credentials, a name for the service connection and, then, click Save. The new connection is selected in the Select Service Connection dropdown menu.
    • Credentials: enter your Veracode API credentials. If you use variables for your credentials, you must start each variable with a $ and wrap the variable value in parentheses. For example, for a variable named id, enter $(Id).

  5. In the Flaw Source section, enter the application name and sandbox name, if applicable, for which you want to import flaws from Veracode. If you remediate SCA vulnerabilities in a sandbox, the integration can only close the corresponding work items after you promote the sandbox to a policy scan.

  6. In the Work Item Settings section, from the Scan Type dropdown menu, select the scan types from which to import flaws.

  7. From the Import dropdown menu, select the flaw type to import as work items:

    • All Flaws: includes mitigated and remediated flaws and vulnerabilities from all scans. During the import process, the extension changes the state of the work items for all mitigated and remediated findings to resolved or closed. After you fix or remediate the finding, during the next scan, its status changes to fixed or mitigated in the Detailed Report. During the next import, the related work items change to closed. This option imports all findings without any restrictions.
    • All Unmitigated Flaws: includes flaws and vulnerabilities from all scans.
    • All Flaws Violating Policy: includes all open flaws and vulnerabilities from all scans that affect policy.
    • All Unmitigated Flaws Violating Policy: includes open flaws and vulnerabilities from all scans that affect policy. The default.

    When generating new work items for imported findings, the extension also imports mitigation and annotation comments. If you add comments to a previously imported finding with work items, the extension does not import the new comments to work items during subsequent imports.

  8. From the Work Item Type dropdown menu, select the work item type to generate for all imported flaws.

    note

    The Scrum process template does not support the Issue work item type.

  9. In the Area Path field, enter the path to the area where you want to group the work items by team, product, or feature area. You can enter up to five levels in the path. To enter the area paths, use the format <project name>\<area 1>\<area 2>. The value in <project name> is the name of the project in the Build Pipeline or Release Pipeline task for which you want to import flaws.

  10. Optionally, select the Overwrite Area Path in Work Items on Import checkbox to replace the area path in new and existing work items with the value in the Area Path field. If you clear this checkbox, existing work items retain their current area path.

  11. In the Iteration Path field, enter the path to the area where you want to group work items into sprints, milestones, or other events or periods. Similar to the value in the Area Path field, use the format <project name>\<iteration 1>.

  12. In the Add Custom Tag field, enter a custom tag name to add user-defined tags to all work items generated from current build.

  13. Select the Add CWE as a Tag checkbox to add a tag with the CWE number to all the work items that the current build generates.

  14. Select the Add Build ID as a Tag checkbox to add a tag to each work item showing the build number of the build that contains the imported flaw.

  15. Select the Add Scan Name as a Tag checkbox to add a tag to each work item showing the name of the scan that found the imported flaw.

  16. In the Flaw Import Limit section, enter the maximum number of flaws to import at one time. The default is 1000.

  17. In the Custom Fields field, if you are using customized process templates with custom fields, you can specify the custom fields to add to new, but not existing, work items. Enter key-value pairs to specify each field name and value. Add each key-value pair separated with a colon on a new line.

    For example, to add Agile-based custom fields for story points (3), priority (1), work estimate (4), and test system information (My Test System), add these values:

    <_field reference name_>.StoryPoints:3
    <_field reference name_>.Priority:1
    <_field reference name_>.OriginalEstimate:4
    <_field reference name_>.SystemInfo:My Test System

    For field reference name, ensure each field name matches the field reference name in Azure and that all values are valid for a given field type. If there are any mismatch or validation errors, you can only see these errors in the console after importing flaws.

  18. In the Advanced Scan Settings section, configure these options:

    • Proxy Settings: if you use a proxy to access Veracode, enter the proxy settings. For example:

      -phost abc.com - pport 5252 -puser proxyuser -ppassword proxypassword
      note

      Do not enclose any of the values in single or double quotations.

    • Team Foundation Server Password: do not change this value from the default of $(password).

  19. Select Add to add the Flaw Importer task to the YAML file in your build pipeline.

    The following example YAML demonstrates building a .NET application. At the end of the YAML are the Veracode tasks for Upload and Scan and Flaw Importer. The YAML specifies to access Veracode using a service connection. For descriptions of all YAML properties for the Flaw Importer task, see Azure DevOps YAML Properties for Flaw Importer.

    # .NET Desktop
    # Build and run tests for .NET Desktop or Windows classic desktop solutions.
    # Add steps that publish symbols, save build artifacts, and more:
    # https://docs.microsoft.com/azure/devops/pipelines/apps/windows/dot-net

    trigger:
    - master

    pool:
      vmImage: 'windows-latest'

    variables:
      solution: '**/*.sln'
      buildPlatform: 'Any CPU'
      buildConfiguration: 'Debug' # required as part of Veracode packaging for task: VSBuild@1

    steps:
    - task: NuGetToolInstaller@1

    - task: NuGetCommand@2
      inputs:
        restoreSolution: '$(solution)'

    - task: VSBuild@1
      inputs:
        solution: '$(solution)'
        platform: '$(buildPlatform)'
        configuration: '$(buildConfiguration)'

    - task: VSTest@2
      inputs:
        platform: '$(buildPlatform)'
        configuration: '$(buildConfiguration)'

    - task: DownloadPipelineArtifact@2
      inputs:
        patterns: '**/*.exe,**/*.dll,**/*.pdb' # ensures Veracode gets the PDB files for Static Analysis

    # This task makes the pipeline build artifacts available in a known location for upload to Veracode
    - task: PublishPipelineArtifact@1
      inputs:
        targetPath: $(System.DefaultWorkingDirectory)/bin/Debug
        artifactName: Debug
        
    - task: Veracode@3
      inputs:
        ConnectionDetailsSelection: 'Endpoint' # access Veracode with service connection or Veracode API credentials
        AnalysisService: 'Veracode Service Account' # service connection name for accessing Veracode
        veracodeAppProfile: '$(system.teamProject)' # Veracode application profile name (case-sensitive) to scan
        version: '$(build.buildNumber)' # name of the scan to run
        filepath: '$(System.DefaultWorkingDirectory)/bin/Debug' # filepath or folderpath of files to upload to Veracode
        createSandBox: false # true to scan of new development sandbox
        createProfile: true # false to enforce using existing profiles
        failBuildIfUploadAndScanBuildStepFails: false # true to fail build if Upload and Scan task fails to start
        import: true # required to view Veracode results in Azure DevOps
        failBuildOnPolicyFail: false # true to fail the build if application fails policy
        maximumWaitTime: '360' # wait time, in minutes, to fail the build if no scan results available

    - task: Veracode Flaw Importer@3
      inputs:
        ConnectionDetailsSelection: 'Endpoint' # access Veracode with service connection or Veracode API credentials
        AnalysisService: 'Veracode Service Account' # service connection name for accessing Veracode
        veracodeAppProfile: '$(system.teamProject)' # Veracode application profile to scan
        sandboxName: 'MySandBox' # name of a development sandbox for sandbox scans
        scanType: 'Dynamic and Static Analysis' # import flaws from dynamic and static analysis scans
        importType: 'All Flaws' # import all flaws discovered during scan
        workItemType: 'Issue' # import all discovered flaws as Issue work item types
        area: '$(system.teamProject)' # area for grouping work items
        overwriteAreaPathInWorkItemsOnImport: 'true' # replace area path in all work items with value for 'area'
        iterationPath: 'MyProject\Iteration 2' # iteration path for grouping work items
        addCustomTag: 'MyCustomTag' # add MyCustomTag to all work items for imported flaws
        addCweAsATag: true # add corresponding CWE ID to all work items for imported flaws
        foundInBuild: true # add build number to all work items for imported flaws
        addScanNameAsATag: true # add Veracode scan name to all work items for imported flaws
        flawImportLimit: '1000' # import a maximum of 1000 flaws at the same time
        customFields: # add these custom fields to work items for imported flaws
          Custom.Field.Name1:value
          Custom.Field.Name2:value
          Custom.Field.Name3:value
          Custom.Field.Name4:value

  20. If you are using customized process templates, configure these predefined variables on the Variables tab in your build or release configuration:

    note

    The names of these predefined variables must match the variable names in your customized process templates.

    • enableCustomProcessTemplate: enter true to enable.
    • customWorkItemType: enter one of these work item types:
      • Bug
      • Epic
      • Feature
      • Issue
      • Task
      • Test Case
    • customPTActiveStatus: enter the state for in progress or active work.
    • customPTNewStatus: enter the state for new or proposed work.
    • customPTResolvedStatus: enter the state for resolved work.
    • customPTDesignStatus: enter the state for work in design or test.
    • customPTCloseStatus: enter the state for completed work.

    You configure these variables for the work item type (WIT) of which you are creating work items in your build or release configuration. The variables ensure that flaws import correctly if the status of a work item changes. See the Azure DevOps documentation for information on the work item states.

    In your build or release configuration, on the Variables tab, configure these pipeline variables in the customized process template for the Bug work item:

    • enableCustomProcessTemplate: enter true
    • customWorkItemType: enter Bug
    • customPTActiveStatus: enter Working
    • customPTNewStatus: enter Introducing
    • customPTResolvedStatus: enter Fixed
    • customPTCloseStatus: enter Closed

  21. Select Save & queue to save your configurations and add the build to your queue.

  22. Optionally, to add debugging to your pipeline, add a new variable and enter the following values in the New variable window:

    • Name: system.debug
    • Value: true

To keep the status of imported findings in your ticketing system in sync with the status of the actual findings in the Veracode Platform, you must routinely run the integration.

After the Flaw Import task has completed successfully, the work items related to flaws or vulnerabilities in a given application appear in Azure DevOps. You can search on the Work or Queries pages, for example, to find the work items you created.

You can use a variable to prevent a password from appearing in a console log.

Flaw Importer YAML properties​

This table describes the YAML properties and their values for adding the Veracode Flaw Importer task to an Azure DevOps build pipeline.

PropertyTypeDescription
ConnectionDetailsSelection
Required		StringOne of these methods for connecting to Veracode:
  • Endpoint to use an existing service connection that includes your API credentials. Include AnalysisService to specify a service connection name.
  • Credentials to enter your Veracode API credentials. Include apiId to enter your API ID and apiKey to enter your API key.
ConnectionDetailsSelection
Required		StringOne of these methods for connecting to Veracode:
  • Endpoint to use an existing service connection that includes your API credentials. Include AnalysisService to specify a service connection name.
  • Credentials to enter your Veracode API credentials. Include apiId to enter your API ID and apiKey to enter your API key.
veracodeAppProfile
Required		StringName of the application profile. The name is case-sensitive.
AnalysisServiceStringIf you set ConnectionDetailsSelection to Endpoint, the name of the service connection for accessing Veracode.

If a service connection does not exist, you can create a new service connection.
apiIdStringIf you set ConnectionDetailsSelection to Credentials, your Veracode API ID.
apiKeyStringIf you set ConnectionDetailsSelection to Credentials, your Veracode API key.
proxySettingsStringIf using a proxy to access Veracode, your proxy settings. For example:

-phost abc.com -pport 5252 -puser proxyuser -ppassword proxypassword

NOTE:
Do not enclose any of the values in single or double quotations.
sandboxNameStringFor development sandbox scans, the name of the sandbox in which to run the scan. If the sandbox does not exist, include createSandBox to create it with the specified name.
scanTypeStringScan types from which to import flaws or vulnerabilities. One of these values:
Dynamic, Static
SCA
, Static, SCA, Dynamic, Static, SCA
importTypeStringOne of these flaw types to import:
  • All Flaws: includes mitigated and remediated flaws and vulnerabilities from all scans. During the import process, the extension changes the state of the work items for all mitigated and remediated flaws to resolved or closed. After you fix or remediate the flaw, during the next scan, its status changes to fixed or mitigated in the Detailed Report. During the next import, the related work items change to closed. This option imports all flaws without any restrictions.
  • All Unmitigated Flaws: includes flaws and vulnerabilities from all scans.
  • All Flaws Violating Policy: includes all open flaws and vulnerabilities from all scans that affect policy.
  • All Unmitigated Flaws Violating Policy: includes open flaws and vulnerabilities from all scans that affect policy. The default.
    When generating new work items for imported flaws, the extension also imports mitigation and annotation comments. If you add comments to a previously imported flaws with work items, the extension does not import the new comments to work items during subsequent imports.
workItemTypeStringOne of these work item types to apply to all imported flaws:Bug, Issue, Task, Epic, Feature, Test Case

NOTE:
The Scrum process template does not support the Issue work item type. Also, the Veracode Flaw Importer task can only import flaws to customized work item types that do not contain required fields. If your customized work item types contain required fields, you must select different work item types that do not contain required fields, or the flaws fail to import.
areaStringPath to the area where you want to group the work items. You can enter up to five levels in the path. To enter the area paths, use the format <project_name>\<area_1>\<area_2>. For <project_name>, enter the name of the project in the Build Pipeline or Release Pipeline task for which you want to import flaws.
overwriteAreaPathInWorkItemsOnImportBooleanSet to true to replace the area path in new and existing work items with the value specified for area. If set to false existing work items retain their current area path.
addCustomTagStringAdd a tag with a custom string to all work items for all imported flaws.
addCweAsATagBooleanAdd a tag with the CWE ID for the discovered flaw to the corresponding work item. Set to true to add the tag. Set to false to not add the tag. Defaults to true and you only see this property in the YAML file if the value is false.
addCveAsATagBooleanFor SCA scans, add a tag with the CVE ID for the finding to the work item. Set to true to add the tag. Set to false to not add the tag. Defaults to true and you only see this property in the YAML file if the value is false.
addScanTypeTagBooleanAdd a tag with the scan type, such as Static or Dynamic, that found the finding to the work item. Set to true to add the tag. Set to false to not add the tag. Defaults to true and you only see this property in the YAML file if the value is false.
addSeverityTagBooleanAdd a tag with the finding severity to the work item. Set to true to add the tag. Set to false to not add the tag. Defaults to true and you only see this property in the YAML file if the value is false.
addDueDateTagBooleanAdd a tag to the work item with the due date for your team to fix the finding. Set to true to add the tag. Set to false to not add the tag. Defaults to true and you only see this property in the YAML file if the value is false.
foundInBuildBooleanAdd a tag with the build number of the build in which Veracode discovered the flaw to the corresponding work item. Set to true to add the tag. Set to false to not add the tag. Defaults to true and you only see this property in the YAML file if the value is false.
addScanNameAsATagBooleanAdd a tag to each work item showing the name of the Veracode scan that found the imported flaw. Set to true to add the tag. Set to false to not add the tag. Defaults to true and you only see this property in the YAML file if the value is false.
flawImportLimitIntegerMaximum number of flaws to import at the same time. Default is 1000.
customFieldsStringAdd custom fields from process templates to generated work items of imported flaws. Enter key-value pairs to specify each field name and value. Add each key-value pair, separated with a colon, on a new line. For example: field.name:value

NOTE:
Ensure these field names match the field names you define in Azure and that all values are valid for a given field type. If there are any mismatch or validation errors, you can only see these errors in the console after importing flaws.
Last updated on