Analyzing Images

When an image is submitted to Anchore Enterprise, the deployment retrieves the image manifest from the configured registry and hands it off to an analyzer worker. Analyzer workers run in parallel and pull from a shared queue, so scaling throughput is a matter of adding more analyzer replicas.

During analysis, a set of catalogers inspects every package, software library, and file, producing a comprehensive SBOM. The SBOM is persisted to the database and drives all downstream vulnerability matching and policy evaluation.

Centralized and Distributed Analysis

Anchore Enterprise supports two analysis models that differ only in where SBOM generation happens:

Centralized analysis — the Anchore Enterprise deployment pulls the image from the registry, unpacks it, and generates the SBOM server-side.
Distributed analysis — AnchoreCTL pulls the image locally, generates the SBOM on the client, and uploads the result. Source image content never leaves the client machine.

sequenceDiagram
    participant A as AnchoreCTL
    participant R as Registry
    participant E as Anchore Enterprise
    A->>E: Request image analysis
    E->>R: Get image content
    R-->>E: Image content
    E->>E: Generate SBOM, secret scan, etc.
    E->>E: Scan SBOM for vulns and evaluate compliance

Centralized analysis — all image content is handled by the deployment.

sequenceDiagram
    participant A as AnchoreCTL
    participant R as Registry/Docker Daemon
    participant E as Anchore Enterprise
    A->>R: Get image content
    R-->>A: Image content
    A->>A: Generate SBOM, secret scan, etc.
    A->>E: Import SBOM, secret search, fs metadata
    E->>E: Scan SBOM for vulns and evaluate compliance

Distributed analysis — image content stays on the client; only the SBOM is uploaded.

Representative commands:

# Centralized — the deployment pulls and analyzes
anchorectl image add docker.io/library/nginx:latest

# Distributed — anchorectl pulls from the registry and analyzes locally
anchorectl image add docker.io/library/nginx:latest --from registry

A stateless variant of distributed analysis is available via anchorectl image one-time-scan. It runs the same client-side flow and returns policy and vulnerability results to the caller, but the SBOM is never persisted in Anchore Enterprise — useful in CI pipelines that want fast pass/fail feedback without growing the deployment’s SBOM history. See One-Time Scan for details.

Analysis State

Analysis is asynchronous. Workers poll an internal queue and update the image’s analysis_status as processing progresses.

stateDiagram
    [*] --> not_analyzed: analysis queued
    not_analyzed --> analyzing: analyzer starts processing
    analyzing --> analyzed: analysis completed successfully
    analyzing --> analysis_failed: analysis fails
    analyzing --> not_analyzed: re-queue by timeout or analyzer shutdown
    analysis_failed --> not_analyzed: re-queued by user request
    analyzed --> not_analyzed: re-queued for re-processing by user request

Monitor Images for Updates

Anchore Enterprise watches the external world on your behalf:

Repository updates — new tags appearing on a watched repository are automatically added as subscriptions.
Tag updates — when the image digest a tag points to changes, the new image is pulled and re-analyzed.

Both checks are driven by the Catalog component on a configurable duty cycle. To manage subscriptions and tune cycle intervals, see Subscriptions.

Base and Parent Images

Container images are built on top of other images via the FROM clause. Docker calls the referenced image the parent image; the broader community uses base image for the same concept, and Anchore Enterprise follows the latter convention. A chain of images related via FROM is an image’s ancestry.

Docker itself defines a base image as an image declared with FROM scratch. Anchore Enterprise does not use that definition — throughout these docs, base image means the image a given image was built from.

Ancestry is reconstructed automatically by comparing layer digests: image B is a descendant of image A only if every layer of A is present in B. No configuration is required — Anchore Enterprise computes ancestry as new images are analyzed.

graph LR
debian:10-->|parent of|mynode:latest
mynode:latest-->|parent of|myapp:v1

Choose the Base Image

By default, the base image is the closest ancestor — mynode:latest for myapp:v1 above. You can override the default by marking a specific ancestor with an annotation, useful for designating a platform team’s “golden image” as the base rather than the immediate parent. The selection rules are:

graph TD
start([start])-->image[image]
image-->first_parent_exists{Does this image have a parent?}
first_parent_exists-->|No|no_base_image
first_parent_exists-->|Yes|first_parent_image[Parent image]
first_parent_image-->config{User base annotations enabled?}
config-->|No|base_image
config-->|Yes|check_parent{Parent has anchore.user/marked_base_image: true?}
check_parent-->|No|parent_exists{Does the parent have a parent?}
parent_exists-->|Yes|parent_image[/Move to next parent image/]
parent_image-->check_parent
parent_exists-->|No|no_base_image
check_parent-->|Yes|base_image
base_image([Found base image])
no_base_image([No base image exists])

The base image filters inherited findings out of policy evaluations and vulnerability scans so developers can focus on issues introduced by their own changes. For the full base-comparison feature, see Compare Against a Base Image.

For the annotation syntax, AnchoreCTL command, and the configuration flag that enables user-marked base images, see Base Image Annotations.

Malware Scanning

During centralized analysis, Anchore Enterprise runs a ClamAV-based malware scan over the image content. Findings are exposed on the image record and can be acted on via the Malware Policy Gate. For enabling scanning, tuning signature-database refresh behavior, and handling images larger than 2 GB, see Scanning Configuration.