Use Veracode's new deleteincompletescan functionality

[Rocket]

Description

Sometimes Veracode scans get stuck as "incomplete". We currently have to manually log in and delete them in order for additional scans to be processed. Otherwise, Veracode will reject additional scans. In May 2021, Veracode introduced a new -deleteincompletescan flag to its Java API wrapper that will delete any stuck or incomplete scans and then run the new scan.

Acceptance Criteria

• Refactor veracode to use -deleteincompletescan flag

[Rocket]

It turns out that the deleteincompletescan flag tells a scan to delete itself if it becomes incomplete. It will not clear out any other incomplete scans. This makes it of limited use for our purposes and the most efficient way to handle Veracode issues is still to manually log in and delete stuck scans.

For future reference, if veracode were not limited to one active scan at a time and the scan times were much faster, then we could have successfully integrated it into our github CI pipeline by making the following changes to the next.js.yml github actions workflow:

# This workflow will do a clean install of repo dependencies and run tests
# For more information see: https://help.github.com/actions/language-and-framework-guides/using-nodejs-with-github-actions

name: NextJS CI

on:
  push:
    branches: [main, future, production, rocket/veracode-wip]
  pull_request:
    branches: [main, future, production]

jobs:
  build:
    runs-on: ubuntu-latest
    # Disable next.js telemetry on yarn build
    # Docs: https://nextjs.org/telemetry
    env:
      NEXT_TELEMETRY_DISABLED: 1
    steps:
      - uses: actions/checkout@v2
      - name: Install, build, test, & lint with Node.js 14
        uses: actions/setup-node@v1
        with:
          node-version: 14
      # Install, build, test, lint
      - run: npm install -g yarn
      - run: yarn install --frozen-lockfile
      - run: yarn build
      - run: yarn test
      - run: yarn lint
      # Build an artifact for scanning:
      # Tar up all the files required to run CST in production. This should be the same files as in
      # azure-pipelines.yml
      - name: Compress production files
        run: tar czvfh prod_files.tar.gz
          package.json
          .next
          node_modules
          public
          next.config.js
          next-i18next.config.js
          server-preload.js
      # Upload the tarball to pass it to the veracode job
      - uses: actions/upload-artifact@master
        with:
          name: prod_files
          path: prod_files.tar.gz

  veracode:
    runs-on: ubuntu-latest
    needs: build
    steps:
      # Download the tarball from the build job
      - uses: actions/download-artifact@master
        with:
          name: prod_files
      - name: Veracode Upload And Scan
        uses: veracode/veracode-uploadandscan-action@master
        with:
          appname: 'uiclaim.tracker'
          createprofile: false
          version: ${{ github.ref_name }}.${{ github.sha }}.${{ github.run_id }}
          vid: ${{ secrets.id }}
          vkey: ${{ secrets.key }}
          createsandbox: false
          deleteincompletescan: true
          scantimeout: 15
          # Note: Ideally, filepath should be "${{ github.workspace }}/prod_files.tar.gz"
          #   However, the context variable `github.workspace` isn't getting translated into a
          #   container (docker-in-docker) path at the right time. Instead, it's being turned
          #   path that exists in the github actions container, but outside the veracode container.
          # May be related to https://github.com/actions/runner/issues/1174
          # For now, hardcoding to the container path for workspaces.
          # See: https://github.com/actions/runner/blob/b1ecffd7070676f2a937840be99fb2ca9da69315/src/Runner.Worker/Handlers/ContainerActionHandler.cs#L188
          filepath: /github/workspace/prod_files.tar.gz

In addition, it would be possible to edit azure pipelines to use deleteincompletescan, where veracode currently lives in our CD pipeline. To do so would require not using the Veracode@3 task and instead using a custom task that downloads the Veracode Java API wrapper, accesses API credentials stored as secrets in Azure, and manually calls the API, using something like:

java -jar VeracodeJavaAPI.jar \
        -filepath *** \
        -version "***" \
        -action "uploadandscan" \
        -appname "***" \
        -vid "***" \
        -vkey "***" \
        -createsandbox="false" \
        -scantimeout "15" \
        -autoscan "true" \
        -deleteincompletescan "true" \
        -createprofile "false"