Pipeline Scan examples

This section provides example configuration scenarios that demonstrate a few common configurations you can use as a reference when integrating Pipeline Scan. It also provides code examples for popular CI/CD systems and SCM tools that you can use as templates to add Pipeline Scan to a build stage in your build pipelines. Add the Pipeline Scan stage after the stage that builds your application. For example scan results output, see Example scan results.

The code examples include scripts to download and extract the pipeline-scan-LATEST.zip archive to ensure your pipeline is using the latest files. The README file in the pipeline-scan-LATEST.zip archive also contains these examples. For improved stability, we recommend that you change these scripts to use the Pipeline Scan Docker image.

For additional code examples or to ask questions, visit the Veracode Community.

Example configuration scenarios

This section provides a few configuration scenarios that you can use when deciding how you want to implement a Pipeline Scan in your development environment. You add these scenarios to a stage in your pipeline that runs after the stage for building your application.

Report flaws that violate policy and proceed regardless of the results

Define the policy criteria with the --fail_on_severity and --fail_on_cwe parameters, or use the --policy_file or --policy_name parameters to specify a security policy.
Initiate the Pipeline Scan on the built application.
After the Pipeline Scan stage runs, proceed to the next stage, ignoring any exit code from the Pipeline Scan stage. Veracode identifies this scenario as allow failure. Implementation details vary for each CI system.

Fail the pipeline stage if flaws violate policy (break the build)

Define the policy criteria with the --fail_on_severity and --fail_on_cwe parameters, or with a security policy using the --policy_file or --policy_name parameters.
Initiate the Pipeline Scan on the built application.
The Pipeline Scan stage fails if it finds any flaws matching the defined criteria. The exit code reports the number of flaws, up to 200.
The Pipeline Scan stage fails if it finds any flaws matching the defined criteria. The exit code reports the number of flaws, up to 200.
The Pipeline Scan stage passes if it does not find flaws matching the defined criteria.

Fail the pipeline stage if new flaws violate policy (break the build)

Include a baseline file, either as an artifact from a previous build or the project repository, to establish a set of known flaws for the scanned application.
Define the policy criteria with the --fail_on_severity and --fail_on_cwe parameters, or with a security policy using the --policy_file or --policy_name parameters. Include the baseline file using the -bf parameter.
Initiate the Pipeline Scan on the built application.
The Pipeline Scan stage fails if it finds any flaws matching the defined criteria that are not present in the baseline file. The exit code reports the number of flaws, up to 200.
The Pipeline Scan stage passes if it does not find flaws that match the defined criteria or if the baseline file includes all the flaws.

Example code for Azure DevOps

You can add a Pipeline Scan as a job in an Azure DevOps pipeline. You can use the YAML code examples in this section to configure Azure DevOps pipelines for building a project and running the Pipeline Scan as a stage in the pipeline.

The Pipeline Scan code examples include variables for your API credentials. Ensure these variables correctly reference your API ID and key stored in your CI/CD code repository.

Veracode provides these packaged applications on GitHub: VeraDemoDotNet and VeraDemo. You can use these applications for testing, debugging, or for demos if you do not have an application that meets the packaging requirements for a specific scan type. You can download these applications or connect them to a CI/CD code repository.

Scan an ASP.NET application

This example YAML code shows how to add a Pipeline Scan as a build stage in an Azure DevOps build pipeline for an ASP.NET application on Windows.

The example includes a script that downloads and unzips pipeline-scan-LATEST.zip, to ensure you have the latest version, then runs pipeline-scan.jar using your API credentials. For improved stability, we recommend that you change the script to use the Pipeline Scan Docker image.

trigger:
  - main

pool:
  vmImage: "windows-latest"

variables:
  solution: "**/*.sln"
  buildPlatform: "Any CPU"
  buildConfiguration: "Release"

steps:
  - task: NuGetToolInstaller@1

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

  - task: VSBuild@1
    inputs:
      solution: "$(solution)"
      msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
      platform: "$(buildPlatform)"
      configuration: "$(buildConfiguration)"

  - task: CmdLine@2
    displayName: Veracode Pipeline Scan
    inputs:
      script: |
        curl -sSO https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip
        unzip -o pipeline-scan-LATEST.zip
        java -jar pipeline-scan.jar -vid $(VERACODE_API_ID) -vkey $(VERACODE_API_KEY) -f $(build.artifactstagingdirectory)\Verademo-dotnet.zip || true
      # VERACODE_API_ID and VERACODE_API_KEY environment variables must reference your API credentials.
      # "|| true" specifies to continue build if Pipeline Scan discovers flaws.
      # To fail the build for new flaws not listed in a baseline file, add an existing baseline file with "-bf <baseline filename>" and remove "|| true".

  - task: PublishBuildArtifacts@1
    displayName: Create Build Artifact for Veracode Pipeline Scan Results
    inputs:
      PathtoPublish: "results.json"
      ArtifactName: "Build"
      publishLocation: "Container"

Add scanning to a Gradle build stage

This example YAML code shows how to add a Pipeline Scan as a build stage in an Azure DevOps build pipeline that uses Gradle.

trigger:
- master

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: Gradle@2
  inputs:
    workingDirectory: ''
    gradleWrapperFile: 'gradlew'
    gradleOptions: '-Xmx3072m'
    javaHomeOption: 'JDKVersion'
    jdkVersionOption: '1.8'
    jdkArchitectureOption: 'x64'
    publishJUnitResults: true
    testResultsFiles: '**/TEST-*.xml'
    tasks: 'build'
- script: |
    curl -O -L https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip
  displayName: 'Download Pipeline Scanner'
- task: ExtractFiles@1
  inputs:
    archiveFilePatterns: 'pipeline-scan-LATEST.zip'
    destinationFolder: 'pipeline'
    cleanDestinationFolder: false
- script: |
      java -jar pipeline\pipeline-scan.jar --veracode_api_id "$(VERACODE_API_ID)" --veracode_api_key "$(VERACODE_API_KEY)" --file "example.jar" --fail_on_severity="Very High, High" --fail_on_cwe="80"
  env:
    VERACODE_API_ID: $(VERACODE_API_ID)
    VERACODE_API_KEY: $(VERACODE_API_KEY)
  displayName: 'Run Pipeline Scan'

Add scanning to a Maven build stage

This example YAML code shows how to add a Pipeline Scan as a build stage in an Azure DevOps build pipeline that uses Maven on Unix.

trigger:
  - master
pool:
  vmImage: "ubuntu-latest"
steps:
  - task: Maven@3
    displayName: Build with Maven
    inputs:
      mavenPomFile: "app/pom.xml"
      mavenOptions: "-Xmx3072m"
      javaHomeOption: "JDKVersion"
      jdkVersionOption: "1.8"
      jdkArchitectureOption: "x64"
      publishJUnitResults: true
      testResultsFiles: "**/surefire-reports/TEST-*.xml"
      goals: "package"
  - task: Bash@3
    displayName: Veracode Pipeline Scan
    inputs:
      targetType: "inline"
      script: |
        curl -sSO https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip
        unzip -o pipeline-scan-LATEST.zip
        java -jar pipeline-scan.jar -vid $(VERACODE_API_ID) -vkey $(VERACODE_API_KEY) -f /home/vsts/work/1/s/app/target/verademo.war || true
      # VERACODE_API_ID and VERACODE_API_KEY environment variables must reference your API credentials.
      # "|| true" specifies to continue build if Pipeline Scan discovers flaws.
      # To fail the build for new flaws not listed in a baseline file, add an existing baseline file with "-bf <baseline filename>" and remove "|| true".
  - publish: $(System.DefaultWorkingDirectory)/results.json # Save the scan results as a file named results.json.
    artifact: VeracodeBaseline

Create and apply a baseline file

This YAML code example shows how to generate and use a baseline file in an Azure DevOps build pipeline.

The Pipeline Scan evaluates only flaws that differ from those stored in the baseline file to determine pass or fail criteria. You can use a baseline file to evaluate security risk on only new changes to your application. The Pipeline Scan uses a single pipeline for the build and security scan, then stores the baseline file as an artifact each time a job runs. You can modify this example so that you can run the Pipeline Scan as its own pipeline that another job can trigger. Depending on your build configuration, you may want to store results in a separate globally-accessible location, such as a shared directory.

Create a baseline file

trigger:
  - master
pool:
  vmImage: "ubuntu-latest"
steps:
  - task: Gradle@2
    inputs:
      workingDirectory: ""
      gradleWrapperFile: "gradlew"
      gradleOptions: "-Xmx3072m"
      javaHomeOption: "JDKVersion"
      jdkVersionOption: "1.8"
      jdkArchitectureOption: "x64"
      publishJUnitResults: true
      testResultsFiles: "**/TEST-*.xml"
      tasks: "build"
  - script: |
      curl -O -L https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip
    displayName: "Download Pipeline Scan"
  - task: ExtractFiles@1
    inputs:
      archiveFilePatterns: "pipeline-scan-LATEST.zip"
      destinationFolder: "pipeline"
      cleanDestinationFolder: false
  - script: |
      java -jar pipeline\pipeline-scan.jar --veracode_api_id "$(VERACODE_API_ID)" --veracode_api_key "$(VERACODE_API_KEY)" --file "example.jar" --json_output_file="baseline.json" || true
      # Pipeline Scan command. VERACODE_API_ID and VERACODE_API_KEY must reference your API credentials.
      # "--json_output_file" saves scan results as a JSON file that you can use as a baseline file.
    env:
      VERACODE_API_ID: $(VERACODE_API_ID)
      VERACODE_API_KEY: $(VERACODE_API_KEY)
    displayName: "Run Pipeline Scan"
  - publish: $(System.DefaultWorkingDirectory)/baseline.json
    artifact: baseline

Apply a baseline file

The following code applies a baseline file and fails the build when new flaws are found during scanning.

trigger:
  - master
pool:
  vmImage: "ubuntu-latest"
steps:
  - script: |
      curl -O -L https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip
    displayName: "Download Pipeline Scan"
  - task: ExtractFiles@1
    inputs:
      archiveFilePatterns: "pipeline-scan-LATEST.zip"
      destinationFolder: "pipeline"
      cleanDestinationFolder: false
  - task: DownloadPipelineArtifact@2
    inputs:
      source: specific
      project: "test"
      pipeline: 2
      artifact: baseline
  - script: |
      java -jar pipeline\pipeline-scan.jar --veracode_api_id "$(VERACODE_API_ID)" --veracode_api_key "$(VERACODE_API_KEY)" --file "example.jar" --baseline_file "../baseline.json"
      # VERACODE_API_ID and VERACODE_API_KEY must reference your API credentials.
      # "--baseline_file" specifies the baseline of known flaws for the specified application file.
      # This example command breaks the build for new flaws not listed in the specified baseline file.
    env:
      VERACODE_API_ID: $(VERACODE_API_ID)
      VERACODE_API_KEY: $(VERACODE_API_KEY)
    displayName: "Run Pipeline Scan"

Example code for GitHub

You can add a Pipeline Scan as a step in a GitHub Actions workflow. You can use the YAML code examples in this section to configure GitHub Action workflows for building a project and running the Pipeline Scan as a step in the workflow.

The Pipeline Scan code examples include variables for your API credentials. Ensure these variables correctly reference your API ID and key stored in your CI/CD code repository.

Add scanning to a Gradle build stage in a GitHub Actions pipeline

This example YAML code shows how to add a Pipeline Scan as a build stage in a GitHub Actions build pipeline that uses Gradle.

name: pipeline-scan

on: push

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: build
        run: gradle clean build
  pipeline-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Set up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - name: Download the Pipeline Scanner
        uses: wei/curl@master
        with:
          args: -O https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip
      - name: Unzip the Pipeline Scanner
        run: unzip pipeline-scan-LATEST.zip
      - name: Run Pipeline Scanner
        run: java -Dpipeline.debug=true -jar pipeline-scan.jar --veracode_api_id "${{secrets.VERACODE_API_ID}}" --veracode_api_key "${{secrets.VERACODE_API_KEY}}" --file "example.jar" --fail_on_severity="Very High, High"

Add scanning to a Maven build stage in a GitHub Actions pipeline

This example YAML code shows how to add a Pipeline Scan as a build stage in a GitHub Actions build pipeline with Maven.

name: pipeline-scan

on: push

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: build
        run: maven clean verify
  pipeline-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Set up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - name: Download the Pipeline Scanner
        uses: wei/curl@master
        with:
          args: -O https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip
      - name: Unzip the Pipeline Scanner
        run: unzip pipeline-scan-LATEST.zip
      - name: Run Pipeline Scanner
        run: java -Dpipeline.debug=true -jar pipeline-scan.jar --veracode_api_id "${{secrets.VERACODE_API_ID}}" --veracode_api_key "${{secrets.VERACODE_API_KEY}}" --file "example.jar" --fail_on_severity="Very High, High"

Use a baseline file in a GitHub Actions pipeline

This YAML code example shows how to generate and use a baseline file in a GitHub Actions workflow.

name: pipeline-scan

on: push

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: build
        run: gradle clean build
  baseline:
    runs-on: ubuntu-latest
    steps:
      - name: Set up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - name: Download the Pipeline Scanner
        uses: wei/curl@master
        with:
          args: -O https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip
      - name: Unzip the Pipeline Scanner
        run: unzip pipeline-scan-LATEST.zip
      - name: Create Baseline
        run: java -Dpipeline.debug=true -jar pipeline-scan.jar --veracode_api_id "${{secrets.VERACODE_API_ID}}" --veracode_api_key "${{secrets.VERACODE_API_KEY}}" --file "example.jar" --json_output_file="baseline.json" || true
      - name: Upload Baseline
        uses: actions/upload-artifact@v1
        with:
          name: baseline
          path: baseline.json
  baseline-scan:
    runs-on: ubuntu-latest
    needs: baseline
    steps:
      - name: Set up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - name: Download the Pipeline Scanner
        uses: wei/curl@master
        with:
          args: -O https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip
      - name: Unzip the Pipeline Scanner
        run: unzip pipeline-scan-LATEST.zip
      - name: download baseline
        uses: actions/download-artifact@v1
        with:
          name: baseline
      - name: Scan with baseline
        run: java -Dpipeline.debug=true -jar pipeline-scan.jar --veracode_api_id "${{secrets.VERACODE_API_ID}}" --veracode_api_key "${{secrets.VERACODE_API_KEY}}" --file "example.jar" --baseline_file "baseline/baseline.json"

Example code for GitLab

You can add a Pipeline Scan as a job in a GitLab pipeline. You can use the YAML code examples in this section to configure GitLab pipeline jobs for building a project and running a Pipeline Scan as a stage in the pipeline.

The Pipeline Scan code examples include variables for your API credentials. Ensure these variables correctly reference your API ID and key stored in your CI/CD code repository.

Important

Before you can use the --gl_issue_generation parameter, you must configure GitLab to import findings as issues.

Add scanning to a Gradle build stage

This example YAML code shows how to add a Pipeline Scan as a build stage in a GitLab Actions build pipeline using Gradle.

image: <image-with-above-requirements>

stages:
  - build
  - scan

build_job:
  stage: build
  artifacts:
    name: ${CI_PROJECT_NAME}_${CI_COMMIT_REF_NAME}_${CI_COMMIT_SHA}_build
    paths:
      - build/
    expire_in: 1 week
  script: gradle clean build

pipeline scan:
  stage: scan
  dependencies:
    - build_job
  artifacts:
    name: ${CI_PROJECT_NAME}_${CI_COMMIT_REF_NAME}_${CI_COMMIT_SHA}_pipeline-results
    paths:
      - results.json
    expire_in: 1 week
    when: always
  script:
    - curl -O https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip
    - unzip pipeline-scan-LATEST.zip pipeline-scan.jar
    - java -jar pipeline-scan.jar
      --veracode_api_id "${VERACODE_API_ID}"
      --veracode_api_key "${VERACODE_API_SECRET}"
      --file "build/libs/sample.jar"
      --fail_on_severity="Very High, High"
      --fail_on_cwe="80"
      --baseline_file "${CI_BASELINE_PATH}"
      --timeout "${CI_TIMEOUT}"
      --project_name "${CI_PROJECT_PATH}"
      --project_url "${CI_REPOSITORY_URL}"
      --project_ref "${CI_COMMIT_REF_NAME}"

Add scanning to a Gradle build stage and generate issues for findings

This example YAML code shows how to add a Pipeline Scan and automatic issue generation as a build stage in a GitLab build pipeline using Gradle.

This structure in the GitLab CI performs a self-test and sets the $VERACODE_API_* variables in the CI/CD settings.

image: <image-with-above-requirements>

stages:
  - build
  - scan

build_job:
  stage: build
  artifacts:
    name: ${CI_PROJECT_NAME}_${CI_COMMIT_REF_NAME}_${CI_COMMIT_SHA}_build
    paths:
      - build/
    expire_in: 1 week
  script: gradle clean build

pipeline scan:
  stage: scan
  dependencies:
    - build_job
  artifacts:
    name: ${CI_PROJECT_NAME}_${CI_COMMIT_REF_NAME}_${CI_COMMIT_SHA}_pipeline-results
    paths:
      - results.json
    expire_in: 1 week
    when: always
  script:
    - curl -O https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip
    - unzip pipeline-scan-LATEST.zip pipeline-scan.jar
    - java -jar pipeline-scan.jar
      --veracode_api_id "${VERACODE_API_ID}"
      --veracode_api_key "${VERACODE_API_SECRET}"
      --file "build/libs/sample.jar"
      --fail_on_severity="Very High, High"
      --fail_on_cwe="80"
      --baseline_file "${CI_BASELINE_PATH}"
      --timeout "${CI_TIMEOUT}"
      --project_name "${CI_PROJECT_PATH}"
      --project_url "${CI_REPOSITORY_URL}"
      --project_ref "${CI_COMMIT_REF_NAME}"
      --gl_issue_generation true

Add scanning to a Gradle build stage and import findings as vulnerabilities

This example YAML code shows how to add a Pipeline Scan and automatic vulnerability generation as a build stage in a GitLab build pipeline using Gradle. Automatic vulnerability generation requires a GitLab Premium or Ultimate license.

This structure in the GitLab CI performs a self-test and sets the $VERACODE_API_* variables in the CI/CD settings.

image: <image-with-above-requirements>

stages:
  - build
  - scan

build_job:
  stage: build
  artifacts:
    name: ${CI_PROJECT_NAME}_${CI_COMMIT_REF_NAME}_${CI_COMMIT_SHA}_build
    paths:
      - build/
    expire_in: 1 week
  script: gradle clean build

pipeline scan:
  stage: scan
  dependencies:
    - build_job
  artifacts:
    name: ${CI_PROJECT_NAME}_${CI_COMMIT_REF_NAME}_${CI_COMMIT_SHA}_pipeline-results
    paths:
      - results.json
      - veracode_gitlab_vulnerabilities.json
    reports:
      sast: veracode_gitlab_vulnerabilities.json
    expire_in: 1 week
    when: always
  script:
    - curl -O https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip
    - unzip pipeline-scan-LATEST.zip pipeline-scan.jar
    - java -jar pipeline-scan.jar
      --veracode_api_id "${VERACODE_API_ID}"
      --veracode_api_key "${VERACODE_API_SECRET}"
      --file "build/libs/sample.jar"
      --fail_on_severity="Very High, High"
      --fail_on_cwe="80"
      --baseline_file "${CI_BASELINE_PATH}"
      --timeout "${CI_TIMEOUT}"
      --project_name "${CI_PROJECT_PATH}"
      --project_url "${CI_REPOSITORY_URL}"
      --project_ref "${CI_COMMIT_REF_NAME}"
      --gl_vulnerability_generation true

Add scanning to a Gradle build stage, apply a built-in policy, and import vulnerabilities

This YAML code example shows how to add a Pipeline Scan to GitLab with Gradle using a built-in security policy and automatic vulnerability generation.

To evaluate Pipeline Scan results against one of the built-in policies in the Veracode Platform, enter the policy name using the --policy_name parameter. This parameter replaces the --fail_on_severity and --fail_on_cwe parameters.

image: <image-with-above-requirements>

stages:
  - build
  - scan

build_job:
  stage: build
  artifacts:
    name: ${CI_PROJECT_NAME}_${CI_COMMIT_REF_NAME}_${CI_COMMIT_SHA}_build
    paths:
      - build/
    expire_in: 1 week
  script: gradle clean build

pipeline scan:
  stage: scan
  dependencies:
    - build_job
  artifacts:
    name: ${CI_PROJECT_NAME}_${CI_COMMIT_REF_NAME}_${CI_COMMIT_SHA}_pipeline-results
    paths:
      - results.json
      - veracode_gitlab_vulnerabilities.json
    reports:
      sast: veracode_gitlab_vulnerabilities.json
    expire_in: 1 week
    when: always
  script:
    - curl -O https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip
    - unzip pipeline-scan-LATEST.zip pipeline-scan.jar
    - java -jar pipeline-scan.jar
      --veracode_api_id "${VERACODE_API_ID}"
      --veracode_api_key "${VERACODE_API_SECRET}"
      --file "build/libs/sample.jar"
      --policy_name="Veracode Recommended Very High"
      --baseline_file "${CI_BASELINE_PATH}"
      --timeout "${CI_TIMEOUT}"
      --project_name "${CI_PROJECT_PATH}"
      --project_url "${CI_REPOSITORY_URL}"
      --project_ref "${CI_COMMIT_REF_NAME}"
      --gl_vulnerability_generation true

Add scanning to a Gradle build stage, apply a custom policy, and import vulnerabilities

These code examples show how to download a custom security policy and use it in a GitLab pipeline with Gradle and automatic vulnerability generation.

To download a policy locally to use later in the pipeline, use the --request_policy parameter as shown in this example:

- java -jar pipeline-scan.jar
       --veracode_api_id "${VERACODE_API_ID}"
       --veracode_api_key "${VERACODE_API_SECRET}"
       --request_policy="Custom Policy"

Pipeline Scan automatically names the locally-generated policy file using the format <policy name>.json, replacing any spaces with underscores. In this example, the resulting file is named Custom_Policy.json. You should place this file in a location accessible to the pipeline for its subsequent use. Use the --policy_file parameter to specify the local custom policy for vulnerability filtering:

image: <image-with-above-requirements>

stages:
  - build
  - scan

build_job:
  stage: build
  artifacts:
    name: ${CI_PROJECT_NAME}_${CI_COMMIT_REF_NAME}_${CI_COMMIT_SHA}_build
    paths:
      - build/
    expire_in: 1 week
  script: gradle clean build

pipeline scan:
  stage: scan
  dependencies:
    - build_job
  artifacts:
    name: ${CI_PROJECT_NAME}_${CI_COMMIT_REF_NAME}_${CI_COMMIT_SHA}_pipeline-results
    paths:
      - results.json
      - veracode_gitlab_vulnerabilities.json
    reports:
      sast: veracode_gitlab_vulnerabilities.json
    expire_in: 1 week
    when: always
  script:
    - curl -O https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip
    - unzip pipeline-scan-LATEST.zip pipeline-scan.jar
    - java -jar pipeline-scan.jar
      --veracode_api_id "${VERACODE_API_ID}"
      --veracode_api_key "${VERACODE_API_SECRET}"
      --file "build/libs/sample.jar"
      --policy_file="Custom_Policy.json"
      --baseline_file "${CI_BASELINE_PATH}"
      --timeout "${CI_TIMEOUT}"
      --project_name "${CI_PROJECT_PATH}"
      --project_url "${CI_REPOSITORY_URL}"
      --project_ref "${CI_COMMIT_REF_NAME}"
      --gl_vulnerability_generation true

Add scanning to a Maven build stage

This example YAML code shows how to add a Pipeline Scan as a build stage in a GitLab Actions build pipeline using Maven.

image: <image-with-above-requirements>

stages:
  - build
  - scan

build_job:
  stage: build
  script:
    - mvn clean verify
  artifacts:
    name: ${CI_PROJECT_NAME}_${CI_COMMIT_REF_NAME}_${CI_COMMIT_SHA}_build
    paths:
      - build/
    expire_in: 1 week

pipeline scan:
  stage: scan
  dependencies:
    - build_job
  artifacts:
    name: ${CI_PROJECT_NAME}_${CI_COMMIT_REF_NAME}_${CI_COMMIT_SHA}_pipeline-results
    paths:
      - results.json
    expire_in: 1 week
    when: always
  script:
    - curl -O https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip
    - unzip pipeline-scan-LATEST.zip pipeline-scan.jar
    - java -jar pipeline-scan.jar
      --veracode_api_id "${VERACODE_API_ID}"
      --veracode_api_key "${VERACODE_API_SECRET}"
      --file "build/libs/sample.jar"
      --fail_on_severity="Very High, High"
      --fail_on_cwe="80"
      --baseline_file "${CI_BASELINE_PATH}"
      --timeout "${CI_TIMEOUT}"
      --project_name "${CI_PROJECT_PATH}"
      --project_url "${CI_REPOSITORY_URL}"
      --project_ref "${CI_COMMIT_REF_NAME}"

Scan with a baseline file

This YAML code example shows how to generate, store, and use a baseline file in a GitLab build pipeline.

image: <image-with-above-requirements>

stages:
  - build
  - scan
  - store

build_job:
  stage: build
  artifacts:
    name: ${CI_PROJECT_NAME}_${CI_COMMIT_REF_NAME}_${CI_COMMIT_SHA}_build
    paths:
      - build/
    expire_in: 1 week
  script: gradle clean build

Scan:
  stage: scan
  only:
    - master
  dependencies:
    - build_job
  artifacts:
    name: ${CI_PROJECT_NAME}_${CI_COMMIT_REF_NAME}_${CI_COMMIT_SHA}_pipeline-results
    paths:
      - baseline.json
    expire_in: 1 week
    when: always
  script:
    - curl -O https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip
    - unzip pipeline-scan-LATEST.zip pipeline-scan.jar
    - java -jar pipeline-scan.jar
      --veracode_api_id "${VERACODE_API_ID}"
      --veracode_api_key "${VERACODE_API_SECRET}"
      --file "build/libs/sample.jar"
      --fail_on_severity="Very High, High"
      --fail_on_cwe="80"
      --json_output_file="baseline.json"
      --timeout "${CI_TIMEOUT}"
      --project_name "${CI_PROJECT_PATH}"
      --project_url "${CI_REPOSITORY_URL}"
      --project_ref "${CI_COMMIT_REF_NAME}"

Store Baseline:
  # Job will only run on master, if requested.
  # Will restore the above baseline artifact so it can be pulled down in other stages
  stage: store
  before_script:
  only:
    - master
  when: manual
  script:
    - echo "Storing results.json as baseline.json"
  artifacts:
    name: baseline
    paths:
      - baseline.json # If you want to keep this longer than the GitLab default - press store in the web UI

Baseline Scan:
  # Job will run anywhere, except master. Will pull the baseline file and use it in the scan, if available
  dependencies:
    - Scan
  except:
    - master
  stage: scan
  script:
    - git clean -dfx
    - "curl -O https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip"
    - unzip pipeline-scan-LATEST.zip pipeline-scan.jar
    - '[[ ! -f baseline.json ]] &&  curl --location "$CI_PROJECT_URL/-/jobs/artifacts/$CI_COMMIT_REF_NAME/raw/baseline.json?job=Store%20Baseline" -o baseline.json'
    - java -jar pipeline-scan.jar --veracode_api_id "${VERACODE_KEY}" --veracode_api_key "${VERACODE_SECRET}" --file "<file_to_scan>" --project_name "${CI_PROJECT_PATH}" --project_url "${CI_PROJECT_URL}" --project_ref "${CI_COMMIT_REF_NAME}" --baseline_file baseline.json -jf results.json

Example code for Jenkins

You can add a Pipeline Scan as a job in a Jenkins declarative pipeline. You configure a Jenkins pipeline with a Jenkins file that defines stages of running the pipeline. You can use the Groovy code examples in this section to configure a Jenkins build job for building a project and running a Pipeline Scan as a stage in the pipeline.

The Pipeline Scan code examples include variables for your Veracode API credentials. Ensure these variables correctly reference your API ID and key stored in your CI/CD code repository.

Add scanning to a Gradle build stage

This example Groovy code shows how to add a Pipeline Scan as a build stage in a Jenkins build pipeline that uses Gradle.

pipeline {
  agent { label <'any-with-jdk8-gradle-curl-unzip'> }
  stages {
    stage('Gradle Build') {
      steps {
        sh 'gradle clean build'
      }
    }
    stage('Veracode Pipeline Scan') {
      steps {
        sh 'curl -O https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip'
        sh 'unzip pipeline-scan-LATEST.zip pipeline-scan.jar'
        sh 'java -jar pipeline-scan.jar \
          --veracode_api_id "${VERACODE_API_ID}" \
          --veracode_api_key "${VERACODE_API_SECRET}" \
          --file "build/libs/sample.jar" \
          --fail_on_severity="Very High, High" \
          --fail_on_cwe="80" \
          --baseline_file "${CI_BASELINE_PATH}" \
          --timeout "${CI_TIMEOUT}" \
          --project_name "${env.JOB_NAME}" \
          --project_url "${env.GIT_URL}" \
          --project_ref "${env.GIT_COMMIT}"'
      }
    }
  }
  post {
    always {
      archiveArtifacts artifacts: 'results.json', fingerprint: true
    }
  }
}

Add scanning to a Maven build stage

This example Groovy code shows how to add a Pipeline Scan as a build stage in a Jenkins build pipeline that uses Maven.

pipeline {
  agent { label <'any-with-jdk8-maven-curl-unzip'> }
  stages {
    stage('Maven Build') {
      steps {
        sh 'maven clean verify'
      }
    }
    stage('Veracode Pipeline Scan') {
      steps {
        sh 'curl -O https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip'
        sh 'unzip pipeline-scan-LATEST.zip pipeline-scan.jar'
        sh 'java -jar pipeline-scan.jar \
          --veracode_api_id "${VERACODE_API_ID}" \
          --veracode_api_key "${VERACODE_API_SECRET}" \
          --file "build/libs/sample.jar" \
          --fail_on_severity="Very High, High" \
          --fail_on_cwe="80" \
          --baseline_file "${CI_BASELINE_PATH}" \
          --timeout "${CI_TIMEOUT}" \
          --project_name "${env.JOB_NAME}" \
          --project_url "${env.GIT_URL}" \
          --project_ref "${env.GIT_COMMIT}"'
      }
    }
  }
  post {
    always {
      archiveArtifacts artifacts: 'results.json', fingerprint: true
    }
  }
}

Scan with a baseline file

This example Groovy code shows how you can add a Pipeline Scan that uses a baseline file to a Jenkins build pipeline.

pipeline {
    agent { label <'any-with-jdk8-maven-curl-unzip'> }
    stages {
        stage('Clone Repo') {
            steps {
                git url: "$GIT_URL", branch: "$GIT_BRANCH", credentialsId: 'ae020d0c-c99b-4a6c-9663-7a2e0290648c'
            }
        }
        stage('Gradle Build') {
            steps {
                sh './gradlew clean build'
            }
        }
        stage('Veracode Pipeline Scan') {
            steps {
                // Copy baseline from previous build
                copyArtifacts(projectName: "$JOB_NAME", selector: lastSuccessful(stable: true), filter: 'baseline.json', target: '.', optional: true)
                script {
                    ref = sh(script: 'git rev-parse HEAD', returnStdout: true).trim()
                    baseline = ''
                    if (fileExists('baseline.json')) {
                        baseline = '--baseline_file baseline.json'
                    }
                }

                // Download and submit Pipeline Scan
                sh 'curl -O https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip'
                sh 'unzip pipeline-scan-LATEST.zip pipeline-scan.jar'
                sh """
                    java -jar pipeline-scan.jar \
                        --veracode_api_id "${env.VERACODE_API_KEY_ID}" \
                        --veracode_api_key "${env.VERACODE_API_KEY_SECRET}" \
                        --jf results.json \
                        --timeout "$timeout" \
                        --file "build/libs/sample.jar" \
                        --project_name "$JOB_NAME" \
                        --project_url "$GIT_URL" \
                        --project_ref "$ref"
                        $baseline
                """
            }
        }
        stage('Store Baseline') {
            steps {
                script {
                    try {
                        input(message: 'Store results as baseline for future scans?', ok: 'Yes')
                        sh 'cp baseline.json build-baseline.json'
                        sh 'cp results.json baseline.json'
                    } catch (err) {

                    }
                }
            }
        }
    }
    post {
        always {
            archiveArtifacts artifacts: "*.json", fingerprint: true, allowEmptyArchive: true
            deleteDir()
        }
    }
}

Example scan results

This section provides example scan results from Pipeline Scans. If the scan produces very large results output, Pipeline Scan might truncate the results and include only a subset of the total results for the scan in the JSON and summary results output. Pipeline Scan issues a warning before starting with the truncation process.

The Pipeline Scan reports up to 200 flaws. If you include the --fail_on_severity parameter, the Pipeline Scan counts only the flaws requested using the --fail_on_severity parameter.

Default settings

This example shows the scan results using the default settings.

====================
Analysis Successful!
====================

===================
Analyzed 2 modules.
===================
Module1.war
Module2.war

======================
Analyzed 11 issues!
======================
-------------------------------------
Found 1 issues of Very High severity.
-------------------------------------
CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'): flawedpackage/Flawed.java:50
--------------------------------
Found 1 issues of High severity.
--------------------------------
CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'): flawedpackage/Flawed.java:43
----------------------------------
Found 7 issues of Medium severity.
----------------------------------
CWE-326: Inadequate Encryption Strength: flawedpackage/GreenLightKeySizeHMAC.java:38
CWE-259: Use of Hard-coded Password: flawedpackage/Flawed.java:23
CWE-259: Use of Hard-coded Password: flawedpackage/Flawed.java:54
CWE-331: Insufficient Entropy: flawedpackage/Flawed.java:59
CWE-327: Use of a Broken or Risky Cryptographic Algorithm: flawedpackage/Flawed.java:60
CWE-327: Use of a Broken or Risky Cryptographic Algorithm: flawedpackage/Flawed.java:61
CWE-326: Inadequate Encryption Strength: flawedpackage/Flawed.java:68
-------------------------------
Found 2 issues of Low severity.
-------------------------------
CWE-597: Use of Wrong Operator in String Comparison: flawedpackage/OneFlaw.java:5
CWE-404: Improper Resource Shutdown or Release: flawedpackage/Flawed.java:37

=========================
FAILURE: Found 11 issues!
=========================

Issue details expanded

This example shows the expanded information shown in the results if you specify --issue_details true. The results include a link to Veracode remediation guidelines. For example: https://downloads.veracode.com/securityscan/cwe/v4/java/245.html

====================
Analysis Successful.
====================

===================
Analyzed 2 modules.
===================
Module1.war
Module2.war

==================
Analyzed 2 issues.
==================
-------------------------------
Found 2 issues of Low severity.
-------------------------------
CWE-209: Information Exposure Through an Error Message: tiles/error/errorUncaughtMessage.jsp:9
Details: <span> The application calls the javax.servlet.jsp.JspWriter.print() function, which may expose information about the application logic or other
details such as the names and versions of the application container and associated components.  This information can be useful in executing other attacks
and can also enable the attacker to target known vulnerabilities in application components. </span> <span>Ensure that error codes or other messages
returned to end users are not overly verbose.  Sanitize all messages of any sensitive information that is not absolutely necessary.</span>
<span>References: <a href="https://cwe.mitre.org/data/definitions/209.html">CWE</a></span>
https://downloads.veracode.com/securityscan/cwe/v4/java/209.html
CWE-245: J2EE Bad Practices: Direct Management of Connections: edu/ufl/osg/webmail/prefs/DBPrefsPlugIn.java:172
Details: <span>This call to getConnection() fails to use the J2EE container's resource management facilities as required by the J2EE standard.</span>
<span>Request the connection from the container rather than attempting to access it directly.</span> <span>References: <a href="https://cwe.mitre.
org/data/definitions/245.html">CWE</a></span>
https://downloads.veracode.com/securityscan/cwe/v4/java/245.html
========================
FAILURE: Found 2 issues!
========================

Severity filters selected

This example shows the results if you specify --fail_on_severity ”Very High,High”.

note

GitLab sometimes removes quotes when expanding variables, exposing any spaces in the variable to the shell. The entire parameter is not set correctly if it contains spaces. Because the Pipeline Scan recognizes filter parameters, both with and without spaces, you may need to remove all spaces from the parameter if you include the filter arguments in a variable. Otherwise, the command may fail.

    ====================
    Analysis Successful!
    ====================

    ===================
    Analyzed 2 modules.
    ===================
    Module1.war
    Module2.war

    =====================
    Found 1 total issues!
    =====================
    ----------------------------------
    Skipping 1 issues of Low Severity.
    ----------------------------------
    ===================================
    SUCCESS: All issues passed filters!
    ===================================

CWE filters selected

This example shows the expanded information shown in the results if you specify --fail_on_cwe. In this example, the filter is set for CWEs 89 and 331: --fail_on_cwe="89, 331".

    ====================
    Analysis Successful!
    ====================

    ===================
    Analyzed 2 modules.
    ===================
    Module1.war
    Module2.war

    ==================
    Analyzed 5 issues.
    ==================
    --------------------------
    Found 1 issues of CWE 331.
    --------------------------
    CWE-331: Insufficient Entropy: flawedPackage/Flawed.java:49
    -------------------------
    Found 1 issues of CWE 89.
    -------------------------
    CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'): flawedPackage/Flawed.java:33

    ========================
    FAILURE: Found 2 issues!
    ========================

Baseline filters selected

This example shows the expanded information shown in the results if you specify --baseline [_baseline_file_path_] to scan against a baseline file.

    ====================
    Analysis Successful!
    ====================

    ===================
    Analyzed 2 modules.
    ===================
    Module1.war
    Module2.war

    ==================
    Analyzed 3 issues.
    ==================
    ----------------------------------
    Found 2 issues of Medium severity.
    ----------------------------------
    CWE-470: Use of Externally-Controlled Input to Select Classes or Code
    ('Unsafe Reflection'): org/apache/sqoop/test/hive/MetastoreServerRunnerFactory.java:50
    CWE-470: Mock Issue 2 ('Mock Issue: Suser'): org/apache/sqoop/test/hive/MetastoreServerRunnerFactory.java:50
    ****************************************************************
    Total flaws found: 3, New flaws found: 2 as compared to baseline
    ****************************************************************

    ========================
    FAILURE: Found 2 issues!   
    ========================

Duplicate issues not uploaded to GitLab

When you create GitLab issues from the scan results, if the Pipeline Scan finds issues that are duplicates of issues previously uploaded to GitLab, Veracode ignores those issues, and sends only the new issues to GitLab.

In this example, the Pipeline Scan found seven issues, four of which are duplicates. Therefore, Veracode sends only the three new issues to GitLab.

Scan Summary:
PIPELINE_SCAN_VERSION: null
DEV-STAGE: DEVELOPMENT
SCAN_STATUS: SUCCESS
SCAN_MESSAGE: Scan successful. Results size: 15021 bytes
====================
Analysis Successful.
====================
===================
Analyzed 1 modules.
===================
myapp.jar
==================
Analyzed 7 issues.
==================
----------------------------------
Found 7 issues of Medium severity.
----------------------------------
CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection'): org/apache/sqoop/test/hive/MetastoreServerRunnerFactory.java:50
CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection'): org/apache/sqoop/test/hive/HiveServerRunnerFactory.java:50
CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection'): org/apache/sqoop/test/hadoop/HadoopRunnerFactory.java:35
CWE-117: Improper Output Neutralization for Logs: org/apache/sqoop/test/hadoop/HadoopRealClusterRunner.java:50
CWE-73: External Control of File Name or Path: org/apache/sqoop/test/hadoop/HadoopRealClusterRunner.java:52
CWE-117: Improper Output Neutralization for Logs: org/apache/sqoop/test/hadoop/HadoopMiniClusterRunner.java:64
CWE-117: Improper Output Neutralization for Logs: org/apache/sqoop/test/hadoop/HadoopMiniClusterRunner.java:67
========================
FAILURE: Found 7 issues!
========================
[14 oct 2020 17:06:23,0792] PIPELINE-SCAN INFO: Uploading 7 issues to GitLab
[14 oct 2020 17:06:25,0553] PIPELINE-SCAN INFO: Found 4 duplicates.

Example configuration scenarios​

Report flaws that violate policy and proceed regardless of the results​

Fail the pipeline stage if flaws violate policy (break the build)​

Fail the pipeline stage if new flaws violate policy (break the build)​

Example code for Azure DevOps​

Scan an ASP.NET application​

Add scanning to a Gradle build stage​

Add scanning to a Maven build stage​

Create and apply a baseline file​

Create a baseline file​

Apply a baseline file​

Example code for GitHub​

Add scanning to a Gradle build stage in a GitHub Actions pipeline​

Add scanning to a Maven build stage in a GitHub Actions pipeline​

Use a baseline file in a GitHub Actions pipeline​

Example code for GitLab​

Add scanning to a Gradle build stage​

Add scanning to a Gradle build stage and generate issues for findings​

Add scanning to a Gradle build stage and import findings as vulnerabilities​

Add scanning to a Gradle build stage, apply a built-in policy, and import vulnerabilities​

Add scanning to a Gradle build stage, apply a custom policy, and import vulnerabilities​

Add scanning to a Maven build stage​

Scan with a baseline file​

Example code for Jenkins​

Add scanning to a Gradle build stage​

Add scanning to a Maven build stage​

Scan with a baseline file​

Example scan results​

Default settings​

Issue details expanded​

Severity filters selected​

CWE filters selected​

Baseline filters selected​

Duplicate issues not uploaded to GitLab​

Did you find this helpful?

Example configuration scenarios

Report flaws that violate policy and proceed regardless of the results

Fail the pipeline stage if flaws violate policy (break the build)

Fail the pipeline stage if new flaws violate policy (break the build)

Example code for Azure DevOps

Scan an ASP.NET application

Add scanning to a Gradle build stage

Add scanning to a Maven build stage

Create and apply a baseline file

Create a baseline file

Apply a baseline file

Example code for GitHub

Add scanning to a Gradle build stage in a GitHub Actions pipeline

Add scanning to a Maven build stage in a GitHub Actions pipeline

Use a baseline file in a GitHub Actions pipeline

Example code for GitLab

Add scanning to a Gradle build stage

Add scanning to a Gradle build stage and generate issues for findings

Add scanning to a Gradle build stage and import findings as vulnerabilities

Add scanning to a Gradle build stage, apply a built-in policy, and import vulnerabilities

Add scanning to a Gradle build stage, apply a custom policy, and import vulnerabilities

Add scanning to a Maven build stage

Scan with a baseline file

Example code for Jenkins

Add scanning to a Gradle build stage

Add scanning to a Maven build stage

Scan with a baseline file

Example scan results

Default settings

Issue details expanded

Severity filters selected

CWE filters selected

Baseline filters selected

Duplicate issues not uploaded to GitLab