Container Image Assets

A container image asset is created by analyzing an OCI or Docker image and attaching the resulting SBOM to an app version. Anchore Enterprise supports two analysis paths — pick the one that matches where the image bytes can be read from.

Distributed vs Centralized Analysis

For the underlying lifecycle these two paths share, see How It Works.

Add a Container Image Asset in the Anchore Enterprise GUI

From an app version’s detail page, open the Add Asset action and choose Container Image. Provide the image reference, an asset name, and (optionally) a Dockerfile to attach and annotations. The GUI submits the analysis job and shows its progress on the version’s recent activity panel.

Select the Image option:

Enter the Image Reference and optional Dockerfile:

Enter the Image Asset Name:

Optionally, enter up to 10 image asset annotations:

You can view the recently added assets in the My Recent Activity panel on the App Version Summary tab:

Add a Container Image Asset with AnchoreCTL

AnchoreCTL exposes the two analysis paths as separate subcommands. Both require the parent app, the parent version, and a name for the new asset.

Distributed Analysis

Use app version asset add container-image to have AnchoreCTL analyze the image locally and upload the SBOM. The default source is a registry pull:

anchorectl app version asset add container-image docker.io/my-org/api:1.4.0 \
  --app my-service \
  --version 1.4.0 \
  --asset api-image

Switch the source with --from. The supported values are:

To analyze an image already loaded into your local Docker daemon — for example a freshly built image that hasn’t been pushed yet — point AnchoreCTL at the docker source:

anchorectl app version asset add container-image my-org/api:1.4.0 \
  --app my-service \
  --version 1.4.0 \
  --asset api-image \
  --from docker

Registry-hosted multi-architecture images carry a manifest per platform. Pin the platform AnchoreCTL should analyze with --platform:

anchorectl app version asset add container-image docker.io/my-org/api:1.4.0 \
  --app my-service \
  --version 1.4.0 \
  --asset api-image \
  --platform linux/arm64

Centralized Analysis

Use app version asset add container-image-remote to have Anchore Enterprise pull and analyze the image server-side:

anchorectl app version asset add container-image-remote docker.io/my-org/api:1.4.0 \
  --app my-service \
  --version 1.4.0 \
  --asset api-image

The image reference must be resolvable from Anchore Enterprise — including registry credentials configured in your account. The centralized command does not accept --from or --platform, since Anchore Enterprise selects how to fetch the image.

Shared Flags

Both subcommands accept the same supporting flags:

• --annotations "key=value,key=value" — attach build metadata at create time (see Add Assets to an App Version for the merge and clear semantics)
• --dockerfile /path/to/Dockerfile — attach the Dockerfile so policy checks can evaluate Dockerfile triggers
• --wait — block until the job reaches a terminal state instead of returning immediately
• --type — override the asset type (defaults to container); see the AssetType enum

These flags stack with both the distributed and centralized invocations. A complete CI/CD-friendly invocation that attaches a Dockerfile, captures build metadata, and blocks until the job completes:

anchorectl app version asset add container-image docker.io/my-org/api:1.4.0 \
  --app my-service \
  --version 1.4.0 \
  --asset api-image \
  --dockerfile ./Dockerfile \
  --annotations "owner=platform-team,commit=a3f7c01" \
  --wait

Add a Container Image Asset with the API

Distributed and centralized analysis are two distinct job types in the API:

• POST /apps/{app_id}/jobs/add-container-image-asset — used by the centralized path; Anchore Enterprise pulls and analyzes the image server-side.
• POST /apps/{app_id}/jobs/add-imported-image-asset — used by the distributed path; AnchoreCTL analyzes the image locally and uploads the resulting SBOM together with the image manifest, image config, and any optional analysis artifacts (secret searches, content searches, file contents) as a multipart payload.

For both, the full multipart request schema and response schemas are in the API browser; search for the App Jobs tag.

A few conventions worth knowing as you call these endpoints:

• Job state transitions and the --wait semantics are documented in How It Works.
• The job response carries a job_id; poll GET /apps/{app_id}/jobs/{job_id} to track status.
• Cross-account requests are scoped via the x-anchore-account header or, from AnchoreCTL, the ANCHORECTL_ACCOUNT environment variable. See Account Scoping for the full mechanism.