The software bill of materials went from a niche best practice to a term in federal procurement contracts because of one document: Executive Order 14028. Understanding how that happened — and what the order actually mandated versus what grew up around it — is the clearest way to make sense of the SBOM obligations vendors face today. This is that story, told for the engineers and compliance leads who now have to live with its consequences.
The catalyst
Executive Order 14028, "Improving the Nation's Cybersecurity," was signed on 12 May 2021, in the immediate aftermath of the SolarWinds and Colonial Pipeline incidents. SolarWinds in particular reframed the problem: attackers had compromised a trusted software vendor's build pipeline and pushed a malicious update to thousands of downstream organisations, including federal agencies. The lesson landed hard — you cannot secure software you do not understand, and agencies had almost no visibility into what components made up the software they ran.
Section 4 of the order, on enhancing software supply chain security, is where the SBOM entered federal policy. It directed the Department of Commerce, through NTIA, to publish the minimum elements of an SBOM, and directed NIST to develop secure software development guidance. The theory was simple: if the government uses its buying power to require secure development and transparency, the market will follow.
What the order actually set in motion
The order itself did not command every company to ship an SBOM tomorrow. It set off a chain of implementing artifacts:
- NTIA's "Minimum Elements for a Software Bill of Materials" (July 2021) defined the baseline data an SBOM should contain — supplier name, component name, version, unique identifiers, dependency relationships, author, and timestamp — plus expectations around formats, automation, and practices.
- NIST's Secure Software Development Framework (SP 800-218) codified the secure development practices the order called for, becoming the yardstick for later attestation requirements.
- OMB guidance (M-22-18 and its follow-on) directed federal agencies to obtain self-attestation from software producers that they follow those secure development practices, with SBOMs and other artifacts available on request.
The commonly cited machine-readable formats that carry this data are SPDX and CycloneDX — both widely supported, and either is generally acceptable where a machine-readable SBOM is expected.
Who this reaches in 2026
The direct legal force of EO 14028 falls on federal agencies and, through them, on the software producers that sell to the government. But its gravity extends much further. Subsequent policy has built on the foundation the order laid, and SBOM expectations have propagated into other regimes — the EU Cyber Resilience Act, medical device regulation, and private-sector procurement contracts that borrow the federal language. If you sell software to almost any large or regulated buyer today, an SBOM request is a matter of when, not if.
A practical note on the policy landscape: federal cybersecurity direction has continued to evolve through additional executive orders since 2021, and specific deadlines and mechanisms have shifted. The through-line that has held is the substance — component transparency via SBOMs and secure development practices aligned with the SSDF. Build to that substance and you remain aligned regardless of which administration adjusts the surrounding process.
What "meeting the intent" looks like
- Generate a machine-readable SBOM (SPDX or CycloneDX) for each release
- Include the NTIA minimum data elements, including dependency relationships
- Automate SBOM generation in the build so it reflects what actually shipped
- Continuously match SBOM components against known vulnerabilities
- Align development practices to the NIST SSDF (SP 800-218)
- Be able to produce an SBOM and secure-development attestation on request
- Retain provenance linking each SBOM to its build and artifact
The lesson SolarWinds taught, still unlearned in places
The order's deepest point is often missed: SolarWinds was a build pipeline compromise, not a vulnerable dependency. An SBOM that lists components is necessary but not sufficient; you also need provenance — evidence of where each component came from and what touched it on the way to the artifact. A list of ingredients does not tell you whether someone tampered with the kitchen. The strongest programs pair the SBOM with a provenance trail from source through build to deployed artifact.
How Safeguard helps
Safeguard operationalises the intent of EO 14028 rather than just its paperwork. SBOM Studio generates NTIA-aligned SBOMs in SPDX or CycloneDX automatically on every build, so the inventory always reflects what shipped and carries the dependency relationships the minimum elements require. Software composition analysis then does the part a static SBOM cannot — continuously matching those components against new vulnerability disclosures, so transparency turns into action.
Because the Safeguard CLI runs in your pipeline, the SBOM is tied to a specific build and artifact, producing the provenance trail that addresses the SolarWinds-style pipeline risk the order was written to prevent. Griffin AI prioritises findings by real-world exploitability so remediation stays focused. Our compliance pages map these capabilities to the NTIA minimum elements and the SSDF, giving you a ready answer when a federal buyer — or any buyer echoing federal language — asks for evidence.
Executive Order 14028 turned the SBOM from an idea into an expectation. In 2026, the vendors who thrive are the ones for whom producing that evidence is automatic.
Make SBOMs a byproduct of every build. Create a free account or read the Safeguard documentation to generate your first NTIA-aligned SBOM.