On May 12, 2021, President Biden signed Executive Order 14028, and two months later, on July 12, 2021, NTIA published "The Minimum Elements for a Software Bill of Materials (SBOM)" — the document that turned a niche packaging-metadata idea into a federal procurement requirement. Five months after that, Log4Shell (CVE-2021-44228) turned the abstraction concrete: a flaw privately reported to Apache by Chen Zhaojun of Alibaba Cloud on November 24, 2021 became a public, actively exploited emergency within two weeks, and thousands of security teams discovered they had no reliable way to answer "which of our systems contain log4j-core, and where." An SBOM — in practice, a CycloneDX or SPDX file listing every component, version, and dependency relationship in a piece of software — is the artifact that makes that question answerable in minutes instead of days. Four years on, SBOM generation is common; SBOM consumption is still rare. This piece covers the mechanics of doing both properly, independent of any specific vendor's tooling, plus why the mandate itself is still being rewritten.
What actually counts as a compliant SBOM?
A compliant SBOM is defined by NTIA's three areas: Data Fields, Automation Support, and Practices and Processes — not just "a list of packages." The Data Fields requirement means every component needs a supplier name, component name, version string, other unique identifiers (a package URL or CPE), and a defined dependency relationship to its parent; the SBOM itself needs an author and a timestamp. Automation Support means the file must be in a machine-readable format — SPDX or CycloneDX, not a PDF or spreadsheet — so tooling can parse it without a human. Practices and Processes covers frequency (regenerate on every build, not once a year) and depth (transitive dependencies, not just what's declared in your top-level manifest). Notably, this baseline isn't frozen: CISA, which inherited NTIA's SBOM effort, opened a request for comment on updated minimum elements in the Federal Register on August 22, 2025, signaling the definition of "compliant" is still moving.
SPDX or CycloneDX — does the format choice matter?
It matters less than people assume, but the two formats come from different lineages and are optimized for different jobs. SPDX originated at the Linux Foundation and became an ISO/IEC standard (ISO/IEC 5962:2021), making it the format of choice when a contract or regulator wants standards-body pedigree — it was built first for license compliance and later extended to security use cases. CycloneDX came out of OWASP with security as the primary design goal from day one, and its schema has iterated fastest on the fields that matter for vulnerability workflows: precise dependency graphs, vulnerability data embedded directly in the BOM, and native support for build and service metadata. In practice, most SBOM tooling (SPDX and CycloneDX generators, scanners, and repositories alike) supports both, and the pragmatic answer is to generate in whichever format your downstream consumer — a federal contracting officer, a customer's security team, an internal SBOM repository — asks for, and keep a converter in your pipeline rather than picking a permanent side.
Why isn't a component inventory enough on its own?
A component inventory tells you what's present; it says nothing about whether a listed vulnerability is actually reachable or exploitable in your specific deployment, which is the gap VEX and CSAF close. The Vulnerability Exploitability eXchange (VEX) format lets a supplier attach a status — affected, not affected, fixed, or under investigation — to a specific CVE for a specific component in a specific product, alongside a justification (the vulnerable code path isn't compiled in, isn't reachable, or requires a configuration you don't use). CSAF (Common Security Advisory Framework) is the machine-readable advisory format that typically carries that VEX data. Without VEX, an SBOM containing a component with a critical CVE triggers the same alarm whether or not the vulnerable function is ever called — exactly the noise problem that turns SBOM consumption into an ignored compliance checkbox instead of a triage tool. Pairing SBOM generation with VEX statements is what separates "we have an inventory" from "we know what to actually patch first."
What does the XZ Utils backdoor prove that Log4Shell didn't?
The XZ Utils backdoor (CVE-2024-3094, CVSS 10.0) proves that knowing a component is present isn't enough if you can't also trust how it was built — a gap SBOMs alone don't close. Malicious code was inserted into xz versions 5.6.0 and 5.6.1 by a contributor using the handle "Jia Tan," the product of a multi-year social-engineering campaign to gain maintainer trust on a widely-embedded compression library. It was discovered by accident on March 29, 2024, when Andres Freund, a PostgreSQL developer and Microsoft engineer, noticed anomalous SSH login latency during unrelated performance profiling — not by any SBOM query, since an SBOM listing "xz 5.6.1" looks identical whether that build is clean or backdoored. This is why the supply-chain security conversation has shifted toward build provenance and attestation (frameworks like SLSA, and signed build metadata) as a companion to SBOMs, not a replacement: an SBOM tells you what's in the box, provenance tells you whether the box was tampered with on the way to you.
How should a team actually operationalize SBOMs day to day?
Operationalizing SBOMs means treating them as a continuously updated, queryable dataset rather than a document you generate once for an audit. That means generating a new SBOM on every build — from source repositories, container images, and any AI models you ship — not just at release time, since a dependency added on a Tuesday and removed on a Thursday still represents a window of real exposure. It means storing SBOMs in a repository organized by product and version so you can diff two versions and immediately see added components, removed components, and which vulnerabilities were newly introduced or resolved between them. And for third-party software you don't build yourself, it means actually requesting SBOMs from vendors — tracking those requests through submission, format validation, and completeness checks — rather than assuming a vendor's marketing page constitutes compliance. Safeguard's ESSCM module generates CycloneDX and SPDX SBOMs from SCM, container registry, and AI model sources with on-push and scheduled scanning, tracks each SBOM's EO 14028 compliance status as a field on the record, and supports CSAF/VEX upload so exploitability context travels alongside the component list rather than being reconstructed by hand during an incident.