Veracode Pipeline Scan CI Tool -- updated -- updated

sdfwertwert wqefrwqerqwer wqerqwrqwre werqwerqwerwqerqwerewqrtwetwer rtzerzerzt wqerqwerqwerqwer Veracode Pipeline Scan CI tool scans a prebuilt binary file for analysis.

The only pre-requisites are Java 8 and the project being built (gradle build or maven verify, for example, has been run and the build outputs are available to the tool) before attempting to scan.

About

The pipeline-scan CI tool is designed to be used in a CI/CD pipeline to submit a binary to Veracode for security scanning. It supports scans for Java, JavaScript, Scala, Kotlin, Groovy and Android code.

For more information on Pipeline Scan visit Veracode Help Center Page: https://help.veracode.com/reader/tS9CaFwL4_lbIEWWomsJoA/ovfZGgu96UINQxIuTqRDwg

Usage

The latest version will always be available at https://downloads.veracode.com/securityscan/pipeline-scan-LATEST.zip. This ZIP file contains this README, and a single JAR (pipeline-scan.jar) that contains all dependencies besides the required Java 8+ JVM.

Intended usage is to add a job to your CI/CD pipeline, after a build job, that downloads and unzips the tool, and then runs the JAR via java -jar. The status code returned depends on the results of the scan:

When the Pipeline Scan has completed:
- If no issues are found, the tool returns a status code of 0 and the pipeline should pass.
- If issues are found, the tool returns a status code equal to the number of flaws found (up to 200), and the pipeline should fail.
- If the scan fails (network issues, invalid API credentials, etc), the tool will return -1 and the pipeline should fail.
- If the scan does not complete within the service's maximum allowed time, the tool will return -2 and the pipeline should fail.
- If the scan does not complete within the user specified time (via the --timeout option), the tool will return -3 and the pipeline should fail.

The tool will need some information passed to it as command line arguments (many are optional):

Required
- One and only one of the following 2 options are allowed:
- --file <filename>
- The build artifact file to upload and scan
- --request_policy <policy name>
- The name of the custom platform policy that will be downloaded. A scan will not happen. This can not be a Veracode builtin policy. The name of the policy file is by convention the name of the policy with spaces replaced by underscores and .json appended.
Very Common
- --veracode_api_id <id> --veracode_api_key <key>
- Veracode API Credentials. Used to pass Veracode API ID and Key as command line arguments. Takes precedence over Veracode API Credentials file.
- --veracode_profile <profile>
- Profile to use from a Veracode API Credentials file. default is used if no credentials are provided.
Common
- --project_[name|url|ref] <project_info> | --app_id <app_id> | --development_stage <development_stage>
- will be appended to the results JSON and summary outputs for easy organization. They can also be included in any reports generated by Veracode for users.
- --fail_on_severity "Very High, High"
- Only fail if flaws of Very High or High severity are found.
- --fail_on_cwe "80"
- Also fail if a CWE-80: (XSS) flaw is found. (It is Medium severity and thus would be filtered out by the above option)
- --baseline_file <baseline file path>
- Used to ignore the flaws that exists in the baseline JSON file and show only the new flaws that got introduced in the next iteration of the scan.
- --policy_name <builtin policy name>
- --policy_file <previously downloaded policy file>
- --timeout <minutes>
- Report scan as unsuccessful if it does not complete scanning in the given number of minutes. Defaults to 60 minutes.
- --include <module name regular expression>
- Enter a case-sensitive, comma-separated list of name patterns that represent the names of the modules to scan as top-level modules. Veracode identifies these modules during prescan. The wildcard matches zero or more characters. The ? wildcard matches exactly one character. For example, to include various module names that contain module: --include "module 1, module-, module2.jar" The scan results show the names of the modules that Veracode identified and the modules included in the scan. This parameter does not pause, stop, or impact the performance of your pipeline.

There are two ways of providing Veracode API credentials to the Pipeline Scan CI tool:

Passing command line arguments --veracode_api_id <id> and --veracode_api_key <key> directly. This method takes precedence over credentials file.
Specifying profile name from Veracode API credentials file in --veracode_profile <profile> argument.

Note: In case both --veracode_api_id <id> --veracode_api_key <key> and --veracode_profile <profile> are not provided, CI tool will look for default profile in Veracode API credentials file.

The default settings (supplying only the upload file, and valid credentials from either an API Credentials file or using the API Credentials parameters) will direct the tool to:

Report of scanned modules.
Report for any issues of any severity of Very Low or higher.
Display a summary of the results on the console.
Write results JSON to storage, where it can then be manipulated (saved, processed, sent, etc) by the pipeline.

Binary Packaging Instructions

Packaging Requirements for Pipeline Scan

Veracode requires that you follow packaging instructions to ensure that your application meets all requirements for successful uploads.
For more information refer to Veracode's instructions: https://help.veracode.com/r/c_pipeline_scan_packaging

Java

Veracode Pipeline Scan CI tool expects you to submit a Java archive in a standard JAR, WAR or EAR format.
For more information refer to Veracode's compilation instructions for Java: https://help.veracode.com/r/compilation_java

.NET

Upload a ZIP file containing .dll, .exe, and .pdb files.
For ASP.NET: Upload a ZIP file containing all aspx.*.dll and aspx.*.pdb along with any traditional .dll assemblies that were generated by the ASP.NET compiler
For more information refer to Veracode's compilation instructions for .NET: https://help.veracode.com/r/compilation_ASPnet

JavaScript

Upload a ZIP file containing JavaScript source code, or files that contain JavaScript.
Veracode extracts and scans JavaScript code in your Java archive (JAR, WAR or EAR) files and .NET ZIPS as well.
For more information refer to Veracode's packaging instructions for JavaScript and TypeScript: https://help.veracode.com/r/compilation_jscript

Scala

Veracode Pipeline Scan CI tool expects you to submit a Scala application in a standard JAR format.
For more information refer to Veracode's compilation instructions for Scala: https://help.veracode.com/r/compilation_scala

Groovy

Veracode Pipeline Scan CI tool expects you to submit a Groovy application in a standard JAR or WAR format.
For more information refer to Veracode's compilation instructions for Groovy: https://help.veracode.com/r/c_compilation_groovy

Kotlin

Veracode Pipeline Scan CI tool expects you to submit a Kotlin application in a standard JAR or WAR format.
For more information refer to Veracode's compilation instructions for Kotlin: https://help.veracode.com/r/c_compilation_kotlin

Android

Veracode Pipeline Scan CI tool expects you to submit an Android application in a standard APK format.
For more information refer to Veracode's compilation instructions for Android: https://help.veracode.com/r/compilation_android

Python

Veracode Pipeline Scan CI tool expects you to upload a ZIP file containing .py files.
For more information refer to Veracode's compilation instructions for Python: https://help.veracode.com/r/compilation_python

PHP

Veracode Pipeline Scan CI tool expects you to upload a ZIP file containing .php files.
For more information refer to Veracode's compilation instructions for PHP: https://help.veracode.com/r/compilation_php

Logging

--verbose adds detailed console output during scanning.

The default log configuration included in the pipeline-scan jar package only log to the console. Configuration of Log4j 2 can be accomplished in 1 of 3 ways to customize additional logging functions (including writing to a log file), these approaches will override any command line options:

Through configuration file pipeline.scan.log4j2.properties

Example using pipeline.scan.log4j2.properties: to output normally to console and output verbose/debug messages to a file (Note: when you want to turn on debug for console as well, set logger.file.additivity to true :

# Extra logging related to initialization of Log4j
# Set to debug or trace if log4j initialization is failing
status = warn
# Name of the configuration
name = ConsoleLogForPipelineScan
# Define the output file, e.g. logs/pipeline-scan.log, pipeline-scan.log
property.filename = pipeline-scan.log

# Console appender configuration
appender.console.type = Console
appender.console.name = consoleLogger
appender.console.layout.type = PatternLayout
appender.console.layout.pattern = [%d{dd MMM yyyy HH:mm:ss,SSSS}] PIPELINE-SCAN %p: %m %n

# File appender configuration
appender.file.type = File
appender.file.name = fileLogger
appender.file.fileName = ${filename}
appender.file.layout.type = PatternLayout
appender.file.layout.pattern = [%d{dd MMM yyyy HH:mm:ss,SSSS}] PIPELINE-SCAN %p: %m %n

logger.file.name=PIPELINE_SCAN
logger.file.level = debug
logger.file.additivity = false
logger.file.appenderRef.file.ref = fileLogger

rootLogger.level = info
rootLogger.appenderRef.stdout.ref = consoleLogger

Through configuration file log4j2.xml, you will need to specify command line option -Dlog4j.configurationFile=[path-to]/log4j2.xml when running pipeline-scan:

Example using log4j2.xml: to output normally to console and output verbose/debug messages to a file (Note: when you want to turn on debug for console as well, set logger.file.additivity to true :

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN">
<Appenders>
    <Console name="Console" target="SYSTEM_OUT">
        <PatternLayout pattern="%d{HH:mm:ss.SSS} %-5level - %msg%n"/>
    </Console>
    <File name="File" fileName="pipeline-scan.log" append="true">
        <PatternLayout>
            <Pattern>%d{HH:mm:ss.SSS} [%t] %-5level - %msg%n</Pattern>
        </PatternLayout>
    </File>
</Appenders>
<Loggers>
    <Logger name="PIPELINE_SCAN" level="debug" additivity="false">
        <AppenderRef ref="File"/>
    </Logger>
    <Root level="info">
        <AppenderRef ref="Console"/>
    </Root>
</Loggers>
</Configuration>

Through any configuration file you create with any name:
To use your own logging configuration file (either a .properties or .xml file), you will need to specify command line option -Dlog4j.configurationFile=[path-to-config-file] when running pipeline-scan.

Notes

If the results size is very large, the results may be truncated before being received by this tool. If so, there will be a warning message displayed, and the results (in JSON and Summary) output by the tool will be a subset of the total results for the scan.

The number of scans is limited to 6 scans per minute per user account.

Examples

Generic

To use the pipeline scan:

Include the JAR file you downloaded from pipeline-scan-LATEST.zip.
After a build stage, add a stage that runs the Pipeline Scan JAR using java -jar, and passes the relevant command parameters.

GitLab & Gradle

If the pipeline scan finds any flaws, it returns status code >=1 (greater than or equal to 1), indicating the number of flaws found, and fails the Pipeline Scan stage. The exit code will report the number of flaws (up to 200). If you include the --fail_on_severity or the --fail_on_cwe parameter, the pipeline scan counts only flaws matching the defined failure parameters. Note: Veracode recommends that you download pipeline-scan-LATEST.zip each time a job is run, to ensure that you are using the latest version of pipeline scan. Alternatively, cache this file locally on your CI system and download it at a regular interval. All examples provided include a step of downloading and extracting the latest pipeline scan distributable.

Here are some common scenarios of how you may wish to configure Pipeline Scan to initiate scans. All are based on setting up Pipeline Scan as a step after the application has been built:

Report policy-violating flaws, but proceed regardless of the results

Initiate Pipeline Scan on the built application, defining the policy criteria with the "-fs" and "-fc" parameters
After the Pipeline Scan stage runs, proceed to the next stage, ignoring any exit code from the Pipeline Scan stage
- This is sometimes called "Allow Failure"; implementation details vary for each CI system

Fail the pipeline stage (aka "Break the Build") if any policy violating flaws are found

Initiate Pipeline Scan on the built application, defining the policy criteria with the "-fs" and "-fc" parameters
The Pipeline Scan stage will fail if any flaws matching the defined criteria are found
- The number of flaws (up to 200) is reported by the exit code
The Pipeline Scan stage will pass if no flaws matching the defined criteria are found.

Fail the pipeline stage (aka "Break the Build") if any newly-identified policy violating flaws are found

Include a scan baseline file either as an artifact from a prior build, or from the project repository, defining the existing set of known flaws
Initiate Pipeline Scan on the built application, defining the policy criteria with the "-fs" and "-fc" parameters and including the baseline file with the "-bf" parameter
The Pipeline Scan stage will fail if any flaws matching the defined criteria are found that are not present in the baseline file
- The number of flaws (up to 200) is reported by the exit code
The Pipeline Scan stage will pass if no flaws are found that match the defined criteria, or if all the flaws found are present in the baseline file

You can use a baseline file to establish a baseline set of scan results. The pipeline scan evaluates only flaws that differ from those 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.

GitLab

Pipeline scan can be added as a job in a GitLab Pipeline. GitLab Pipeline jobs are configured by means of YAML configuration files. The YAML code below provide examples of how to configure a pipeline to build a project and run Pipeline Scan as a stage in the pipeline.

GitLab Integrations

In order to automatically generate GitLab vulnerabilities, the GitLab repository must have a GitLab Gold / Ultimate license. In order to automatically generate GitLab issues, no premium GitLab subscriptions are needed. An API access token for the GitLab repository must be generated and set as a variable in the CI/CD settings with the key PRIVATE_TOKEN.

Before running a Pipeline Scan of a Java application using the --gl_issue_generation parameter to generate GitLab issues, you must define environment variables for the filepaths of the base directories.

In your GitLab environment:

Set these environment variables:
- SRC_ROOT: the filepath typically is /src/main/java/.
- JSP_ROOT: the filepath typically is /src/main/webapp/.

GitLab & Gradle (with automatic vulnerability generation)

We use this structure in GitLab CI to self-test, setting the $VERACODE_API_* variables in the CI/CD Settings.

# image must have JDK8+, gradle, curl, unzip
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

GitLab & Gradle (with automatic vulnerability generation with builtin policy)

We use this structure in GitLab CI to self-test, setting the $VERACODE_API_* variables in the CI/CD Settings. The builtin --policy_name option or --policy_file options are used as a replacement for the --file_on_severity and --fail_on_cwe filters

# image must have JDK8+, gradle, curl, unzip
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

GitLab & Gradle (with automatic vulnerability generation with custom policy)

A previously downloaded and packaged policy file can be specified then used in the pipeline. To download policy locally for later use in the pipeline, use the --request_policy option as in the following example:

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

The locally generated policy file will be automatically given the name Custom_Policy.json. It should be placed in a location accessible to the pipeline for its subsequent use. The --policy_file option will be used to specify the local custom policy for vulnerability filtering as before:

# image must have JDK8+, gradle, curl, unzip
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

GitLab & Gradle (with automatic issue generation)

We use this structure in GitLab CI to self-test, setting the $VERACODE_API_* variables in the CI/CD Settings.

# image must have JDK8+, gradle, curl, unzip
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

GitLab & Gradle

# image must have JDK8+, gradle, curl, unzip
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}"

GitLab & Maven

# image must have JDK8+, gradle, curl, unzip
image: <image-with-above-requirements>

stages:
  - build
  - scan

build_job:
  stage: build
  script:
    - maven 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"
      --gitlab_api_token "${PRIVATE_TOKEN}"
      --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}"

Storing and using a baseline file with GitLab

# image must have JDK8+, gradle, curl, unzip
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

Jenkins

Pipeline Scan can be added as a job in a Jenkins Declarative Pipeline. Jenkins pipelines can be configured with a "Jenkinsfile" that defines stages of running it. The code below provide examples of how to configure Jenkins to build a project and run Pipeline Scan as a stage in the pipeline.

Jenkins & 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
    }
  }
}

Jenkins & 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
    }
  }
}

Storing and using a baseline file with Jenkins

This is just one example of how to use a baseline file. It uses a single pipeline for the build and Pipeline Scan process, then stores the baseline file as an artifact each time a job is run. This can be modified so that the Pipeline Scan can run as its own pipeline and be triggered by another job. Depending on your build configuration it may also be desirable to store results in separate globally accessible location such as a shared directory, S3, etc.

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()
        }
    }
}

GitHub

Pipeline Scan can be added as a step in a Github Actions workflow. GitHub Action workflows are configured by by YAML configuration files. The YAML code below provide examples of how to configure a workflow to build a project and run Pipeline Scan as a step in the workflow.

GitHub Actions & 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"

Github Actions & 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"

Storing and using baseline file with Github Actions

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"

Azure DevOps

Pipeline scan can be added as a job in an Azure DevOps Pipeline. AzureDevOps Pipelines are customized with YAML file that defines steps of running the pipeline. The YAML code below provide examples of how to configure AzureDevOps to build a project and run Pipeline Scan as a stage in the pipeline.

Azure DevOps YAML Pipeline & 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'

Azure DevOps YAML Pipeline & Maven


trigger:
- master

pool:
  vmImage: 'ubuntu-latest'

steps:
# Maven
# Build, test, and deploy with Apache Maven
- task: Maven@3
  inputs:
    mavenPomFile: 'pom.xml'
    goals: 'package' # Optional
    options: # Optional
    publishJUnitResults: true
    testResultsFiles: '**/surefire-reports/TEST-*.xml' # Required when publishJUnitResults == True
    testRunTitle: # Optional
    codeCoverageToolOption: 'None' # Optional. Options: none, cobertura, jaCoCo. Enabling code coverage inserts the `clean` goal into the Maven goals list when Maven runs.
    codeCoverageClassFilter: # Optional. Comma-separated list of filters to include or exclude classes from collecting code coverage. For example: +:com.*,+:org.*,-:my.app*.*
    codeCoverageClassFilesDirectories: # Optional
    codeCoverageSourceDirectories: # Optional
    codeCoverageFailIfEmpty: false # Optional
    javaHomeOption: 'JDKVersion' # Options: jDKVersion, path
    jdkVersionOption: 'default' # Optional. Options: default, 1.11, 1.10, 1.9, 1.8, 1.7, 1.6
    jdkDirectory: # Required when javaHomeOption == Path
    jdkArchitectureOption: 'x64' # Optional. Options: x86, x64
    mavenVersionOption: 'Default' # Options: default, path
    mavenDirectory: # Required when mavenVersionOption == Path
    mavenSetM2Home: false # Required when mavenVersionOption == Path
    mavenOptions: '-Xmx1024m' # Optional
    mavenAuthenticateFeed: false
    effectivePomSkip: false
    sonarQubeRunAnalysis: false
    sqMavenPluginVersionChoice: 'latest' # Required when sonarQubeRunAnalysis == True# Options: latest, pom
    checkStyleRunAnalysis: false # Optional
    pmdRunAnalysis: false # Optional
    findBugsRunAnalysis: false # Optional
- 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'

Storing and using a baseline file with Azure DevOps


# generate baseline
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" --json_output_file="baseline.json" || true
  env:
    VERACODE_API_ID: $(VERACODE_API_ID)
    VERACODE_API_KEY: $(VERACODE_API_KEY)
  displayName: 'Run Pipeline Scan'
- publish: $(System.DefaultWorkingDirectory)/baseline.json
  artifact: baseline

# use baseline
trigger:
- master

pool:
  vmImage: 'ubuntu-latest'

steps:
- 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
- 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"
  env:
    VERACODE_API_ID: $(VERACODE_API_ID)
    VERACODE_API_KEY: $(VERACODE_API_KEY)
  displayName: 'Run Pipeline Scan'

Example Summary Output

Default Summary

====================
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

Using --issue_details=true

====================
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

Using --fail_on_severity="Very High, High"

**Note: GitLab sometimes strips quotes when expanding variables, thus exposing any spaces in the variable to the shell, and the entire parameter will not be set correctly if it contains spaces. If the filter arguments are in a variable, you may need to remove all spaces from the parameter (the tool can handle filter parameters both with and without spaces).

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

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

==================
Analyzed 1 issues.
==================
----------------------------------
Skipping 1 issues of Low Severity.
----------------------------------

==================================
SUCCESS: No issues passed filters.
==================================

CWE Filters

Using --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

Using --baseline [baseline_file_path]

====================
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: Soumyadeep Sinha'): org/apache/sqoop/test/hive/MetastoreServerRunnerFactory.java:50
****************************************************************
Total flaws found: 3, New flaws found: 2 as compared to baseline
****************************************************************

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

Command Line Arguments Details

usage: java -jar pipeline-scan.jar
       [-h] [-v] (-f FILE | -rp REQUEST_POLICY) [-prof VERACODE_PROFILE] [-vkey VERACODE_API_KEY] [-vid VERACODE_API_ID]
       [-fs FAIL_ON_SEVERITY] [-fc FAIL_ON_CWE] [-bf BASELINE_FILE] [-t TIMEOUT]
       [-id {true,false}] [-sd {true,false}] [-jd {true,false}] 
       [-so {true,false}] [-sf SUMMARY_OUTPUT_FILE] [-jo {true,false}] [-jf JSON_OUTPUT_FILE]
       [-p PROJECT_NAME] [-u PROJECT_URL] [-r PROJECT_REF] [-aid APP_ID] [-ds {Development,Testing,Release}]
       [-gig {true,false}] [-gvg {true,false}]
       [-pn POLICY_NAME | -pf POLICY_FILE]

Scan a pre-built JAR with Veracode Pipeline Scan CI Tool.

Results JSON will always be output to file storage. A human-readable summary will also be output to file storage
if the results contain any findings.

Either or both can also be displayed on the console as well, see the help [-h] for details. Adding '-Dpipeline.
debug=true' to the java command will increase verbosity of the console output.

Named Arguments:
  -h, --help             Show this help message and exit.
  -v, --version          Display version info and exit.

Required:
  -f FILE, --file FILE   File to upload and scan.
    OR
  -rp REQUEST_POLICY, --request_policy REQUEST_POLICY
                           Name of the policy to be download.
Credentials:
  -prof VERACODE_PROFILE, --veracode_profile VERACODE_PROFILE
                         Identify which Veracode API credentials file provides your API credentials. Defaults to the default profile.
  -vkey VERACODE_API_KEY, --veracode_api_key VERACODE_API_KEY
                         Veracode API Key.
  -vid VERACODE_API_ID, --veracode_api_id VERACODE_API_ID
                         Veracode API ID.

Scan Configuration:
  -fs FAIL_ON_SEVERITY, --fail_on_severity FAIL_ON_SEVERITY
                         Set analysis to fail for issues of the given severities. Comma-separated list of
                         severities, in quotes. Example: '--fail_on_severity="Very High, High"' would only report
                         if issues of severity 'Very High' or 'High' exist in the scan. The default is to report
                         issues of Severities Very Low and above. (default: "Very High, High, Medium, Low, Very
                         Low")
  -fc FAIL_ON_CWE, --fail_on_cwe FAIL_ON_CWE
                         Set analysis to fail for the given CWEs. Comma-separated list of severities, Example: '--
                         fail_on_cwe=95,100,978' would only report if issues of CWEs 95, 100, or 978, exist in the
                         scan. The default is to report issues of all CWEs.
  -bf BASELINE_FILE, --baseline_file BASELINE_FILE
                         Provide the baseline file.
  -t TIMEOUT, --timeout TIMEOUT
                         User timeout from CI tool. (default: 60)                        

Results Display:
  -id {true,false}, --issue_details {true,false}
                         Show detailed messages for each issue in the results summary. (default: false)
  -sd {true,false}, --summary_display {true,false}
                         Show human-readable results summary on the console. (default: true)
  -jd {true,false}, --json_display {true,false}
                         Show the results JSON on the console. (default: false)

Saving Results:
  -so {true,false}, --summary_output {true,false}
                         Save human-readable results summary to file. (default: false)
  -sf SUMMARY_OUTPUT_FILE, --summary_output_file SUMMARY_OUTPUT_FILE
                         Filename (in the current directory) to save results summary. (default: results.txt)
  -jo {true,false}, --json_output {true,false}
                         Save results JSON to file. (default: true)
  -jf JSON_OUTPUT_FILE, --json_output_file JSON_OUTPUT_FILE
                         Filename (in the current directory) to save results JSON. (default: results.json)
  -gig {true,false}, --gl_issue_generation {true,false}
                         Create GitLab issues from the scan results. (default: false)

                        In order to use the issue generation feature, the API path should be configured correctly as a CI/CD variable:
                        `GITLAB_URL` = "https://{GitLab Domain}/api/v4/projects/". This value defaults to "https://gitlab.com/api/v4/projects/".
  -gvg {true,false}, --gl_vulnerability_generation {true,false}
                         Create a JSON file from scan results that is automatically imported as GitLab vulnerablities.(default: false)

                         In order to use vulnerability generation `veracode_gitlab_vulnerabilities.json` must be saved as an artifact
                         and set as a `sast` file under the `reports` heading in the CI/CD configuration. An example can be seen in the
                         the 'GitLab & Gradle (with automatic vulnerability generation)' example.

Veracode Platform Policy:
  -pn POLICY_NAME, --policy_name POLICY_NAME
                         Name of the Veracode Platform Policy to be applied to the scan results.
  -pf POLICY_FILE, --policy_file POLICY_FILE
                         Name of the local policy file to be applied to the scan results.

Project Metadata:
  Optional: Details about the project. Will be attached to the results summary and results JSON, and stored on the
  Veracode backend for reporting purposes.

  -p PROJECT_NAME, --project_name PROJECT_NAME
                         Project name.
  -u PROJECT_URL, --project_url PROJECT_URL
                         Source control URI.
  -r PROJECT_REF, --project_ref PROJECT_REF
                         Source control ref/revision/branch.
  -aid APP_ID, --app_id APP_ID
                         Veracode Platform Application ID.
  -ds {Development,Testing,Release}, --development_stage {Development,Testing,Release}
                         Development Stage.

Policy Names

The following Veracode Policy names can be used to perform scan pass/fail filtering

PCI 3.2.1
Veracode Recommended High
Veracode Recommended High + SCA
Veracode Recommended Low
Veracode Recommended Medium
Veracode Recommended Medium + SCA
Veracode Recommended Mobile Policy
Veracode Recommended Very High
Veracode Recommended Very High + SCA

julz0815 / test-action

readme

Veracode Pipeline Scan CI Tool -- updated -- updated

About

Usage

Binary Packaging Instructions

Packaging Requirements for Pipeline Scan

Java

.NET

JavaScript

Scala

Groovy

Kotlin

Android

Python

PHP

Logging

Notes

Examples

Generic

GitLab & Gradle

Report policy-violating flaws, but proceed regardless of the results

Fail the pipeline stage (aka "Break the Build") if any policy violating flaws are found

Fail the pipeline stage (aka "Break the Build") if any newly-identified policy violating flaws are found

GitLab

GitLab Integrations

GitLab & Gradle (with automatic vulnerability generation)

GitLab & Gradle (with automatic vulnerability generation with builtin policy)

GitLab & Gradle (with automatic vulnerability generation with custom policy)

GitLab & Gradle (with automatic issue generation)

GitLab & Gradle

GitLab & Maven

Storing and using a baseline file with GitLab

Jenkins

Jenkins & Gradle

Jenkins & Maven

Storing and using a baseline file with Jenkins

GitHub

GitHub Actions & Gradle

Github Actions & Maven

Storing and using baseline file with Github Actions

Azure DevOps

Azure DevOps YAML Pipeline & Gradle

Azure DevOps YAML Pipeline & Maven

Storing and using a baseline file with Azure DevOps

Example Summary Output

Default Summary

Issue Details Expanded

Severity Filters

CWE Filters

Baseline Filters

Command Line Arguments Details

Policy Names