Executive Order 14028, signed by President Biden on May 12, 2021, is the reason nearly every federal software vendor now has to produce a Software Bill of Materials, attest to secure development practices, and prove it. The order was issued six months after the SolarWinds breach and in the same year as the Kaseya and Log4j incidents, and it treats software supply chain compromise as a national security problem rather than a vendor-specific one. Section 4 alone spawned a chain of follow-on mandates: NIST's Secure Software Development Framework (SP 800-218, published February 2022), OMB Memorandum M-22-18 (September 14, 2022), and a CISA self-attestation form that agencies started collecting in 2023. If your company sells software to a U.S. federal agency — or sells to a prime contractor who does — these requirements are not optional guidance. They are contractual gates that block procurement when unmet. Here is what the order actually requires, on what timeline, and how to demonstrate compliance without slowing down engineering.
What is Executive Order 14028?
Executive Order 14028, "Improving the Nation's Cybersecurity," is a 2021 directive that uses federal procurement power to force minimum security standards onto any software sold to the U.S. government. President Biden signed it on May 12, 2021, following the SolarWinds Orion compromise disclosed in December 2020, which affected roughly 18,000 customers including nine federal agencies. Rather than writing new law, the EO uses the FAR (Federal Acquisition Regulation) and agency budget authority as enforcement levers: agencies were directed to update contract language so vendors must meet NIST-defined security practices to keep selling. Section 4, "Enhancing Software Supply Chain Security," is the part relevant to security teams — it gave NIST, CISA, and OMB a series of deadlines (some as short as 30, 60, and 90 days from the signing date) to publish definitions, guidelines, and enforcement mechanisms. Sections 2, 3, 5, 6, 7, and 8 cover related areas like information-sharing requirements, cloud security, incident response playbooks, and endpoint detection, but Section 4 is what created the SBOM and attestation regime vendors deal with today.
What does EO 14028 require for software supply chain security?
EO 14028 requires that any vendor selling software to the federal government use a documented secure development process, provide a Software Bill of Materials on request, and self-attest in writing that they followed NIST's secure development standard. The order applies specifically to "critical software" — a category NIST defined on June 25, 2021 as software with direct or privileged access to networking, computing, or data resources, which in practice covers identity management systems, operating systems, hypervisors, and network monitoring tools first, before later phases extend to broader categories. Concretely, three deliverables came out of Section 4: (1) NIST SP 800-218, the Secure Software Development Framework, which lists specific practices like verifying third-party components and maintaining provenance records; (2) minimum elements for an SBOM, published by NTIA on July 12, 2021, specifying that an SBOM must include supplier name, component name, version, unique identifiers, dependency relationships, and a timestamp at minimum; and (3) a standardized self-attestation form that CISA published in draft form in April 2023 and finalized later that year. Vendors that can't produce these artifacts on request risk losing the ability to sell to agencies at contract renewal.
What is a Software Bill of Materials (SBOM) under EO 14028?
Under EO 14028, an SBOM is a formal, machine-readable inventory of every component in a piece of software, and federal agencies can require one as a condition of purchase. NTIA's July 2021 minimum-elements guidance specifies two accepted machine-readable formats in practice — SPDX and CycloneDX — and requires that the SBOM be generated for each build and made available to the acquiring agency within a "reasonable time" after request, not produced once and never updated. The practical problem for vendors is scale: a mid-size SaaS application commonly pulls in 150-500+ transitive open-source dependencies through its direct dependency tree, and every one of those needs to appear with a correct version string and supplier field. Manually maintained spreadsheets fail this requirement almost immediately because dependency graphs change on every build. This is why SBOM generation has shifted from a compliance checkbox exercise to something that has to run in CI/CD on every merge, tied to the actual artifact that ships, not a point-in-time snapshot from months earlier.
What is the NIST Secure Software Development Framework (SSDF)?
The NIST Secure Software Development Framework, published as SP 800-218 in February 2022, is the specific set of practices vendors must attest to following under EO 14028. SSDF organizes secure development into four practice groups — Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV) — with roughly 19 top-level practices and dozens of sub-tasks, covering things like PW.4.4 (verify third-party software components comply with organizational security requirements) and RV.1.2 (have a documented, tested vulnerability response process). CISA's attestation form asks vendors to certify compliance with a subset of these practices for each software product or product line sold to a federal agency, and the certifying official has to be a company executive, not a compliance vendor or contractor — which raises the internal stakes considerably, since a false attestation carries potential False Claims Act exposure. Notably, SSDF compliance isn't graded by an external auditor at the point of attestation; it's a self-certification, which means the burden of proof shifts to the vendor if a breach later reveals the attestation was inaccurate.
When do the self-attestation deadlines apply and who is affected?
Self-attestation deadlines under EO 14028 have already passed for critical software and now apply broadly, and any company selling software to a federal agency — including subcontractors several tiers down a prime contractor's supply chain — falls in scope. OMB Memorandum M-22-18, issued September 14, 2022, originally set a deadline of June 11, 2023 (270 days after issuance) for agencies to collect attestations covering critical software, and a separate deadline for all other software covered by the order. That timeline slipped: OMB issued M-23-16 on June 9, 2023, extending the critical-software deadline and clarifying that agencies could accept a self-attestation letter directly rather than requiring a third-party assessment in most cases, while reserving the right to demand supporting artifacts like the SBOM itself. As of 2024, agencies including DoD, DHS, and GSA have incorporated the attestation requirement into standard contract clauses, meaning it now shows up during routine vendor onboarding and renewal cycles rather than as a one-time historical deadline — companies that haven't attested are increasingly finding themselves unable to close new federal deals or renew existing ones.
How does EO 14028 differ from FedRAMP or CMMC?
EO 14028 is a supply chain integrity mandate focused on how software is built and what it contains, whereas FedRAMP governs cloud service authorization and CMMC governs contractor handling of Controlled Unclassified Information — they are complementary, not overlapping, requirements. A vendor can hold a FedRAMP Moderate authorization and a CMMC Level 2 certification and still be out of compliance with EO 14028 if it has never generated an SBOM or filed a CISA attestation, because FedRAMP's control catalog (based on NIST SP 800-53) doesn't require component-level provenance tracking the way SSDF does. In practice, companies selling into federal accounts increasingly need all three: FedRAMP or CMMC to clear the operational security bar, and EO 14028 artifacts (SBOM plus SSDF attestation) to clear the supply chain bar at contract execution. Security teams that treat these as one compliance program rather than three separate audits generally move faster through procurement, since SBOM data and SSDF evidence overlap heavily with the vulnerability management artifacts FedRAMP assessors already ask for.
How Safeguard Helps
Safeguard maps directly onto the two hardest EO 14028 deliverables: SBOM generation and provable secure-development practice. Safeguard generates SPDX- and CycloneDX-compliant SBOMs automatically on every build and ingests SBOMs from vendors and acquisitions, giving you the per-build, machine-readable inventory NTIA's minimum elements require instead of a stale quarterly export. Because most CVEs in a dependency tree are never actually invoked by your code, Safeguard's reachability analysis narrows the SSDF-relevant vulnerability list down to what's exploitable in your specific build — the evidence CISA and federal customers increasingly ask to see behind an attestation, not just a raw scan count. Griffin AI, Safeguard's AI-driven triage engine, correlates that reachability data against exploit intelligence to prioritize what actually needs remediation, and Safeguard's auto-fix PRs close the loop by shipping the dependency bump or patch directly into your CI pipeline. Together, that turns EO 14028 compliance from a once-a-year attestation scramble into a continuously current record you can hand to a federal customer, an auditor, or your own executive signing the CISA form.
