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.
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
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.
- Profile to use from a Veracode API Credentials file.
- 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.
- Report scan as unsuccessful if it does not complete scanning in the given number of minutes. Defaults to
--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.
- 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
- Veracode Pipeline Scan CI tool expects you to submit a Java archive in a standard
JAR
,WAR
orEAR
format. - For more information refer to Veracode's compilation instructions for Java: https://help.veracode.com/r/compilation_java
- Upload a
ZIP
file containing.dll
,.exe
, and.pdb
files. - For
ASP.NET
: Upload aZIP
file containing allaspx.*.dll
andaspx.*.pdb
along with any traditional.dll
assemblies that were generated by theASP.NET
compiler - For more information refer to Veracode's compilation instructions for .NET: https://help.veracode.com/r/compilation_ASPnet
- 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
orEAR
) files and .NETZIPS
as well. - For more information refer to Veracode's packaging instructions for JavaScript and TypeScript: https://help.veracode.com/r/compilation_jscript
- 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
- Veracode Pipeline Scan CI tool expects you to submit a Groovy application in a standard
JAR
orWAR
format. - For more information refer to Veracode's compilation instructions for Groovy: https://help.veracode.com/r/c_compilation_groovy
- Veracode Pipeline Scan CI tool expects you to submit a Kotlin application in a standard
JAR
orWAR
format. - For more information refer to Veracode's compilation instructions for Kotlin: https://help.veracode.com/r/c_compilation_kotlin
- 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
- 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
- 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
--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, setlogger.file.additivity
totrue
:# 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
- Example using
- 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, setlogger.file.additivity
totrue
:
<?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>
- Example using
- 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.
- To use your own logging configuration file (either a .properties or .xml file), you will need to specify command line option
- Through configuration file
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.
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.
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:
- 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
- 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.
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.
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/.
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
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
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
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
# 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}"
# 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}"
# 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
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.
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
}
}
}
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
}
}
}
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()
}
}
}
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.
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"
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"
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"
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.
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'
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'
# 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'
====================
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!
=========================
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!
========================
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.
==================================
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!
========================
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!
========================
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.
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