This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

How It Works

SBOM management in Anchore Enterprise covers the full Software Bill of Materials (SBOM) lifecycle — from adding SBOMs to a release through organization, vulnerability scanning, and compliance evaluation. Each SBOM is attached to an app version as an asset, and Anchore Enterprise aggregates package, vulnerability, and policy data across every asset in a version so you can see, and act on, the security posture of a release as a whole.

Specific topics related to the SBOM management framework can be referenced per the links below:

The App, Version, and Asset Hierarchy

Anchore Enterprise organizes SBOM data around a three-level hierarchy:

  • App — the top-level entity representing a piece of software you ship or host. An app carries a name, a description, a contact, and an optional default policy that applies to every version for that application.
  • App Version — a point-in-time release of an app. A version carries a name (typically a semver or release tag), an optional description, an optional reference to the previous version, an optional release date, and a status (in_progress, released, or eol).
  • Asset — a concrete thing that was analyzed and whose SBOM lives inside an app version. An app version can hold any number of assets — a container image, a filesystem analysis, an externally supplied Syft (native), CycloneDX, or SPDX document, or any mix of these.
App  ────  App Version  ────  Asset (container image)
                        ├──   Asset (filesystem: source repo, artifact dir, mounted VM, etc.)
                        └──   Asset (uploaded SBOM)

The app version is the unit of aggregation: when Anchore Enterprise reports the packages, vulnerabilities, or policy status of “a release,” it is summarizing across the assets attached to a version.

Asset Types

Every asset has a type that describes what the SBOM represents. The supported types are:

  • container — a container image
  • filesystem — an analyzed directory tree
  • application, library, module, file, firmware, device, virtual_machine_disk — finer-grained classifications used primarily by externally supplied SBOMs that follow the CycloneDX component-type taxonomy
  • unknown — to be used when the type is not known

The three AnchoreCTL asset add commands allow the user to specify the asset type (what codebase element it represents) with the --type parameter. For app version asset add container-image, the --type parameter is defaulted to container and for app version asset add sbom it is defaulted to unknown.

The Asset Lifecycle

Adding an asset is an asynchronous operation. AnchoreCTL or the API submits a job that analyzes the artifact and generates the SBOM (or uploads the SBOM if external), processes the SBOM contents, and attaches the resulting asset to the named app version.

A job moves through the following states:

  • pending — accepted, waiting for a worker
  • processing — actively being analyzed
  • complete — finished successfully; the asset is queryable
  • failed — terminated with an error captured on the job record
  • cancelled — terminated by user request

You can wait for a job to finish (--wait on the CLI) or poll the job endpoint until status reaches a terminal state. Once an asset is complete, its SBOM, packages, vulnerabilities, and policy findings are queryable through the app-version endpoints.

Centralized and Distributed Analysis

Container images can be analyzed in two ways:

  • Centralized analysis (anchorectl app version asset add container-image-remote) — Anchore Enterprise pulls the image from your registry and analyzes it server-side. The SBOM is produced inside Anchore Enterprise.
  • Distributed analysis (anchorectl app version asset add container-image) — AnchoreCTL pulls or reads the image where you run the command, generates the SBOM locally, and uploads the result. Anchore Enterprise never sees the image bytes.

Both paths produce the same kind of asset. The trade-off is where the SBOM-generation work runs: centralized analysis runs it inside the Anchore Enterprise deployment, while distributed analysis runs it on the host where AnchoreCTL is invoked. Use distributed analysis to keep image-analysis load off the central deployment — useful when CI runners have spare capacity, when the central deployment is sized for evaluation and aggregation rather than analysis throughput, or when image bytes shouldn’t leave the build host (air-gapped or sensitive-image pipelines).

For the full mechanics — including diagrams, a worked CLI example, and the stateless one-time-scan variant — see Centralized and Distributed Analysis.

Unified Data Queries Across an App Version

Once an app version contains one or more assets, Anchore Enterprise exposes unifed data queries that combine deduplicated data from every asset in the version:

  • List packages in a version — GET /apps/{app_id}/versions/{version_id}/packages
  • List vulnerabilities in a version — GET /apps/{app_id}/versions/{version_id}/vulnerabilities
  • Find assets that contain a given package — GET /apps/{app_id}/versions/{version_id}/assets-by-package?name=…&version=…
  • Find packages affected by a given vulnerability — GET /apps/{app_id}/versions/{version_id}/packages-by-vulnerability
  • Locate where a package lives inside an asset — GET /apps/{app_id}/versions/{version_id}/asset-locations-by-package

These unified data queries are the practical reason to group assets under an app version: they let you answer “which images in this release contain openssl 3.0.13?” or “where in the filesystem asset does log4j-core live?” with one request.

API Conventions

Every entity carries a system_metadata envelope with a UUID id and RFC 3339 created_at/updated_at timestamps.

Pagination

Collection endpoints return paginated responses. The limit query parameter sets the page size (default and maximum 1000).

Account Scoping

App, version, and asset data is isolated per Anchore Enterprise account. A user with the appropriate role can act on another account’s data by setting the target account explicitly:

  • REST API — set the x-anchore-account request header to the target account name.
  • AnchoreCTL — set the account key in the AnchoreCTL config file, or export ANCHORECTL_ACCOUNT as an environment variable. AnchoreCTL does not have a per-command --account flag; the account is read from configuration before the command runs.

Supported SBOM Formats

SBOMs uploaded via app version asset add sbom are validated for schema correctness before the job moves out of pending. The supported formats are:

  • CycloneDX
    • JSON: versions 1.2–1.6
    • XML: versions 1.0–1.6
  • SPDX
    • JSON: versions 2.2–2.3
    • Tag-Value: versions 2.1–2.3
    • Initial SPDX 3.0 support for JSON — upload and download are supported, but content and vulnerability analysis are not yet functional
  • Syft native JSON

Performance Considerations

Asset analysis and SBOM scanning are queued and processed asynchronously. Though no explicit limits are enforced, the platform is tuned for releases of up to roughly 10,000 assets across all apps.

Vulnerability rescans run on a periodic schedule against the existing asset inventory as new vulnerability data lands in the Anchore Data Service. For more information on scheduling and tuning, see Imported SBOM Scanning.