Skip to main content

Container Security

Caution

This page describes changes that are being rolled out in waves. Contact your support agent to determine whether this functionality is available in your environment.

All changes described in this document relate only to Checkmarx One accounts. For SCA standalone users, container scan functionality will remain unchanged, see Container Scans.

Decoupling Container Security from SCA

For Checkmarx One users, the container scanning engine now functions independently from SCA. This affects how scan are triggered as well as how the results are shown. The new Container Security scanner is easier to use and provides improved functionality. A table showing the workflow changes can be viewed here.

Key Improvements

  • Simplified workflow - Scanning of built images is now done in the cloud, with no need to install additional tools.

  • Results viewer - Improved results viewer in the web application enables easy navigation to view package and vulnerability info for specific base images and layers.

  • Triage vulnerabilities - Change State and Severity level of vulnerabilities.

  • Remediation recommendations - Shows alternative versions of base images with fewer vulnerabilities.

  • In addition to vulnerable packages, this scanner also identifies malicious packages.

  • User permissions - Full support for granular user permissions.

  • Runtime usage - Prioritize remediation efforts based on runtime usage data, obtained via integration with Sysdig.

  • Scan Risk Report - Scan risk reports now contain a dedicated section for containers. This includes customized container data such as breakdown of images and layers in each scanned file.

Container Security Overview

The Container Security scanner scans the Dockerfiles in your project to identify the container images used in your project and the risks associate with those images. Checkmarx extracts all layers of each public base image located in the Dockerfile, and identifies the packages used by each layer. In addition to scanning the Dockerfile itself, we also scan 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 Checkmarx SCA as well as many non-supported languages (e.g., Dart, Haskell, Swift etc.).

In addition, you can use the Checkmarx One CLI tool to submit specific images from public or private registries for analysis.

Images in Files

  • Dockerfile base images

  • Helm charts and yaml/yml files

  • Docker-compose file images

Private Images

  • Scan images directly from private registries (using Checkmarx One CLI)

Runtime Images (Containers)

  • Integration with Sysdig for runtime analysis

Supported Registries

Container scans support scanning of images from any registry for which you can run the docker pull command, e.g., DockerHub, Amazon Elastic Container Registry (ECR), Google Container Registry (GCR), Quay, JFrog Container Registry (JCR) etc.

Supported Ecosystems

  • Debian (dpkg)

  • Alpine (apk)

  • C (conan)

  • C++ (conan)

  • Dotnet (deps.json)

  • Go (go.mod, Go binaries)

  • Java (jar, ear, war, par, sar, native-image)

  • JavaScript (npm, yarn)

  • PHP (composer)

  • Python (wheel, egg, poetry, requirements.txt)

  • Red Hat (rpm)

  • Ruby (gem)dpkg

Running Container Security Scans

A container scan can be triggered by selecting the Container Security scanner when initiating a scan via the web application, CLI or API. This will scan the Dockerfile in your project. When you run a scan via the CLI, there is an additional option to specify a specific image to be scanned from a public or private repository.

Running Scans via the Web Application

Follow the normal procedure for running a scan, making sure that the Container Security scanner is selected.

Image_867.png

Running Container Security Scans via the CLI

When running scans via the CLI you can choose to scan the project files in order to analyze the Dockerfile in your project or you can submit specific images for scanning.

Authentication for Scanning Private Repos

In order to access private repos you need to be authenticated in your container repo at the time that you run the scan via Checkmarx One CLI.

Notice

In addition, even when using public repos in DockerHub there is an advantage to authenticating your user in order to avoid the limits that apply to anonymous requests to public repos.

Authentication can be done via Docker or Podman.

Before running the scan, it is recommended to verify that you are able to access the image on your local machine.

For details about authentication for specific registries, see ???.

Scan Procedure

  1. Run the scan create command with all required parameters, and specify container-security in the --scan-types.

    ./cx scan create --project-name <Project Name> -s <Repository URL> --branch <branch name> --scan-types container-security
  2. If you want to scan only specific images (not an entire project), do the following:

    1. Create a "dummy" folder in your project (for use in the -s parameter) and give it a name that indicates that it is used for scanning images, e.g., scan_ecr_image.

    2. In the CLI scan command, for the -s parameter give the path to the "dummy" folder that you created, e.g., /Users/DemoUser/scan_ecr_image.

  3. Add the --container-images flag followed by a comma separated list of images. Specify each image using the following syntax {image_name}:{image_tag}.

    ./cx scan create --project-name <Project Name> -s <Repository URL> --branch <branch name> --scan-types container-security --container-images “mycompany/myimage:myimagetag”

    Notice

    For the syntax for images in specific registries, see ???.

Running Scans via API

You can run a Container Security scan using POST /scans. In the config section specify the type as containers.

Warning

When running the Container Security scanner together with SCA, it is recommended to include the SCA config enableContainersScan and set it as false.

Sample request body:

{
    "type": "git",
    "handler": {
        "repoUrl": "https://github.com/myOrg/demorepo",
        "branch": "demoBranch"
    },
    "project": {
        "id": "71eacb3b-ae1d-4961-a96f-2b8593ff3dc7",
        "tags": {}
    },
    "config": [
     {
      "type": "sca",
      "value": {
        "enableContainersScan": "false"
      }
    },
     {
            "type": "containers",
            "value": {}
        }
    ],
    "tags": {}
}

Viewing Container Scan Results

The Container scan results page shows info about the images identified in your project, the packages used in those images and the vulnerabilities associated with them.

The main screen shows a list of images grouped by the Dockerfile in which they were identified. For each image, info is shown about the related packages and vulnerabilities. There are also dashboard widgets showing key metrics for the selected Dockerfile.

Image_869.png

Click on an image to drill down to see detailed info about the packages and risks associated with that image.

Images and Layers Viewer

This pane contains two main sections, Images & Layers and Result Details.

Image & Layers Pane

This pane shows a separate section for each build stage showing all layers within that stage, as well as the ALL section that includes all layers. Next to each item, an icon indicates the overall risk level for that item.

This section serves as a navigation pane for the details tabs. When ALL is selected, all results are shown in the Vulnerabilities and Packages tabs. When a specific layer is selected, the Vulnerabilities and Packages tabs are filtered to show only results for that layer. The Remediation tab always shows recommendations for remediating the entire image.

Image_871.png
Malicious Packages

In addition to vulnerable packages, this scanner also identifies malicious packages.

When a malicious package is identified, that package is marked with a "malicious" icon.

Image_1130.png

You can also set the filter to show only malicious packages.

Image_1131.png

Result Details Pane

The following sections describe the info shown in each of the tabs.

Vulnerabilities Tab

This tab shows the vulnerabilities identified in each package. Click on a package to show the associated vulnerabilities. Drill down further to see details about each vulnerability.

Notice

Use the search field at the top right to search by CVE or package name. Results are filtered as you type. You can also apply filters based on runtime usage and malicious packages.

Image_872.png
Triaging Results

Important

The following permissions enable users to triage results:

  • update-result-state-not-exploitable (can change to this state only)

  • update-result-state-propose-not-exploitable (can change to this state only)

  • update-result-states (can change all states except not-exploitable; can’t change the severity)

  • update-result-severity (can change only severities)

For group related permissions, add "-if-in-group" the relevant permission, e.g., update-result-state-not-exploitable-if-in-group.

You can triage vulnerabilities by adjusting the Severity and State of the vulnerability. Hover over a vulnerability and click on the Edit button. In the dialog that opens, you can click on the Severity or State and select the value that you would like to assign from the drop-down menu. You can select different vulnerabilities within the same package and triage each of them.

Image_919.png
Bulk Action Triaging Results

You can triage multiple vulnerabilities with a single bulk action.

  1. In the Vulnerabilities tab, select the checkbox next to each vulnerability that you would like to include in the bulk action triage. Then, click on Edit Properties.

    Image_969.png

    All of the selected vulnerabilities are shown and you can click on each one to see the relevant details.

  2. Make changes to the Severity and/or State, and those changes are applied to all of the selected vulnerabilities.

    Image_970.png
Packages Tab

This tab shows a list of packages that were identified. Click on a package to show detailed information about the package.

Notice

Use the search field at the top right to search by package name. Results are filtered as you type. You can also apply filters based on runtime usage and malicious packages.

Image_873.png
Remediation Tab

This tab shows info about recommended remediation actions. When you click on a base image in the navigation pane, a list of remediated versions of that image is displayed. The remediated versions are grouped by the type of version update (Next, Minor Updates, Major Updates, Latest or Alternatives). For each suggested version, the number of resolved vulnerabilities of each severity level is displayed. This enables users to choose the version that will most effectively remediate the vulnerabilities without requiring unnecessary code refactoring.???

Image_918.png

Additional Info About Specific Registries

This section provides additional info about how to scan images from an AWS ECR registry.

Authentication for AWS ECR

Before running scans via the CLI, make sure that your AWS IAM user is authenticated, and that the token is in the credentials file (AWS_SESSION _TOKEN) as explained here. And, if you are scanning images in a different region, then make sure that the region is correctly configured in the credentials file (REGION).

Obtaining the Image Name and Tag for an AWS ECR Image

The value submitted for the --images parameter for GCR uses the following syntax {repository_uri}:{image_tag}.

The following procedure describes how to obtain these values via the CLI.

  1. To obtain the repository uri, run the CLI command aws ecr describe-repositories --repository-name {your_repo_name}, and make a note of the value returned for repositoryUri.

    ecr1.png

    Example for repo named "container-comparer"

  2. To obtain the image tags of the images in the repo, run the CLI command aws ecr list-images --repository-name {your_repo_name}, and make a note of the value returned for ImageTag for the desired image.

    MicrosoftTeams-image__32_.png

    Example for repo named "container-comparer"

  3. Run the CLI command with the --images flag specifying the desired images using the syntax {repository_uri}:{image_tag}. For example:

    --images 006765415138.dkr.ecr.us-east-1.amazonaws.com/container-comparer:2021.10.18.1155-8aefe81 
    

Configuring Environment Variables for AWS ECR

The Checkmarx One CLI 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

This section provides additional info about how to scan images from a GAR registry.

Authentication for GAR

Before running scans via the CLI, make sure that you are authenticated in GAR. ou can test this by running the docker pull command for the desired image. Learn about possible authentication methods here.

The recommended authentication is using gcloud.

To authenticate using gcloud:

  • If it is the first time that you are pulling images, run the following command on your machine gcloud auth configure-docker us-docker.pkg.dev

    Notice

    This command assumes that you are using the US region of GAR. If you are using a different region, then replace "us" with the name of your region.

Obtaining the Image Name and Tag for a GAR Image

The value submitted for the --images parameter for GAR uses the following syntax {gar_region}-docker.pkg.dev/{project_id}/{image_name}:{image_tag}.

  1. Obtain the values needed to identify this image.

  2. Run the CLI command with the --scan-containers flag, and add the --images flag specifying the desired images using the syntax gcr.io/{project_id}/{image_name}:{image_tag}. For example:

    --images us-docker.pkg.dev/symbolic-eye-1234/quickstart-image:tag1
    

This section provides additional info about how to scan images from a GCR registry.

Authentication for GCR

Before running scans via the CLI, make sure that you are authenticated in GCR. You can test this by running the docker pull command for the desired image. Learn about possible authentication methods here.

The recommended authentication is using gcloud.

To authenticate using gcloud:

  1. Log in to gcloud as the user that will run Docker commands and run the command gcloud auth login.

  2. Configure Docker using the following command gcloud auth configure-docker.

    Your credentials are saved in your user home directory.

    • Linux: $HOME/.docker/config.json

    • Windows: %USERPROFILE%/.docker/config.json

Obtaining the Image Name and Tag for a GCR Image

The value submitted for the --images parameter for GCR uses the following syntax gcr.io/{project_id}/{image_name}:{image_tag}.

  1. Obtain the value needed to identify this image. The following is on possible method for obtaining this info:

    • Open ECR in the Google Cloud portal and navigate to the image and tag of the desired image. Then, in the PULL tab, copy the value given in the Pull by tag snippet (without the "docker pull" command).

      MicrosoftTeams-image__33_.png
  2. Run the CLI command with the --images flag specifying the desired images using the syntax gcr.io/{project_id}/{image_name}:{image_tag}. For example:

    ./ScaResolver -s /Users/DemoUser/scan_gcr_image -n DemoImageScan -a Checkmarx -u jack -p 'demo123!' --scan-containers --images gcr.io/symbolic-eye-1234/quickstart-image:tag1

Sysdig Integration - Runtime Usage

We have implemented a new integration with Sysdig Risk Spotlight, which identifies runtime usage of container packages. Once the integration is configured, the runtime usage data that was identified by Sysdig is shown as part of the Checkmarx scan results. This provides important insights for prioritizing remediation activities based on actual risk of exploitation.

Prerequisites

  • You need to have a Sysdig license and you need to obtain a Sysdig Risk Spotlight Token for your account.

  • Make sure that your Sysdig agents are configured to cover all images that you will be scanning in Checkmarx.

Limitations

Sysdig doesn't provide runtime data for base-images.

Setting up the Integration

The integration needs to be configured by Checkmarx personnel. Please contact your Checkmarx account agent and provide them with:

  • The base URL for your Sysdig region (e.g., https://us2.app.sysdig.com)

  • Your Sysdig Risk Spotlight token

  • Cluster name (optional)

Viewing Runtime Data

Once the integration has been configured for your account, whenever you run a scan on an image that is covered by your Sysdig deployment, the Checkmarx scan results will be supplemented with the runtime data.

On the Container Scan Results screen, there is a column Runtime which indicates which packages are used in runtime.

Possible values for Runtime Usage are:

  • Used - Runtime usage of this package was identified.

  • Not Used - No runtime usage of this package was identified.

  • Not Eligible - Runtime analysis isn’t supported for this package (for example, base-images aren't scanned by Sysdig).

  • Not Found - We couldn’t identify runtime usage because this package isn’t covered by your runtime security integration. Try adjusting the configuration of your runtime security integration so that all relevant clusters are covered.

Image_911.png