On November 19, Veracode published new, official Docker images for use in continuous integration pipelines. The images, which provide access to Pipeline Scan, Policy (or Sandbox) scans, and the ability to access Veracode APIs via the Java API Wrapper or via HTTPie with the Veracode API Signing tool, make it easy to include the current version of Veracode tools in your automation workflow.
Why Docker?
Providing official Docker images addresses customer feedback we’ve received regarding the use of Veracode tools in a pipeline. Without using a Docker image, a customer’s script must download the tool each time to the CI/CD runner, adding time to each run, or a customer must implement their own caching mechanism to avoid redownloading the tool every time. Also, any dependencies required by the Veracode tool, including the Java runtime or Python, must be installed on the local machine, potentially raising issues of version compatibility. Last, some continuous integration pipelines, including AWS CloudStar and TravisCI, require external testing tools to be integrated via containers.
The Veracode Docker images address these concerns. Docker automatically provides caching and makes it easy to always use the latest version available. Also, the Docker image contains any dependencies required by the Veracode tool. Last, the Docker images are supported by Veracode, addressing concerns from customers about having to write their own image or rely on a community-provided one.
Securing Docker images
The Veracode Docker image was originally designed and built by Veracode’s product security team for internal use in pipelines by Veracode development teams. The team has done the following to ensure the images are secure:
-
The Docker images are built and published to DockerHub via continuous delivery pipelines that include the most current version of each included tool and scan the images for vulnerabilities.
-
Each image is run with a de-privileged local user to avoid privilege escalation.
-
The underlying tools are developed with a secure SDLC and are tested with Veracode Static Analysis and Veracode Software Composition Analysis in their own development pipelines.
-
The images are based on well-known and widely used base images.
-
Only the prerequisites absolutely needed for downloading the tools in the images are included.
Usage examples
Here are a few samples using the images in continuous integration workflows.
GitLab examples
These examples are drawn from a single workflow that uses all three containers in different stages. (You can see the project in which the workflow is published here.)
Pipeline Scan
Pipeline Scan Static Analysis:
image: veracode/pipeline-scan:latest
stage: Security_Scan
only:
- development
script:
- java -jar /opt/veracode/pipeline-scan.jar -vid ${VERACODE_API_ID} -vkey ${VERACODE_API_KEY} --file target/verademo.war --issue_details true --gl_issue_generation true -jf results.json 2>&1 | tee pipeline_scan_text_output.txt
artifacts:
paths:
- results.json
- pipeline_scan_text_output.txt
when: always
name: "veracode-pipeline-$CI_COMMIT_REF_NAME-$CI_COMMIT_SHORT_SHA"
allow_failure: false
Sandbox Scan (using the Java API Wrapper)
Sandbox Scan Static Analysis:
image: veracode/api-wrapper-java:latest
stage: Security_Scan
only:
- release
script:
- java -jar /opt/veracode/api-wrapper.jar -vid ${TEAM_ANALYSISCENTER_ID} -vkey ${TEAM_ANALYSISCENTER_KEY}
-action UploadAndScan -appname "Verademo" -createprofile true -autoscan true -sandboxname "gitlab-release" -createsandbox true
-filepath ./target/verademo.war -version "Job ${CI_JOB_ID} in pipeline ${CI_PIPELINE_ID}" 2>&1 | tee sandbox_scan_output.txt
artifacts:
paths:
- sandbox_scan_output.txt
when: always
name: "veracode-SANDBOX-SCAN-$CI_COMMIT_REF_NAME-$CI_COMMIT_SHORT_SHA"
allow_failure: true
Dynamic Analysis (using the API Signing image)
Dynamic Analysis:
image: veracode/api-signing:latest
stage: Dynamic_Analysis
only:
- development
- release
- master
variables:
VERACODE_API_KEY_ID: ${VERACODE_API_ID}
VERACODE_API_KEY_SECRET: ${VERACODE_API_KEY}
script:
- http --auth-type veracode_hmac PUT https://api.veracode.com/was/configservice/v1/scan_occurrences/?action=RESUBMIT
GitHub example
This example is drawn from a workflow that packages the application before submitting it for Pipeline Scan. Note that this workflow is structured as three jobs that use upload-artifact to share files between jobs; only the Pipeline Scan job is shown below. (You can see the project from which the example workflow was drawn here.)
Pipeline Scan
pipeline-scan:
needs: build
runs-on: ubuntu-latest
container:
image: veracode/pipeline-scan:latest
options: --user root # our container user doesn't have privs to write to github directories
steps:
- name: Retrieve artifact
uses: actions/download-artifact@v2
with:
name: CodePackage
# Submit project to pipeline scan
- name: Pipeline Scan
run: java -jar /opt/veracode/pipeline-scan.jar --veracode_api_id="${{secrets.VERACODE_API_ID}}" --veracode_api_key="${{secrets.VERACODE_API_KEY}}" --fail_on_severity="Very High, High" --file="project.zip" --app_id="${{secrets.VERACODE_APP_ID}}" --json_output_file="results.json"
continue-on-error: true # continuing so we can post results to Security tab
- uses: actions/upload-artifact@v2
with:
name: ScanResults
path: results.json
One interesting point to note in this example is that GitHub restricts write access to the normal working directory (/github/workspace) by anything but the root user of the container. Because Veracode Docker images normally run as a user with lower privileges for security reasons, we have to work around the GitHub restriction by explicitly invoking the root user by setting options: --user root .
Conclusion
Veracode Docker images provide a convenient, simple way to include Veracode automation in your CI/CD workflows. If you have questions or want to share your own experiences, check out the Veracode Community.