The State of SBOMs in 2022
It had been nearly nine months since our post on the premise, the promise, and the peril of software bills of material (SBOMs), and while there were many developments during 2021–2022, the actual state of affairs did not change as much as many expected.
May 2021 — Improving the Nation’s Cybersecurity
President Biden issued Executive Order 14028, Improving the Nation’s Cybersecurity, mandating the establishment of supply chain security minimum standards for all software consumed by the US government. The order directed federal agencies to adopt SBOMs to improve transparency in the software supply chain. Software developers would need to produce an SBOM for each product or publish it on a public website.
We had previously noted the potential of machine-readable metadata to improve many areas of modern business, while also highlighting the inherent limitations of SBOMs as a standalone solution.
July 2021 — Minimum Elements for SBOMs
The US Department of Commerce published the Minimum Elements for an SBOM, providing guidance on what should be included to ensure SBOMs are comprehensive and useful for identifying and managing software security risks. The document established a baseline across three categories:
Data Fields — the core identifiers for each component:
- Supplier name, component name, and version
- Unique identifiers and dependency relationships
- Author of SBOM data and timestamp
Automation Support — tools and formats (like SPDX and CycloneDX) that enable automated processing and integration with vulnerability databases.
Practices and Processes — guidelines for collecting, organizing, updating, and maintaining SBOMs over time.
February 2022 — NIST Guidance
NIST delivered the Software Supply Chain Security Guidance on Attestation and the Secure Software Development Framework (SSDF) in Special Publication 800-218. Key elements included:
- Software producers should use SSDF terminology to communicate secure development practices to federal agencies.
- Agencies should request attestation of secure development practices across the full software lifecycle, including post-release.
- Self-attestation is acceptable unless a risk-based assessment suggests third-party attestation is more appropriate.
- Agencies should request high-level conformance artifacts rather than low-level implementation details.
July 2022 — NDAA Attempt #1
The version of the National Defense Authorization Act for FY2023 that passed the House included provisions requiring DHS contractors to submit planned SBOMs and certifications as a condition of contract award. Existing contracts would require SBOM submission upon request. Contractors would also need to certify that all listed components were free from known vulnerabilities, provide notification of newly discovered issues, and develop mitigation plans.
This language did not survive to the enacted version.
September 2022 — OMB Memorandum M-22-18
The Office of Management and Budget published M-22-18, directing federal agencies to follow NIST attestation guidance and accept SBOMs as conformance artifacts. Agencies could require Plans of Action & Milestones (POA&Ms) from software producers unable to attest to specific practices. The memo set timelines for both “critical software” and all other software categories.
December 2022 — NDAA (Enacted)
The final NDAA for FY2023 contained no mention of SBOMs. The Alliance for Digital Innovation (ADI), whose members include AWS, Google Cloud, and others, successfully lobbied to remove all SBOM-related language. Their position: while they supported the goal of strengthening software supply chain security, SBOMs were not the right mechanism.
Where SBOMs Stood
At the close of 2022, the regulatory picture was mixed. Executive orders and OMB memoranda pushed federal agencies toward requiring SBOMs, but legislative efforts stalled under industry opposition. The fundamental question remained: are SBOMs a useful transparency tool, or an unfunded compliance burden?
Beyond SBOMs
It was broadly accepted — then and now — that SBOMs alone will not secure the software supply chain. They are one element of a layered approach. Combining source composition analysis with static code analysis, establishing data provenance for ML training data, and maintaining data bills of materials are all part of a more comprehensive strategy.
Since this post was originally published, the SBOM landscape has continued to evolve — CycloneDX 1.7 added patent and provenance fields, the EU Cyber Resilience Act codified SBOM requirements into European law, and supply chain attacks like xz-utils and tj-actions underscored why transparency in the software supply chain matters more than ever.
Our team helps organizations build layered application security programs that go beyond checkbox compliance. If you need help assessing your supply chain security posture or preparing for regulatory requirements, reach out.
Related posts
Delve and the 494 Fake SOC 2 Reports: What the Compliance Industry Should Learn
A Y Combinator-backed compliance startup allegedly fabricated 494 SOC 2 reports with auditor conclusions pre-written before clients submitted any evidence.
Read moreFive Supply Chain Attacks in Twelve Days: March 2026 Broke Open Source Trust
In twelve days, attackers compromised Trivy, Checkmarx, LiteLLM, Telnyx, and Axios — and the supply chain security model most organizations rely on did not survive.
Read moreThree More States, Three More Privacy Laws: 2026 Compliance Starts Now
Indiana, Kentucky, and Rhode Island all went live on January 1, 2026, which means privacy compliance just got a little less optional.
Read more