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.
 |
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
Run the
scan createcommand with all required parameters, and specifycontainer-securityin the--scan-types../cx scan create --project-name <Project Name> -s <Repository URL> --branch <branch name> --scan-types container-security
If you want to scan only specific images (not an entire project), do the following:
Create a "dummy" folder in your project (for use in the
-sparameter) and give it a name that indicates that it is used for scanning images, e.g., scan_ecr_image.In the CLI scan command, for the
-sparameter give the path to the "dummy" folder that you created, e.g.,/Users/DemoUser/scan_ecr_image.
Add the
--container-imagesflag 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.
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.
 |
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.
 |
You can also set the filter to show only malicious packages.
 |
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.
 |
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.
 |
You can triage multiple vulnerabilities with a single bulk action.
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.
All of the selected vulnerabilities are shown and you can click on each one to see the relevant details.
Make changes to the Severity and/or State, and those changes are applied to all of the selected vulnerabilities.
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.
 |
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.???
 |
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.
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 forrepositoryUri.
Example for repo named "container-comparer"
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 forImageTagfor the desired image.
Example for repo named "container-comparer"
Run the CLI command with the
--imagesflag 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”)
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.devNotice
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}.
Obtain the values needed to identify this image.
Run the CLI command with the
--scan-containersflag, and add the--imagesflag 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:
Log in to gcloud as the user that will run Docker commands and run the command
gcloud auth login.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}.
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).
Run the CLI command with the
--imagesflag 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.
