SBOMs

A Software Bill of Materials (SBOM) is a structured, machine-readable inventory of the components that make up a piece of software — operating-system packages, language-ecosystem libraries, files, licenses, and the relationships between them. The common analogy is a nutrition label: an explicit declaration of the “ingredients” inside a piece of software, from which consumers can answer “what’s actually in here?” without needing to crack it open themselves.

In Anchore Enterprise, the SBOM is the foundation. It is not a downstream artifact produced as a side-effect of scanning; it is the central record that every other capability depends on. Container images are one kind of asset from which an SBOM can be derived, and the primary focus of most deployments — but source repositories, filesystem artifacts, and externally supplied SBOMs are also first-class inputs. Once an SBOM is stored, the platform re-evaluates, exports, matches, and compares it over time.

Why SBOMs Matter

SBOMs moved from a nice-to-have to a board-level requirement over a short period of time. Three drivers converged:

  • Regulatory mandates — U.S. Executive Order 14028 (2021) required SBOMs for software delivered to federal agencies, and subsequent guidance from NIST (SP 800-53, SP 800-218 / SSDF), FedRAMP, and the EU Cyber Resilience Act extended the expectation into broader commercial procurement.
  • High-profile supply-chain incidents — SolarWinds, Codecov, and the Log4Shell vulnerability in Log4j each demonstrated that organizations could not quickly answer a basic question: “do we use this component, and where?” An SBOM inventory turns that question from a weeks-long audit into a database lookup.
  • Interoperability standards — the NTIA’s Minimum Elements for a Software Bill of Materials (2021) established a baseline — component name, supplier, version, unique identifier, dependency relationships, SBOM author, and timestamp — that modern SBOM formats satisfy. This baseline makes SBOMs exchangeable across organizations and tools rather than stuck in vendor-specific representations.

Anchore Enterprise is designed around these drivers: SBOMs are stored as first-class records, exchanged in open formats, and reused for as many security, compliance, and audit questions as possible.

What an SBOM Captures

Anchore Enterprise extracts a single SBOM per analyzed artifact. The SBOM records the material that downstream scanning and policy decisions need:

  • Packages — operating-system packages (dpkg, rpm, apk, etc.) and language-ecosystem packages (Java, Python, Node.js, Go, Ruby, .NET, and others), each with name, version, license, and package-type metadata.
  • Files — a file inventory with coordinates and optional content hashes, used for checks that depend on file layout as well as language-ecosystem package discovery.
  • Distribution metadata — the detected Linux distribution and release for container images, which determines which vulnerability feeds are consulted.
  • Source metadata — identifying information for the analyzed artifact: image reference, repository digests, architecture, OS, and, for container images, the raw manifest and config.
  • Relationships — the dependency graph connecting packages to the files and parents that declared them, used for precise vulnerability localization.

Several related content types travel alongside the SBOM rather than inside it — secret-scan results, content-search results, retrieved file contents, image manifest, parent manifest, and Dockerfile. These are stored as separate content records tied to the same image record, so they can be queried independently without bloating the SBOM itself.

How SBOMs Are Produced and Exchanged

Anchore Enterprise treats SBOMs as a two-way flow: the platform generates SBOMs for the software an organization produces, and also consumes SBOMs the organization receives from its suppliers.

SBOMs land in Anchore Enterprise from three distinct sources, all of which participate in the same downstream flows once stored:

  • Centralized analysis — the Anchore Enterprise deployment pulls an image from a registry, unpacks it, and generates the SBOM server-side.
  • Distributed analysis — AnchoreCTL pulls the image (or source tree) locally, runs Syft to generate the SBOM client-side, and uploads the result. Source content never leaves the client. Syft is Anchore’s open-source SBOM generator, and Anchore Enterprise builds on that foundation to store, evaluate, and enforce policy against SBOMs at scale. See Images for when to pick which mode.
  • External import (“Bring Your Own SBOM”) — an SBOM produced by another tool or vendor is uploaded directly, without requiring the underlying artifact. This is how procurement teams ingest supplier SBOMs, how M&A due-diligence and third-party audits are brought into the same analysis pipeline, and how components that were never built by Anchore Enterprise get vulnerability and license visibility.

Supported Formats

Internally, Anchore Enterprise stores SBOMs in the Syft native JSON format. At the edges of the system, the two dominant open standards are supported for both import and export:

  • CycloneDX (OWASP) — imported and exported in JSON and XML.
  • SPDX (Linux Foundation) — imported and exported in JSON and tag-value formats.
  • Syft — the native internal format; produced by AnchoreCTL distributed analysis and by Anchore Enterprise centralized analysis.

Both CycloneDX and SPDX satisfy the NTIA minimum-elements baseline, which is why an SBOM generated once can be re-emitted in whichever format a downstream consumer requires — auditor, customer, or another security tool. For the exact schema versions supported for upload and download, see SBOM Management.

How Anchore Enterprise Uses the SBOM

Storing the SBOM means every downstream capability can be derived from the same canonical record, without re-analyzing the artifact. The same SBOM answers a range of questions well beyond “what CVEs apply”:

  • Vulnerability matching — the packages in the SBOM are matched against Anchore Enterprise’s consolidated vulnerability data on a recurring schedule, so newly disclosed CVEs surface automatically on previously analyzed software. For how matching is performed, see How It Works.
  • License compliance — the SBOM records per-package license metadata, which policy rules use to enforce allow-lists, denylists, or obligations (for example, flagging GPL-licensed components in proprietary releases).
  • Policy evaluation — rule sets evaluate the SBOM’s packages, files, licenses, metadata, and Dockerfile instructions to produce a pass/warn/fail outcome. See Policy.
  • Reporting, audit, and procurement responses — stored SBOMs feed scheduled and ad-hoc reports and can be re-emitted as CycloneDX or SPDX for auditors, customers, regulators, or downstream tooling. This is the primary mechanism for responding to customer or procurement requests that require an SBOM alongside a delivered product.
  • VEX generation — vulnerability annotations applied on the SBOM’s findings are emitted as OpenVEX or CycloneDX VEX documents, combining the SBOM with its exploitability statements. See Remediation.
  • Base-image comparison — because both an image’s SBOM and its base image’s SBOM are stored, findings can be partitioned into “inherited from base” versus “introduced by this image”. See Compare Against a Base Image.
  • SBOM drift detection — successive SBOMs for the same image can be diffed to detect added, removed, or changed components, and the drift result can drive policy to catch unauthorized modifications, developer error, or supply-chain attacks. See SBOM Drift.
  • Component provenance and trend analysis — stored historical SBOMs let teams trace when a specific component entered the codebase, identify every release that carries a given library version, and track the evolution of the software’s composition over time.
  • Application grouping — individual SBOMs can be grouped into higher-level applications that reflect the way an organization actually delivers software, making batch reporting and policy management possible across related artifacts.

Because the SBOM is persistent and the data sources around it (vulnerability feeds, policy definitions, annotations) change over time, a single analysis remains useful for the full life of the software it describes.

Last modified April 22, 2026