Executive Order 14028 and SBOMs: what software vendors must know

Executive Order 14028 SBOM requirements reshaped how the U.S. government buys software—and, by gravity, how the whole industry documents its supply chain. Signed in May 2021 after SolarWinds, EO 14028 directed agencies to require secure development evidence from vendors, with SBOMs as a headline artifact. If you sell (or want to sell) software to federal agencies, this is the policy chain that determines what lands in your contracts.

This guide covers:

What EO 14028 established and the guidance chain that followed (NIST SSDF, OMB memos, CISA forms)
The specific SBOM expectations vendors face
The CISA secure software development attestation and how SBOMs relate
Who is affected—including SaaS and indirect sellers
A preparation checklist that doubles as commercial-buyer readiness

Raising the security bar

GIF via GIPHY

Related guides:

Key takeaways

EO 14028 made secure software development evidence a condition of federal procurement—SBOMs are one pillar, attestations another.
The operative documents are NIST's SSDF (SP 800-218), OMB M-22-18 / M-23-16, and CISA's attestation form—the EO itself is the umbrella.
Agencies may require an SBOM with NTIA minimum elements; the attestation is broadly required for critical software.
Federal expectations have become the template for enterprise buyers, so preparation pays off beyond government deals.
SecureSlate helps map SSDF practices and SBOM evidence to one control library.

What EO 14028 is

Executive Order 14028, "Improving the Nation's Cybersecurity," responded to the SolarWinds compromise by directing federal action across incident response, zero trust, and—most relevant here—software supply chain security (Section 4). It tasked NIST with defining secure development practices and directed OMB to make those practices contractual requirements for software the government buys.

The resulting chain:

Document	What it does
EO 14028 (2021)	Directs agencies to require secure development evidence, including SBOMs
NTIA minimum elements (2021)	Defines what a valid SBOM contains
NIST SP 800-218 (SSDF)	The secure development practices vendors attest to
OMB M-22-18 / M-23-16	Requires agencies to collect attestations; permits SBOM requirements
CISA attestation form (2024)	The standardized self-attestation vendors sign

The SBOM provisions

Under the OMB memos, agencies may require SBOMs from software producers based on the criticality of the software. When required:

SBOMs must conform to the NTIA minimum elements (data fields, automation support, practices and processes)
Accepted formats are SPDX, CycloneDX, or SWID—machine-readable, not PDFs
SBOMs may be requested per version/release, posted to a designated repository, or delivered with the product
Agencies can also ask for participation in a vulnerability disclosure program and evidence of secure development environments

In practice, SBOM clauses now appear in solicitations well beyond "critical software," and defense contracts add their own supply chain language on top.

The CISA attestation form

The Secure Software Development Attestation Form is a self-attestation, signed by your CEO or designee, that your development practices meet a subset of SSDF requirements: secure build environments, provenance data maintenance, vulnerability management, and more.

Key points vendors miss:

It applies to software developed after September 2022, plus older software receiving major changes
False attestations carry legal exposure (False Claims Act risk)—sign only what your practices support
Agencies may request artifacts backing the attestation, and an SBOM pipeline is among the most concrete artifacts you can offer
Third-party assessments (by a FedRAMP 3PAO) can substitute where you cannot attest to everything

Who is affected

Direct federal software vendors — squarely in scope, including SaaS
Resellers and integrators' suppliers — requirements flow down contractually; primes push attestation and SBOM clauses to you
FedRAMP-authorized providers — attestation and supply chain expectations layer on top of the authorization—see our FedRAMP overview
Commercial-only vendors — not legally bound, but enterprise buyers now copy this playbook in procurement, so the practical bar has moved for everyone

How to prepare

Read the CISA form against your actual practices and gap-assess honestly—especially build environment separation and provenance.
Stand up automated SBOM generation per release with NTIA fields—see how to generate an SBOM.
Adopt SSDF-aligned policies: secure SDLC, vulnerability management with SLAs, and a disclosure program.
Prepare artifact packages (SBOMs, pipeline configs, scan reports) so an agency request does not trigger a quarter of scrambling.
Track flow-down clauses in every federal-adjacent contract—your obligations often arrive via a prime, not an agency.

Federal readiness with SecureSlate

SecureSlate maps SSDF practices, SBOM evidence, and vulnerability management to one control library that serves federal attestations, SOC 2, ISO 27001, and enterprise buyer reviews simultaneously.

Get started for free · Free readiness score

FAQ: EO 14028 and SBOMs

Does EO 14028 require every vendor to provide SBOMs?

Not universally. The attestation is the broad requirement; SBOMs are required when the buying agency decides to require them—which is increasingly common for critical software.

Does this apply to SaaS?

Yes. The attestation and SBOM expectations apply regardless of delivery model, and SaaS providers commonly face them alongside FedRAMP obligations.

What happens if we cannot sign the attestation?

You can submit a plan of action with milestones (POA&M) identifying gaps and timelines, or obtain a 3PAO assessment. Agencies decide whether to accept it.

Is the SBOM submitted with every proposal?

Practices vary by agency and contract. Some collect SBOMs at delivery, some per release, some on request. Read the solicitation language carefully.

Where should we start if we sell to government through a prime?

Ask the prime which clauses flow down to you now, then prioritize the attestation gap assessment and automated SBOM generation—both take weeks, not days, to do honestly.

Disclaimer (legal note)

SecureSlate is not a law firm, and this article does not constitute legal advice or create an attorney-client relationship. Security and compliance obligations vary by industry, contract, and jurisdiction—consult qualified counsel as needed.