The SBOM executive order — Executive Order 14028, “Improving the Nation’s Cybersecurity,” signed in May 2021 — set in motion a federal push to require a Software Bill of Materials from vendors selling software to the government. That push has since been scaled back. In January 2026, the Office of Management and Budget rescinded the memoranda that made SBOMs and security attestations mandatory across the federal government and replaced them with a risk-based framework that lets each agency decide whether to require an SBOM at all. Vendors still need to be ready to produce one, but the requirement now travels through individual contract terms rather than a single government-wide rule.
What EO 14028 Originally Required
EO 14028 was a response to supply chain attacks that had exposed how little visibility the federal government had into the software running on its networks. The order itself directed agencies and standards bodies to build the framework: NIST would publish secure software development guidelines, NTIA would define the minimum elements of an SBOM, and CISA would identify categories of critical software deserving the most scrutiny.
The operational requirements arrived through two OMB memoranda, M-22-18 and M-23-16. Under those memos, any software producer selling to a federal agency had to submit a self-attestation confirming it followed NIST’s Secure Software Development Framework, and any agency could require an SBOM from a vendor. That was the compliance world vendors spent several years preparing for.
What Changed in January 2026
On January 23, 2026, OMB issued Memorandum M-26-05, “Adopting a Risk-Based Approach to Software and Hardware Security,” which rescinded both M-22-18 and M-23-16. The new memo rejects a one-size-fits-all approach. Each agency head is now responsible for validating provider security based on the agency’s own risk assessment and mission needs.
Agencies must still keep a complete inventory of the software and hardware on their networks. But the mandatory attestation and SBOM requirements no longer exist at the government-wide level. Under M-26-05, agencies “may choose” to use the attestation form developed under the old memos, and they “may also choose to adopt contractual terms” requiring a vendor to produce an SBOM upon request. For cloud platforms, agencies that do require an SBOM should specify that it cover the runtime production environment.
The practical result is that SBOM obligations now vary agency by agency. A vendor selling to one department may face a contractual SBOM mandate while a vendor selling to another faces none. Agencies that handle classified data, defense systems, or critical infrastructure are the most likely to keep requiring SBOMs, and some may demand more than the old memos ever did. Vendors who already invested in SBOM generation carry that work into those procurements as an advantage.
Federal procurement is not the only place these documents matter. Major software buyers in healthcare, financial services, and energy already request SBOMs from vendors as part of third-party risk management, independent of any OMB memo.
What an SBOM Must Contain
When an agency does ask for an SBOM, the accepted baseline is the set of minimum elements NTIA published pursuant to EO 14028. CISA issued an updated guide in 2025 that builds on the NTIA framework rather than replacing it. Seven data fields form the core:
- Supplier name — the company or individual that created, packaged, or distributed the component.
- Component name — the name assigned to the software unit by its original supplier.
- Version — the specific release identifier, which allows cross-referencing against known vulnerability databases.
- Other unique identifiers — markers like Common Platform Enumeration strings or Software Identification tags that distinguish similar-sounding components.
- Dependency relationship — which components rely on other components, mapping the upstream connections that can propagate a vulnerability.
- Author of the SBOM data — the entity that compiled the SBOM, which may differ from the software supplier.
- Timestamp — the date and time the SBOM was generated, so consumers know whether it is current.
These fields exist so automated tools can ingest the data. When a new vulnerability is disclosed in an open-source library, an agency with a well-populated SBOM repository can identify every product that includes the affected component in minutes rather than weeks.
How Vendors Actually Produce One
Building an SBOM starts with an audit of everything that goes into a product: every third-party library, open-source package, and proprietary module. Manual tracking is impractical for any real codebase. Even a modest web application can pull in hundreds of transitive dependencies that developers never explicitly chose.
Software Composition Analysis tools automate the discovery by scanning codebases, build environments, and container images. They output machine-readable SBOM files, typically in one of two formats: CycloneDX, maintained by OWASP, or SPDX (Software Package Data Exchange), maintained by the Linux Foundation. Both satisfy the NTIA minimum elements and are widely accepted across government and industry.
Open-source tooling sits alongside commercial platforms. CycloneDX offers plugins for common build tools like Maven and Gradle, generating SBOMs directly from the build process. Syft, maintained by Anchore, works from source code, build environments, and Docker container images, which matters for organizations deploying containerized applications. Commercial tools add continuous monitoring, policy enforcement, and ticketing integrations, but the core generation capability is available at no cost.
Coordination with sub-vendors is the harder part. If a product embeds a licensed module from another company, the SBOM should account for that module’s components too. Some sub-vendors resist sharing detailed component lists, treating them as trade secrets. The NTIA minimum elements were kept lightweight partly to reduce that friction, but it remains one of the sticking points of SBOM adoption in practice.
The Attestation Piece
EO 14028 also directed NIST to publish guidance on secure software development, which became Special Publication 800-218, the Secure Software Development Framework (SSDF). The SSDF organizes its recommendations into four practice groups: preparing the organization, protecting the software (including collecting provenance data for every component in a release), producing well-secured software, and responding to vulnerabilities identified after release.
CISA built a Secure Software Development Attestation Form based on those practices. Under the rescinded M-22-18, software producers had to submit the form before their products could be used by federal agencies. Under M-26-05, agencies may choose to use it — a tool available to them rather than a universal requirement. Vendors selling to security-conscious agencies like the Department of Defense or the intelligence community should expect attestation requirements to persist regardless of the OMB shift.
A proposed Federal Acquisition Regulation rule, FAR Case 2021-017, would have formalized SBOM and attestation requirements across all federal contracts. Its status is uncertain following the OMB policy change. For now, individual agencies impose requirements through contract-specific terms rather than a uniform FAR clause.
What Happens If a Vendor Can’t Deliver — or Lies
Because the rules are now set at the agency level, the consequences of non-compliance depend on the specific contract. An agency that includes SBOM provisions in its terms can treat a failure to deliver as a breach, terminating the agreement or withholding payment. Vendors who cannot produce an SBOM when a solicitation requires one will lose the competition to vendors who can.
The more serious risk is debarment. Federal procurement regulations allow an agency to debar a contractor from all federal contracts for causes that include failure to perform contract obligations. Debarment generally should not exceed three years, though longer periods are possible in serious cases.
Submitting a fraudulent SBOM or attestation triggers liability under the False Claims Act. The FCA imposes treble damages, three times whatever the government lost, plus civil penalties per false claim that are adjusted annually for inflation. The DOJ’s most recent adjustment set penalties between $14,308 and $28,619 per violation. For a vendor supplying software across multiple agencies and contracts, the cumulative exposure from a knowingly false attestation can be severe. Criminal investigation is also possible for intentional fraud, which can reach the individual officers who signed the attestation.
What Vendors Should Do Now
The move to a risk-based framework is not permission to stop preparing. The requirement can now come from any direction: a contract clause, an agency policy, a private-sector customer, or a future executive order that swings the pendulum back toward mandatory disclosure. Vendors who build SBOM generation into their development pipeline now will not be scrambling when the next requirement arrives.
At a minimum, vendors selling to federal agencies should integrate an SBOM tool into the build process, work through the NIST SSDF practices, and be ready to complete the CISA attestation form on request. The cost of preparation is modest compared with losing a contract because a competitor had the documentation ready.