Skip to content

Archive File Scanning for Container Scanning

Proposal

Currently, the upstream analyzer for Container Scanning via Trivy allows the use of .tar files as a value for CS_IMAGE with a limited ability. Similar issue suggesting the support in use of .tar file image found here

For our organization's workflow, we would like to request a feature to support multiple .tar files for container scanning jobs. The current workaround has a limitation: the list of vulnerability findings across multiple images (as .tar files) does not include all duplicate findings among these images. Specifically, if a vulnerability in a particular package is found in two scan jobs, we are only able to see a single instance of that vulnerability, which is reported from the most recently completed container scanning job.

Example pipeline:

image-build:
  stage: build
  script: 
   - echo "image build"
  artifacts:
    paths:
      - image.tar

image-build-2:
  stage: build
  script: 
   - echo "image 2 build"
  artifacts:
    paths:
      - image_2.tar

container_scanning:
  variables:
    CS_IMAGE: "--input image.tar"
  needs:
    - image-build
  dependencies:
    - image-build

container_scanning_2:
  variables:
    CS_IMAGE: "--input image_2.tar"
  needs:
    - image-build-2
  dependencies:
    - image-build-2

The result of this pipeline creates two artifacts from the container scanning job, which can be individually downloaded on the vulnerability report page. However, vulnerabilities found in both individual reports are not directly reflected in the GitLab UI of the vulnerability report. Instead, it shows only one vulnerability when two identical vulnerabilities are identified across the artifacts.

Current state

The reason that the workaround --input image.tar works is due to the way we execute Trivy in Container Scanning:

      def scan_command(image_name, output_file_name)
        [
          "trivy",
          "image",
          ...
          "--output",
          output_file_name,
          image_name
        ].compact.flatten
      end

CS_IMAGE goes into image_name which is appended to the end of the command. Trivy scans .tar files using the --input flag and the file name.

Action plan

Options:

  1. Identify when the CS_IMAGE value ends with .tar and assume we should scan it as a tar file.
    1. It's possible to tag a regular image as image:tag.tar and run it as an image, without it actually being a tar file. This case would throw us off if we choose this option.
  2. Add a variable (e.g. SCAN_TAR) which can be set to true in order to scan CS_IMAGE as a .tar file. This is the chosen option.
    1. In this case, the switch between regular image scanning and tar file scanning would not be dynamic; users would have to be aware that they must set the variable.

For the second option, we may use an implementation similar to the following in lib/gcs/trivy.rb:

Click to expand 
      def scan_command(image_name, output_file_name)
        [
          "trivy",
          "image",
          ...
          scan_tar_arg,
          image_name
        ].compact.flatten
      end

      def sbom_scan_command(image_name, output_file_name)
        [
          "trivy",
          "image",
          ...
          scan_tar_arg,
          image_name
        ].compact.flatten
      end

      def scan_tar_arg
        return unless Gcs::Environment.should_scan_tar?

        [
          '--input'
        ]
      end

We should also consider how images will appear in the platform and in the produced documents, and whether their naming includes .tar or not.

Implementation steps

Edited by Yasha Rise