Container Security Configuration Options
The following table shows the configuration options available for the SCA scanner. These configuration options can be applied on the Account > Project > Scan levels. These configurations can be set via the web application (UI), CLI or API, as shown in the table below.
Notice
CLI flags are submitted on the scan level with the scan create command. API configs can be configured on the account or project level using the Scan Configuration APIs or on the scan level as part of the request body of the POST /scans API. When using the POST /scans API the scan.config.containers prefix is left out.
Parameter | Description | Syntax | Examples | CLI | API |
|---|---|---|---|---|---|
Scan specific images | If you would like to scan specific images, submit a comma separated list of images to be scanned. | Specify each image using the following syntax {image_name}:{image_tag}. For the syntax for images in specific registries, see Authentication for Scanning Registries Locally. | debian:11, alpine:latest | --container-images |
TipThis configuration is applied on the scan level and not as a project or tenant config. Example: "config": [
{
"type": "containers",
"value": {
"userCustomImages": "debian:11"
}
}
] |
Folder/file filter | Specify files and folders to be included (allow list) or excluded from (block list) scans. You can create complex filters that combine include and exclude patterns. NoticeFor details on the filter application logic, see here. |
TipYou can submit multiple items separated by a comma. |
|
| scan.config.containers.filesFilter Example: {
"key": "scan.config.containers.filesFilter",
"value": "*.yaml,*.yml",
"allowOverride": true
} |
Image/tag filter | Include or exclude images by image name and/or tag. NoticeFor details on the filter application logic, see here. |
TipYou can use wildcard (*) at the beginning, end or both. |
|
| scan.config.containers.imagesFilter Example: {
"key": "scan.config.containers.imagesFilter",
"value": "!*test-image*",
"allowOverride": true
} |
Package Regex Filter | Prevent sensitive packages from being sent to the cloud for analysis. Exclude packages by package name or file path using regex. TipExcluded packages will nonetheless appear in the scan results. However, no vulnerabilities will be identified in those packages since their info wasn't sent to the cloud for analysis. | Regex |
|
| scan.config.containers.packagesFilter Example: {
"key": "scan.config.containers.packagesFilter",
"value": "^internal-.*",
"allowOverride": true
} |
Exclude non-final stages filter | Exclude all images that are not from the final stage of the build process, so that only the final deployable image is scanned. TipOnly supported for Dockerfile images. | True - apply filter False - don't apply filter |
| scan.config.containers.nonFinalStagesFilter Example: {
"key": "scan.config.containers.nonFinalStagesFilter",
"value": "true",
"allowOverride": true
} |
Filter Application Logic
Filters are applied in the order they appear in the expression.
When both include and exclude filters are used, include filters must come first.
Why this order matters
If the include filters come first (correct order) the system starts with an empty selection set, then adds content from the original sources based on the include filters. The exclude filters are then applied to that populated set, successfully removing any unwanted items. The resulting, correctly filtered selection set is what gets sent for scanning.
If the exclude filters are applied first (incorrect order), the system begins with an empty selection set and attempts to remove content - which has no effect. Only afterward does it apply the include filters, adding content from the source set to the selection set. This results in the exclude rules being effectively ignored.