Executive Order 14028, signed in May 2021, directed US agencies to strengthen software supply chain security for software the federal government buys. Its software provisions led to NIST guidance on secure development, requirements for producers to attest to secure practices, and wider use of software bills of materials (SBOMs).
What did the order do?
The order, titled Improving the Nation's Cybersecurity, covered many topics. Section 4 dealt with enhancing software supply chain security. It asked NIST to publish guidelines and standards, and it asked other agencies to turn them into procurement practice.
NIST maintains a resource page for the order that lists the outputs, including the Secure Software Development Framework (SSDF), guidance on software supply chain security for consumers, and a definition of what counts as critical software.
What is the SSDF and why does it matter here?
NIST SP 800-218 is a set of high-level practices in four groups: prepare the organisation, protect the software, produce well-secured software and respond to vulnerabilities. It is outcome-based and does not name tools. Federal procurement guidance pointed producers to it as the baseline for secure development.
If you sell to government, expect questions that map to SSDF practices. If you do not, it is still a sensible checklist that customers recognise.
What about SBOMs?
An SBOM is a nested inventory of the components in a piece of software. The order called for guidance on providing one to purchasers, and NIST and CISA have since published material on SBOM use. The format matters less than keeping it accurate for each release and being able to answer a question such as "do you ship this library?" quickly.
Has the policy stayed fixed?
No. Implementation went through OMB memoranda and later changes to the requirements, and executive actions since 2021 have adjusted parts of the approach. Do not rely on a summary, including this one, for contract language. Read the current text of the order and the memos that apply to your agency customers, and ask your contracting officer which attestation forms are expected.
A constructed example
A software company sells a reporting tool to a government agency. The agency's contract asks the vendor to confirm that it follows secure development practices consistent with NIST guidance and to provide an SBOM on request.
The vendor maps its existing process to the SSDF groups. Code review and branch protection cover protect. Dependency scanning and tests cover produce. A vulnerability intake page and a fix target cover respond. It generates an SBOM at release and stores it with the build record. When the agency asks about a newly disclosed library flaw, the vendor searches stored SBOMs and answers within hours.
Why should non-government suppliers care?
Large customers tend to copy federal procurement language into their own questionnaires. A supplier that can show SSDF-aligned practices and produce an SBOM on request answers those questionnaires in hours instead of weeks. That shortens sales cycles and reduces repeated security reviews. Even if you never sell to an agency, the order shaped what many buyers now expect to see, so building the habit once pays back across customers.
How to check or apply this
- Read the SSDF practices and rate your team on each.
- Produce an SBOM for every release and store it with the artifact.
- Keep evidence: review records, scan results, test runs and signed releases.
- Publish a vulnerability disclosure route and a fix policy.
- Check customer contracts for attestation language and who signs it.
- Re-check the current federal requirements each year, since they have changed.
Safeguard's SBOM and dependency scanning, policy gates and compliance automation can gather this evidence in one place. They support your attestation work. Safeguard does not certify you or attest on your behalf.
Quick check
Does EO 14028 apply to private companies?
Not directly. It binds federal agencies, but its procurement effects reach suppliers who sell software to them.
Is an SBOM the same as a vulnerability scan?
No. An SBOM lists components. A scan compares that list to vulnerability data. You use the SBOM to answer questions fast when new flaws appear.
Sources
- Executive Order 14028 resources, NIST
- NIST SP 800-218, Secure Software Development Framework, NIST
- Securing the Software Supply Chain: Recommended Practices Guide for Customers, CISA
Last reviewed: 18 October 2026.
