A Software Bill of Materials (SBOM) is a machine-readable inventory of every component, library, and dependency that makes up a piece of software — the digital equivalent of an ingredient label. An SBOM lists each component's name, version, supplier, and unique identifier (such as a CPE or PURL), along with the relationships between them, so a security team can answer "is this vulnerable library anywhere in our stack?" in minutes instead of weeks. The concept moved from niche practice to federal mandate after Executive Order 14028 (May 12, 2021) directed the U.S. government to require SBOMs from software vendors, and the December 2021 Log4Shell incident (CVE-2021-44228) showed why: organizations that didn't know they used Log4j spent weeks manually auditing thousands of applications to find out. Today, SBOMs are the foundation of modern software supply chain security programs.
What is an SBOM, exactly?
An SBOM is a structured, machine-readable document that lists all first-party code, open source packages, and third-party dependencies used to build an application, along with the version, license, and supplier of each. Think of it as a nested parts list: a single containerized microservice might resolve to 150-400 transitive dependencies once you account for the packages that your direct dependencies pull in on their own. The National Telecommunications and Information Administration (NTIA) formalized the concept in July 2021 with a "minimum elements" document specifying that a compliant SBOM must include, at minimum, the supplier name, component name, version string, unique identifiers, dependency relationships, the author of the SBOM data, and a timestamp. Without those fields, a document might list software but can't function as an SBOM for security or compliance purposes — it's just a spreadsheet.
Why do SBOMs matter for software supply chain security?
SBOMs matter because they let security teams find vulnerable and malicious components across their entire portfolio in minutes rather than during a fire drill. When Log4Shell was disclosed on December 9, 2021, organizations without dependency inventories had no fast way to determine exposure — Log4j was estimated to be present, directly or transitively, in over 35,000 Maven Central packages, and many enterprises spent 2-4 weeks manually grepping build artifacts and asking every engineering team to self-report usage. An organization with current SBOMs for its applications can instead run one query against stored component data and get an answer the same day. This same logic extends to license compliance (catching a GPL-licensed dependency before it ships) and to malicious package detection, since an SBOM gives you a baseline to diff against when a package you depend on suddenly changes maintainers or publishes an unexpected new version.
What formats do SBOMs use — SPDX or CycloneDX?
The two dominant SBOM formats are SPDX and CycloneDX, and most tooling today supports both. SPDX (Software Package Data Exchange) started at the Linux Foundation in 2010, became ISO/IEC 5962:2021 in September 2021, and is oriented toward licensing and provenance metadata, which made it the reference format cited in U.S. federal guidance. CycloneDX was created by the OWASP Foundation in 2017 with a security-first design, including native support for vulnerability disclosure records (VEX — Vulnerability Exploitability eXchange) and component-level pedigree data describing how a piece of software was assembled. Both formats are expressed in JSON or XML and both are accepted by CISA and most commercial scanners; the practical choice usually comes down to whether your priority is regulatory license reporting (lean SPDX) or vulnerability and exploitability workflows (lean CycloneDX).
Who is legally required to produce SBOMs?
Federal software vendors, medical device manufacturers, and (soon) most companies selling digital products into the EU are already required to produce SBOMs. Executive Order 14028 directed NIST and NTIA to build SBOM standards for any vendor selling software to U.S. federal agencies, and by 2023 several agencies, including the Department of Health and Human Services and the VA, had begun requesting SBOMs as part of procurement. The FDA followed with the Omnibus Appropriations Act, Section 3305, effective March 29, 2023, which requires SBOMs in premarket submissions for internet-connected medical devices. The EU's Cyber Resilience Act, which entered into force in December 2024 with core obligations phasing in through December 2027, requires manufacturers of "products with digital elements" to maintain an SBOM covering top-level dependencies as part of conformity assessment. Even organizations with no direct regulatory trigger increasingly need SBOMs because their enterprise customers' procurement questionnaires ask for one — a 2023 Linux Foundation survey found 47% of organizations were already producing SBOMs for their software, up from 27% in 2022.
What does a complete SBOM actually contain?
A complete SBOM contains the seven NTIA minimum elements plus, in practice, several fields security teams actually use day to day. Beyond supplier name, component name, version, and unique identifiers (PURL or CPE), a usable SBOM includes the dependency graph showing which components are direct versus transitive, license identifiers (SPDX license expressions), cryptographic hashes for integrity verification, and ideally a VEX statement indicating whether a known CVE in a component is actually exploitable in that specific product. A static list of package names and versions without the dependency graph is the single most common gap — it tells you Log4j 2.14.1 is somewhere in your build, but not whether it's a direct dependency you can patch in an afternoon or buried four layers deep in a vendor's SDK, which changes remediation time from hours to weeks.
How do you generate and maintain an SBOM?
You generate an SBOM by running an analysis tool against your source code, build artifacts, or container images at build time, then you maintain it by regenerating it on every release rather than treating it as a one-time document. Manual SBOM creation doesn't scale past a handful of services — a typical mid-size engineering org with 50-200 repositories needs automated generation wired into CI/CD, producing a new SBOM on every merge to main or every container build. The harder part is maintenance: a component list generated once in Q1 is stale by Q2 as dependencies get bumped, and stale SBOMs give teams false confidence that they've already checked for a vulnerability that was introduced three sprints later. Mature programs store SBOMs centrally, diff them release-over-release to flag new or changed components automatically, and correlate them against live vulnerability feeds continuously instead of at audit time.
How Safeguard Helps
Safeguard generates and ingests SBOMs across your entire codebase and container fleet automatically on every build, so you always have a current, queryable inventory instead of a stale point-in-time snapshot. Rather than stopping at "this package appears in your SBOM," Safeguard's reachability analysis determines whether the vulnerable function in a flagged dependency is actually called by your code, cutting through the noise of theoretical CVEs that inflate typical vulnerability backlogs by 70-90%. Griffin AI, Safeguard's detection engine, correlates SBOM data with runtime and code-path context to prioritize the handful of findings that represent real exploitable risk, and Safeguard's auto-fix PRs turn that prioritized list directly into a merge-ready dependency bump — closing the gap between "we found it in the SBOM" and "it's patched in production" from weeks to hours.