From Recommendation to Requirement
Software Bills of Materials existed as a concept long before governments noticed them. The National Telecommunications and Information Administration had been convening working groups on the idea since 2018, producing voluntary frameworks that most vendors quietly filed and forgot. That changed on 12 May 2021, when President Biden signed Executive Order 14028 on Improving the Nation's Cybersecurity, which directed federal agencies to condition software procurement on a vendor's ability to supply a machine-readable inventory of every component and dependency in their product — a Software Bill of Materials, or SBOM.
The order did not invent the requirement in detail; it tasked the National Institute of Standards and Technology and the NTIA with filling in the specifics. The NTIA responded with minimum-element guidance, settling on seven baseline data fields, among them component name and version, supplier, and dependency relationships. Those three fields, modest as they sound, were enough to establish whether a given product contained, for instance, a vulnerable version of Apache Log4j — the library at the centre of the Log4Shell crisis that had erupted just months after the order was signed.
The timing was not incidental. Log4Shell (CVE-2021-44228, a severity-10.0 remote-code-execution flaw disclosed in December 2021) demonstrated exactly what an SBOM is for: rapid identification of which deployed products contain a specific component. Without a bill of materials, the question "do we run this?" requires manual archaeology across every vendor and codebase. With one, it is a query.
What the Requirement Actually Covers
EO 14028 applies to software sold to or operated on behalf of the federal government. That scope is broad but not universal — it does not, on its face, reach purely commercial products. The practical effect is nonetheless wide, because major enterprise vendors sell to federal agencies and do not maintain separate component inventories per customer. A procurement requirement that touches the US federal market tends to reshape supplier practices across their whole catalogue.
The formats the market coalesced around are SPDX, a specification maintained by the Linux Foundation and recognised as an ISO/IEC standard (ISO/IEC 5962:2021), and CycloneDX, maintained by OWASP. Both are machine-readable; both satisfy the NTIA minimum elements. Neither mandates how a vendor assembles the SBOM — by hand, by tooling, or by build-system instrumentation — which left a secondary market for compliance tooling to fill.
- CHRONOLOGYAS RECORDED
- 2018NTIA begins convening working groups on SBOM as voluntary framework
- May 2021EO 14028 signed; SBOM moves from recommendation to procurement condition
- December 2021Log4Shell (CVE-2021-44228) disclosed; SBOM's practical value demonstrated immediately
- 2021ISO/IEC 5962:2021 ratifies SPDX as an international standard
- December 2024EU Cyber Resilience Act enters into force
The European dimension arrived with the EU Cyber Resilience Act, which entered into force in December 2024. The CRA applies to any product with digital elements placed on the European market — a definition that reaches hardware, software, and connected devices regardless of where the vendor is domiciled. It requires manufacturers to identify and document components, address known vulnerabilities, and provide security support for a defined period after a product's market life ends. The CRA requires manufacturers to draw up a software bill of materials as part of its vulnerability-handling obligations, covering at least the top-level dependencies of the product.

Open-source projects distributed without commercial intent occupy a carve-out in the CRA's current text, but that carve-out narrows the moment a project is integrated into a commercial product — which is, of course, almost always. The European Commission acknowledged during the legislative process that the obligation would fall primarily on the integrators, not the volunteer maintainers upstream, but the line between the two is not always clean.
Together, the two frameworks establish SBOM production as the new baseline expectation for any organisation that ships software into a regulated market. The NTIA's voluntary guidance of 2019 now reads like a footnote. What changed was not the technology — the formats, the tooling, and the concept were already present — but the enforcement mechanism: the purchase order on one side of the Atlantic, the conformity-marking regime on the other.
