Scanning

Introduction

This section describes common configuration options for image and SBOM scanning.

Limiting Image Size

Anchore Enterprise can be configured to have a size limit for images being added for analysis. Images that exceed the configured maximum size will not be added to Anchore Enterprise and the catalog service will log an error message providing details of the failure. This size limit is applied when adding images to Anchore Enterprise via AnchoreCTL, tag subscriptions, and repository watchers.

By default the max_compressed_image_size_mb feature is disabled.

This limit can be enabled via the max_compressed_image_size_mb property in the Anchore Enterprise configuration file or by using the ANCHORE_MAX_COMPRESSED_IMAGE_SIZE_MB env variable.

When a value greater than zero is supplied, the value represents the size limit in MB of the compressed image.
When a value less than zero is supplied, it will disable the feature and allow images of any size to be added to Anchore Enterprise.
A value of 0 will prevent any images from being added.
Finally, non-integer values will cause bootstrap of the service to fail.

If using Docker Compose with the default config, this can be set through the ANCHORE_MAX_COMPRESSED_IMAGE_SIZE_MB env variable on the catalog service. If using Helm, it can be configured by using the values file and adding the ANCHORE_MAX_COMPRESSED_IMAGE_SIZE_MB env variable to the catalog.extraEnv property.

Malware Scanning

When an image is analyzed you have the ability to configure the process to best suit your particular use case and/or desired security control. After discovery these data can later be used within the Anchore Enterprise policy engine rules and gates. For an overview of what malware scanning does and when it runs, see Images.

Malware scanning is powered by ClamAV and runs during Centralized Analysis. Findings are available via:

API endpoint: GET /v2/images/{image_digest}/content/malware
AnchoreCTL: anchorectl image content <image_digest> -t malware
The Enterprise UI Image SBOM tab

Signature Database Updates

By default each analyzer service refreshes its ClamAV signature database before scanning each image. This adds latency but ensures signatures are as up-to-date as possible. The update can be disabled if you prefer to manage signature freshness another way — for example, via a shared filesystem that is updated on a schedule and mounted into every analyzer node. See Enabling & Disabling below for the db_update_enabled flag.

The result of the database update is recorded in every scan’s metadata.db_update_enabled and metadata.db_version fields. When updates are disabled, db_version will not be populated, as the version numbers are only obtained during a refresh.

Scan Result Structure

The malware content type returned by the API is a list of scan results. Each result records the files matched, the scanner that produced it (ClamAV by default), and metadata about the signatures used.

{
    "content": [
        {
            "findings": [
                {
                    "path": "/somebadfile",
                    "signature": "Unix.Trojan.MSShellcode-40"
                },
                {
                    "path": "/somedir/somepath/otherbadfile",
                    "signature": "Unix.Trojan.MSShellcode-40"
                }
            ],
            "metadata": {
                "db_update_enabled": true,
                "db_version": {
                    "bytecode": "331",
                    "daily": "25890",
                    "main": "59"
                }
            },
            "scanner": "clamav"
        }
    ],
    "content_type": "malware",
    "imageDigest": "sha256:0eb874fcad5414762a2ca5b2496db5291aad7d3b737700d05e45af43bad3ce4d"
}

An empty findings array indicates no malware was detected.

Malware scanning can be configured via the UI as well as the methods documented below. To enable it in the UI, go to System -> Configuration, search for Malware, and click the check button to enable the feature.

Limitations and Resource Usage

Malware scanning will impact analysis/scanning time, and this time will depend on the size and number of files the image contains. Anchore Enterprise supports sources, however, sources currently need to be analyzed with Syft and not AnchoreCTL. Syft does not currently support malware checks. Where possible, and use case depending, you should offload to Distributed Scanning/Analysis to reduce analyzer compute load on your central Anchore Deployment.

Anchore Enterprise 5.13 and above supports scanning of images greater than 2GB in size through splitting images for analysis.

Malware scanning can ONLY operate when using Centralized Analysis and NOT Distributed Analysis.
ClamAV scan timeout has been increased from 2 minutes to 30 minutes in order to accommodate malware scanning for larger images. This can be changed through the max_scan_time parameter in the Helm chart.

Enabling & Disabling

The process for enabling and configuring the Malware scan differs between Helm and Compose deployments. Additionally, there are two modes in which you can scan and analyze images, and therefore two places to configure this capability: 1. Distributed Mode 2. Centralized Mode.

For Centralized Analysis, Malware scans are configured in the centralized Anchore Enterprise Deployment via the Analyzer config documented on this page.

Helm

Update the Helm values.yaml file. Below is an example configuration for enabling Malware scanning. Helm will take these values and define a ConfigMap in your Anchore Enterprise Kubernetes deployment.

Malforming this file can cause the Anchore Enterprise Analyzer to fail on all image analysis!

anchoreConfig:
  analyzer:
    configFile:
      ## Malware scanning occurs only at analysis time when the image content itself is available
      malware:
        clamav:
          # Set to true to enable the malware scan
          enabled: true
          # Set to true to enable the db refresh on each scan
          db_update_enabled: true
          # Maximum time in milliseconds that ClamAV scan is allowed to run (default is 30 minutes)
          max_scan_time: 1800000

Please review the helm chart example values.yaml file for further detail.

Docker Compose

The Malware scan can be configured and enabled in the ‘analyzer_config.yaml’ file. This file needs to then be mounted as a file volume in your Anchore Enterprise Docker Compose file under the analyzer: service as shown below:

analyzer:
    volumes:
      - ./analyzer_config.yaml:/anchore_service/analyzer_config.yaml:ro   #mounted analyzer_config

This file should contain the required configuration parameters. Please see the following example and adjust as required.

malware:
  clamav:
    # Set this to true to enable the malware scan
    enabled: true
    # Set this to false to turn off the db refresh on each scan
    db_update_enabled: true

Cataloger Scanning

During Analysis/Scans of your images, Anchore Enterprise has the ability to run extra catalogers or searches. These are as follows:

retrieve_files - retrieve and index files matching a configured file list

secret_search and content_search - perform a search across file contents for a configured regexp match. Findings are then cataloged accordingly.

Limitations and Resource Usage

Running extra catalogers will require more resources and time to perform analysis of images. Please take this into consideration when enabling and defining your regexp values. This can be controlled by limiting the search with MAXFILESIZE to limit the search to large and/or very small files.

Catalogers will impact analysis/scanning time, and this time will depend on the size and number of files the image contains. Anchore Enterprise supports sources, however, sources currently need to be analyzed with Syft and not AnchoreCTL. Syft does not currently support catalogers. Where possible, and use case depending, you should offload to Distributed Scanning/Analysis to reduce analyzer compute load on your central Anchore Deployment.

Enabling & Disabling

The process for enabling and configuring the catalogers differs between Helm and Compose deployments. Additionally, there are two modes in which you can scan and analyze images: 1. Distributed Mode 2. Centralized Mode.

For Distributed Analysis, the catalogers are configured in the AnchoreCTL Configuration. For Centralized Analysis, the catalogers are configured in the centralized Anchore Enterprise Deployment via the Analyzer config documented below.

Helm

Update the Helm values.yaml file. Below is an example configuration for enabling retrieve_files and secret_search catalogers. Helm will take these values and define a ConfigMap in your Anchore Enterprise Kubernetes deployment.

Malforming this file can cause the Anchore Enterprise Analyzer to fail on all image analysis!

anchoreConfig:
  analyzer:
    malware:
        configFile:
          retrieve_files:
            file_list:
              - '/etc/passwd'
          secret_search:
            match_params:
              - MAXFILESIZE=10000
            regexp_match:
              - "AWS_ACCESS_KEY=(?i).*aws_access_key_id( *=+ *).*(?<![A-Z0-9])[A-Z0-9]{20}(?![A-Z0-9]).*"
              - "AWS_SECRET_KEY=(?i).*aws_secret_access_key( *=+ *).*(?<![A-Za-z0-9/+=])[A-Za-z0-9/+=]{40}(?![A-Za-z0-9/+=]).*"
              - "PRIV_KEY=(?i)-+BEGIN(.*)PRIVATE KEY-+"
              - "DOCKER_AUTH=(?i).*\"auth\": *\".+\""
              - "API_KEY=(?i).*api(-|_)key( *=+ *).*(?<![A-Z0-9])[A-Z0-9]{20,60}(?![A-Z0-9]).*"
              # - "ALPINE_NULL_ROOT=^root:::0:::::$"
          #
          ## Uncomment content_search: {} to configure file content searching
          # Very expensive operation - recommend you carefully test and review
          # content_search:
          #   match_params:
          #     - MAXFILESIZE=10000
          #   regexp_match:
          #     - "EXAMPLE_MATCH="

Please review the helm chart example values.yaml file for further detail.

Docker Compose

The Catalogers can be configured and enabled in the ‘analyzer_config.yaml’ file. This file needs to then be mounted as a file volume in your Anchore Enterprise Docker Compose file under the analyzer: service as shown below:

services:
  analyzer:
    volumes:
      - ./analyzer_config.yaml:/anchore_service/analyzer_config.yaml:ro   #mounted analyzer_config

This file should contain the required configuration parameters. Please see the following example and adjust as required.

retrieve_files:
  max_file_size_kb: 1000
  file_list:
    - '/etc/passwd'
    - '/etc/services'
    - '/etc/sudoers'

secret_search:
  match_params:
    - MAXFILESIZE=10000
  regexp_match:
    - "AWS_ACCESS_KEY=(?i).*aws_access_key_id( *=+ *).*(?<![A-Z0-9])[A-Z0-9]{20}(?![A-Z0-9]).*"
    - "AWS_SECRET_KEY=(?i).*aws_secret_access_key( *=+ *).*(?<![A-Za-z0-9/+=])[A-Za-z0-9/+=]{40}(?![A-Za-z0-9/+=]).*"
    - "PRIV_KEY=(?i)-+BEGIN(.*)PRIVATE KEY-+"
    - "DOCKER_AUTH=(?i).*\"auth\": *\".+\""
    - "API_KEY=(?i).*api(-|_)key( *=+ *).*(?<![A-Z0-9])[A-Z0-9]{20,60}(?![A-Z0-9]).*"

## Uncomment content_search: {} to configure file content searching
# Very expensive operation - recommend you carefully test and review
# content_search:
#   match_params:
#     - MAXFILESIZE=10000
#   regexp_match:
#     - "EXAMPLE_MATCH="

Owned Package Filtering

Some images contain software packages that are tracked by more than one package manager. For example, a Python library installed via dpkg (the OS package manager) may appear in scan results as both a Python package and an OS package — two entries for the same files. This creates duplicate vulnerability matches and inflates SBOM output.

Owned package filtering removes these duplicates. If a package’s files are entirely covered by a parent OS package, Anchore drops the child entry before any vulnerability matching or policy evaluation occurs. This applies to all image analysis modes — centralized, distributed, and SBOM imports.

Owned package filtering is enabled by default.

Disable Owned Package Filtering

To disable owned package filtering, set services.analyzer.enable_owned_package_filtering to false.

Helm

In your values.yaml file:

anchoreConfig:
  analyzer:
    enable_owned_package_filtering: false

Docker Compose

In your config.yaml file:

services:
  analyzer:
    enable_owned_package_filtering: false

Base Image Annotations

Anchore Enterprise automatically identifies an image’s base image by tracing its ancestry — the chain of images produced by successive FROM clauses — and picking the closest ancestor by default. You can override that default by annotating a specific ancestor so that it, rather than the immediate parent, is treated as the base image. This is useful when a platform team publishes a “golden image” several layers up the chain. For concept details see Images.

Mark an Image as the Base

Apply the anchore.user/marked_base_image annotation with value true to any image you want considered a base image. If an annotated image should no longer be treated as a base image, set the annotation to false — it is not currently possible to remove annotations once added.

# Mark an image as the base
anchorectl image add anchore/test_images:ancestor-base -w --annotation "anchore.user/marked_base_image=true"

# Un-mark it
anchorectl image add anchore/test_images:ancestor-base --annotation "anchore.user/marked_base_image=false"

Enable or Disable User Annotations

The base-image selection logic can ignore the anchore.user/marked_base_image annotation entirely by setting services.policy_engine.enable_user_base_image to false in the Anchore Enterprise configuration file. When disabled, base-image selection always uses the closest ancestor, regardless of annotations.

Imported SBOM Scanning

SBOMs imported via Anchore SBOM are automatically scanned for vulnerabilities after upload and at regular intervals following each feed update.

By default, the system runs in auto_scale mode. This automatically calculates the number of concurrent background tasks required to completely rescan your imported SBOM inventory within a six-hour window. It does so by adjusting the following settings based on a function of the number of imported SBOMs in the system and the number of Policy Engine and Catalog instances configured in your deployment:

batch_size: The number of imported SBOMs to scan in a single batch. Maximum of 8.

pool_size: The number of concurrent scan threads to run on each Policy Engine. Maximum of 4.

If you wish to override the auto_scale behaviour and manually configure these settings, first set catalog.sbom_vuln_scan.auto_scale to false. You may then set catalog.sbom_vuln_scan.batch_size and catalog.sbom_vuln_scan.pool_size to your desired values.

Helm

In your values.yaml file set the following:

anchoreConfig:
  catalog:
    sbom_vuln_scan:
      auto_scale: false
      batch_size: 4
      pool_size: 2

Docker Compose

In your config.yaml file set the following:

services:
  catalog:
    sbom_vuln_scan:
      auto_scale: false
      batch_size: 4
      pool_size: 2

Redhat Enterprise Linux (RHEL) Extended Update Support (EUS)

Anchore Enterprise supports the detection of Red Hat Enterprise Linux (RHEL) Extended Update Support (EUS) in images analysed by Anchore Secure.

You can decide how Anchore Secure should act when scanning RHEL EUS images for vulnerabilities by setting the following configuration options:

services.policy_engine.vulnerabilities.extended_support.rhel.enabled
- auto: Use EUS data during vulnerability scans if RHEL EUS was detected during image analysis. This is the default value.
  - Images analysed before the release of Anchore Enterprise version 5.21.0 will need to be reanalysed to make use of the auto behaviour.
  - always: Use EUS data during vulnerability scans for all RHEL images, regardless of whether EUS was detected during image analysis.
  - never: Do not use EUS data during vulnerability scans for any images.
services.policy_engine.vulnerabilities.extended_support.rhel.versions
- Defines the range of RHEL versions for which the above EUS behaviour should apply.
- The default value is ">=8.0", which covers all current RHEL EUS versions.

These settings can be changed via the configuration API or by modifying your configuration file as follows.

Helm

To override the default values, alter the following fields in your values.yaml file:

anchoreConfig:
  policy_engine:
    vulnerabilities:
      extended_support:
        rhel:
          enabled: "auto"
          versions: ">=8.0"

Docker Compose

To override the default values, alter the following fields in your config.yaml file:

services:
  policy_engine:
    vulnerabilities:
      extended_support:
        rhel:
          enabled: "auto"
          versions: ">=8.0"

Last modified April 29, 2026