Skip to main content

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

userCustomImages

Tip

This 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.

Notice

For details on the filter application logic, see here.

*.abc - include specific file types

!*.abc - exclude specific file types

!/folder-name/ - exclude a specific folder

Tip

You can submit multiple items separated by a comma.

!Dockerfile* - exclude all Dockerfiles in the root folder

*.yaml,*.yml - include all yaml and yml files

--containers-file-folder-filter <string>

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.

Notice

For details on the filter application logic, see here.

image-name:image-tag - include by image name and tag

image-name - include by image name

!:image-tag - exclude by image tag

Tip

You can use wildcard (*) at the beginning, end or both.

!*test-image* - to exclude all images that contain "test-image" in their name

!:*latest - to exclude all image tags that end with "latest"

--containers-image-tag-filter <string>

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.

Tip

Excluded 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

^internal-.* - filters out any package names starting with "internal-"

--containers-package-filter <string>

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.

Tip

Only supported for Dockerfile images.

True - apply filter

False - don't apply filter

--containers-exclude-non-final-stages

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.