CI/CD With Veracode Docker Images

CI/CD With Veracode Docker Images

Tim Jarrett By Tim Jarrett
December 3, 2020

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/[email protected]
      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/[email protected]
      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.

Demo walkthrough video

Tim Jarrett is Senior Director of Product Marketing at Veracode. A Grammy-award winning product professional, he joined Veracode in 2008 and has a Bacon number of 3. He can be found on Twitter as @tojarrett.