In December 2020, attackers slipped malicious code into a SolarWinds Orion software update and quietly compromised roughly 18,000 organizations, including nine federal agencies. Sixteen months later, the Log4j vulnerability forced security teams across the government and private sector to answer a question almost nobody could answer quickly: "Are we running the affected component, and where?" Those two incidents didn't just make headlines — they rewrote federal procurement policy. Executive Order 14028, OMB memoranda, FDA rules, and the evolving Cybersecurity Maturity Model Certification (CMMC) program have turned the Software Bill of Materials (SBOM) from a niche compliance artifact into a baseline expectation for anyone who wants to sell software to the U.S. government. And because prime contractors push requirements down their supply chains, and because enterprise buyers copy what the government does, SBOM government procurement impact now reaches far past companies that hold a federal contract. This post walks through how that happened and what it means for your SBOM program.
What federal rule actually started requiring SBOMs?
Executive Order 14028, "Improving the Nation's Cybersecurity," signed on May 12, 2021, is the document that made SBOMs a procurement issue. Section 4 directed the National Institute of Standards and Technology (NIST) and the National Telecommunications and Information Administration (NTIA) to define minimum elements for an SBOM and to build guidelines for "critical software" used by federal agencies. NTIA published its Minimum Elements for a Software Bill of Materials on July 12, 2021, defining three components every compliant SBOM needs: data fields (supplier, component name, version, dependency relationships, and more), automation support (machine-readable formats like SPDX, CycloneDX, or SWID), and practices around frequency, depth, and distribution. That single 15-page document is now the reference point cited in nearly every subsequent federal rule, contract clause, and vendor questionnaire touching software transparency — including the FDA's medical device rules and the DoD's evolving contract language.
Which federal purchases now actually require an SBOM?
Since September 2022, any software vendor selling to the federal government has had to self-attest to secure development practices, and that attestation form points directly back to NTIA's SBOM guidance. OMB Memorandum M-22-18 required agencies to collect a signed attestation from software producers before using their products, based on the NIST Secure Software Development Framework (SSDF, NIST SP 800-218). OMB M-23-16, issued June 9, 2023, softened the original all-at-once deadline but kept the core requirement intact: agencies must collect attestations for "critical software" and can request an SBOM directly from a vendor if they want deeper visibility, particularly when a self-attestation raises questions. CISA published the standard attestation form in 2023 and has continued refining it since. The practical effect: contracting officers at agencies like GSA, DoD, and VA increasingly build SBOM-readiness into RFPs and vendor onboarding, even when a formal SBOM delivery clause isn't yet spelled out in the FAR itself.
Does this reach beyond IT vendors, into places like healthcare and defense hardware?
Yes — the FDA has required SBOMs for medical devices since March 29, 2023, and the effect on that industry has been immediate. Section 524B of the Federal Food, Drug, and Cosmetic Act, added by the PATCH Act as part of the Consolidated Appropriations Act, 2023, requires manufacturers submitting premarket applications for cyber devices to include a plan for monitoring and remediating post-market vulnerabilities, and to provide "a software bill of materials, including commercial, open-source, and off-the-shelf software components." The FDA can now refuse to accept an incomplete submission on these grounds alone. On the defense side, CMMC 2.0 became a final rule on December 16, 2024 (32 CFR Part 170), and while its published requirements focus on Controlled Unclassified Information handling rather than mandating SBOMs outright, DoD's broader secure software supply chain guidance and its Software Acquisition Pathway increasingly expect component-level transparency from contractors building the systems layered on top of it. Two very different industries, one shared expectation: know what's in your software before you ship it to a federal buyer.
Why is a company with zero government contracts building an SBOM program anyway?
Because flow-down obligations and copycat procurement language reach much further than the direct contract, that's why. When a prime contractor like a large defense integrator or federal systems integrator signs an attestation about its own secure development practices, it typically needs assurance from every subcontractor and software supplier feeding into that system — SBOMs included. That obligation cascades three, four, sometimes five tiers deep into companies that have never spoken to a government contracting officer. On top of that, enterprise security teams have started mirroring federal SBOM expectations in their own vendor risk questionnaires, because it's now a recognized, auditable standard rather than something they'd have to invent themselves. Gartner has estimated that by 2025, 45% of organizations globally would experience an attack on their software supply chain, roughly triple the rate from 2021 — a trend that gives procurement and security teams outside government plenty of reason to ask "where's your SBOM?" even without a FAR clause forcing the question.
Is a formal SBOM requirement coming to the Federal Acquisition Regulation itself?
Not yet as a finalized, government-wide FAR clause, but the rulemaking machinery is already moving. A FAR Council case tied to cyber threat and incident reporting has been working through the federal rulemaking process since 2023, and CISA has continued to update its own guidance — including a third edition of "Framing Software Component Transparency" in 2024 — to keep pace with how agencies actually want to consume SBOM data (VEX documents, vulnerability-exploitability exchange formats, and continuous rather than point-in-time delivery). The absence of a single unified FAR mandate today doesn't mean less pressure; it means the requirements are arriving piecemeal, agency by agency and sector by sector, which is often harder for vendors to track than one clean rule would be. Companies waiting for a single "SBOM Day" compliance deadline are missing that the deadline has effectively already arrived in fragments across OMB memos, FDA rules, and contract-specific clauses.
What should a private-sector vendor actually do about this today?
Start by treating SBOM generation as a build-pipeline output, not a one-time compliance exercise, because every federal rule referenced above expects SBOMs to reflect the software as it currently ships, not a snapshot from a year-old audit. NTIA's minimum elements call out both format (SPDX, CycloneDX) and frequency, and OMB's attestation process assumes the underlying development practices are continuous. That means SBOMs need to be produced automatically at build time, matched against known vulnerabilities on an ongoing basis, and made available in a form a customer, auditor, or contracting officer can actually parse — not a PDF buried in a compliance folder.
How Safeguard Helps
Safeguard was built for exactly this shift from SBOMs-as-paperwork to SBOMs-as-infrastructure. Our platform generates SPDX- and CycloneDX-compliant SBOMs directly from your build and CI/CD pipelines, so the artifact you hand to a federal prime, an FDA reviewer, or an enterprise security team reflects what's actually running in production — not a stale export. Safeguard continuously matches every component and dependency in your SBOM against emerging CVE data, so you know the moment a component you shipped last quarter becomes a liability, and we help you produce VEX statements that tell customers whether a given vulnerability is actually exploitable in your product's context, cutting down the back-and-forth that slows procurement reviews. For teams navigating NIST SSDF attestation, FDA Section 524B submissions, or prime-contractor flow-down requirements, Safeguard maps your existing SBOM and vulnerability data to the specific fields and formats those processes expect, so your security team spends less time reformatting spreadsheets and more time actually reducing risk. Whether you're selling directly to a federal agency or simply feel the ripple effect through a customer's questionnaire, Safeguard gives you a defensible, continuously accurate answer to the question every buyer is now asking: what's really in your software.