Skip to main content

Container Scans

In addition to scanning the packages in your source code itself, Checkmarx SCA also scans the Dockerfiles in your project to identify the container images used in your project. Checkmarx SCA extracts all layers of each image file, and identifies the packages used by each layer.

For scans run via the Checkmarx SCA web portal, Checkmarx One, or Checkmarx plugins only images hosted on public repos are scanned. For scans run using Checkmarx SCA Resolver, private repositories are also scanned as long as you are authenticated on that repo when you run the scan.

In addition to scanning the Dockerfile itself, SCA Resolver also enables scanning of the image that is created from the Dockerfile, using the Syft open source tool. This enables greater visibility into all packages used in the image for all languages supported by SCA as well as many non-supported languages (e.g., Dart, Haskell, Swift etc.).

Supported Registries

  • DockerHub

  • AWS ECR

Supported Package Managers

  • dpkg

  • apk

Viewing Container Scan Results

The Scan Results > Container tab shows the container packages identified in your project and the vulnerabilities associated with them. For a description of the info shown in the Container tab, see Container Tab.

6414631036.png

Running Container Scans Using Resolver

Running Container Scans

  1. To scan containers using Resolver, add the --scan-containers flag to the scan command.

  2. If you would like to specify images to be scanned, add the --images flag followed by a comma separated list of images.

  3. If you would like to also use Syft to scan the actual images, add the --syft flag.

Container Scan Example:

The following example shows a command to run a container scan, specifying a specific image and using Syft.

Authentication for Scanning Private Repos

In order to access private repos you need to be authenticated in your container repo when you run the scan via Checkmarx SCA Resolver. In addition, authenticating in DockerHub avoids the limits that apply to anonymous request to public repos.

Build Arguments Configuration

Some projects may contain build arguments that are required for layer resolution.

Checkmarx SCA Resolver supports use of a .env_cxsca-container-build-args file, which can be added to repository code to provide custom build-arguments to Dockerfile FROM instructions. We recommend using this file when the docker is present and the build process requires arguments in order to enhance the docker layer resolution and improve results.

The format of this file is similar to an .env file, with each line containing a single argument with an = sign between the argument key and value.

Example:

An .env_cxsca-container-build-args file with the following argument for layer resolution:

LAYER=golang
TAG=bullseye

can be used in Dockerfile as follows: FROM $LAYER:${TAG}

Hierarchy

Since many different Dockerfiles can be used inside a project, Checkmarx SCA Resolver applies a folder hierarchy. The following priority (high to low) is given to the files:

  1. Same directory .env_cxsca-container-build-args

  2. Same directory .env

  3. Parent directory .env_cxsca-container-build-args

  4. Parent directory .env

  5. Ancestor directory .env_cxsca-container-build-args

  6. Ancestor directory .env

  7. Default argument value on resolution Dockerfile

Configuring Environment Variables for AWS ECR

Resolver is configured to scan your AWS ECR repo assuming that the default values/paths are in use. If the “credentials” file is in the default AWS path, and you are using the “default” profile, then no action is needed. If you have changed these settings, then you need to configure the following environment variables.

  • AWS_PROFILE (default value: “default”)

Note

You can configure multiple profiles, e.g., for different environments.

  • AWS_CONFIG_FILE (default path: “~/.aws/config”)

  • AWS_SHARED_CREDENTIALS_FILE (default path: “~/.aws/credentials”)

See AWS SDKs and Tools

Example of Credentials File

File ““~/.aws/credentials”

[default]
aws_access_key_id=ASI
aws_secret_access_key=abcd
region=us-west -1
aws_session_token=Absd
[prod]
aws_access_key_id=AKI
aws_secret_access_key=xyz
region=us-west -1
In this section: