If you've ever tried to answer "are we affected by this CVE?" within an hour of a zero-day dropping, you already know why SBOMs exist. A Software Bill of Materials is a structured, machine-readable inventory of every component, library, and dependency baked into a piece of software — the same idea as an ingredients label on food, applied to code. When Log4Shell hit on December 10, 2021, teams with SBOMs on hand could grep a file and get an answer in minutes; teams without one spent days manually crawling build manifests, container layers, and vendor emails. That gap is why the U.S. government made SBOMs a procurement requirement in Executive Order 14028 (May 2021), why NTIA published its minimum elements the same July, and why the FDA now requires them for medical device submissions under Section 524B (effective October 2023). Below: what's actually in an SBOM, which formats matter, and how a component like Anchore's Syft fits into generating one.
What is a Software Bill of Materials (SBOM)?
An SBOM is a formal, machine-readable record listing every software component — open source libraries, third-party packages, internal modules, and their versions — that makes up an application or container image, along with the relationships between them. Think of a typical Node.js or Java service: the code you wrote might be 5,000 lines, but npm install or a Maven build can pull in 800–1,500 transitive dependencies you never directly chose. An SBOM captures all of them, not just the top-level ones you listed in package.json or pom.xml. The term was formalized by NTIA (National Telecommunications and Information Administration) in a July 2021 framework defining seven "minimum elements": supplier name, component name, version string, other unique identifiers, dependency relationship, author of SBOM data, and timestamp. CISA has since taken over stewardship of the standard from NTIA.
What does an SBOM actually contain?
At minimum, an SBOM contains the seven NTIA fields above for every component in scope, plus a document-level manifest (SBOM author, tool used, generation timestamp, and format version). In practice, a useful SBOM goes further and includes package hashes (SHA-256 checksums to detect tampering), license identifiers (SPDX license expressions like Apache-2.0 or GPL-3.0-only), known vulnerability references when paired with a scanner, and a dependency graph showing which component pulled in which — critical for tracing a vulnerable transitive dependency back to the direct package that introduced it. A real-world example: an SBOM for a single python:3.11-slim container image commonly enumerates 90–150 OS packages plus whatever your application layer adds, each with its own version and license, generated as a single JSON or XML document you can diff between builds.
Why did SBOMs suddenly become a compliance requirement?
SBOMs became a compliance requirement because two events three years apart exposed the same blind spot: nobody could quickly answer "what's in our software." The SolarWinds breach, disclosed December 2020, showed that a single compromised build pipeline could poison thousands of downstream customers with no visibility into what changed. Executive Order 14028, signed May 12, 2021, directly cited that incident and mandated that any software vendor selling to the U.S. federal government provide an SBOM on request. The EU followed with the Cyber Resilience Act (entered into force December 2024, with SBOM-related obligations phasing in through 2027), which requires manufacturers of "products with digital elements" to maintain an SBOM covering top-level dependencies. The FDA's premarket cybersecurity guidance under Section 524B, effective October 1, 2023, requires medical device makers to submit an SBOM as part of any 510(k) or PMA application. None of these are optional checkboxes anymore — they're conditions of doing business in regulated markets.
What formats do SBOMs come in — SPDX vs CycloneDX?
The two dominant SBOM formats are SPDX and CycloneDX, and the choice usually comes down to whether your priority is license compliance or security. SPDX (Software Package Data Exchange) started at the Linux Foundation in 2010 focused on license and provenance tracking, reached ISO/IEC 5962:2021 standardization, and is now on version 3.0. CycloneDX, maintained by OWASP since 2017, was purpose-built for application security use cases — it has native support for vulnerability disclosure (VEX, Vulnerability Exploitability eXchange), pedigree data, and service dependencies, which is why most SCA and container scanning tools default to it. A third format, SWID (Software Identification) tags, ISO/IEC 19770-2, is older and more common in enterprise IT asset management than in modern DevSecOps pipelines. CISA officially recognizes both SPDX and CycloneDX as acceptable minimum-elements formats, so most tooling — including Anchore's open source Syft generator — supports exporting to either.
How do teams use SBOMs day to day?
Teams use SBOMs primarily for rapid incident response, license auditing, and procurement gatekeeping — not as a one-time compliance artifact that sits in a folder. During an incident like the xz-utils backdoor discovered March 29, 2024 (CVE-2024-3094), a security team with SBOMs indexed across their fleet can query "which of our 200 production images include liblzma 5.6.0 or 5.6.1" and get an exact list in seconds instead of re-scanning every environment from scratch. On the license side, legal and compliance teams query SBOMs to catch a copyleft license like AGPL-3.0 sneaking into a commercial product before it ships. On the procurement side, enterprise buyers increasingly ask vendors for an SBOM before signing — a practice that grew directly out of the EO 14028 federal requirement and has trickled into private-sector vendor risk questionnaires over the past three years.
How does Anchore fit into the SBOM ecosystem?
Anchore is one of the most widely used SBOM tooling vendors, primarily through Syft, its open source CLI for generating SPDX and CycloneDX SBOMs from container images, filesystems, and archives, and Grype, its companion open source vulnerability scanner that consumes those SBOMs. Anchore Enterprise packages this generation-and-scanning workflow with policy enforcement, a centralized SBOM repository, and continuous monitoring so that when a new CVE is disclosed, previously generated SBOMs are automatically re-checked against it rather than requiring a fresh scan. This "generate once, re-check continuously" model is Anchore's core pitch and is genuinely useful for organizations standardizing on SBOM generation as their primary control point. Where it tends to fall short for supply-chain-focused teams is upstream of the SBOM itself: Anchore's strength is inventorying and scanning artifacts you already built, not verifying the integrity of the build pipeline, source repositories, and CI/CD identity chain that produced those artifacts in the first place — which is where SBOM data becomes most actionable when it's tied back to provenance.
How Safeguard Helps
Safeguard treats the SBOM as one input into a broader supply chain risk picture rather than the end product. Instead of generating an SBOM in isolation and hoping teams remember to re-check it, Safeguard continuously correlates SBOM component data with build provenance, source-to-artifact traceability, and live exploitability signals — so when a component like the one behind the xz-utils incident shows up, you're not just told "this package is present," you're shown which pipeline built it, which commit introduced the dependency, and whether it's actually reachable in your running services. Safeguard ingests SPDX and CycloneDX SBOMs from existing tools (including Anchore-generated ones, so switching isn't required to get value), enriches them with VEX statements to cut through vulnerability noise, and maps every component back to the CI/CD identity and artifact signature that produced it. That closes the gap Anchore and similar SBOM-first tools leave open: an SBOM tells you what's in your software, but Safeguard tells you where it came from, whether it's trustworthy, and what to actually fix first — turning a compliance artifact into an operational one.