A government contractor should build to NIST's Secure Software Development Framework, keep a current SBOM it can provide on request, and be ready to complete CISA's secure software attestation form. Agencies decide which of these they require, so read each solicitation. The program below works in order and can start with two people.
What is driving the requirements?
Executive Order 14028, issued 12 May 2021, directed NIST to identify or develop standards, tools and practices to improve software supply chain security, including criteria to evaluate software security and the security practices of developers and suppliers. NIST's page says the resulting guidelines are aimed at federal agencies but are also available for industry. The core outcome for builders is SP 800-218, the Secure Software Development Framework.
The rules around it keep moving. CISA's attestation page says the form is based on the SSDF and that, according to OMB Memorandum M-26-05, federal agencies must keep a complete inventory of software and hardware and set assurance policies aligned to their own risk assessments. It adds that agencies may choose to use the government-wide secure software development resources created under M-22-18, including the attestation form, and may include contract requirements for a current SBOM on request. So treat the form and the SBOM as likely asks, not universal ones, and check each contract.
Step 1: What does the SSDF ask for?
NIST describes the SSDF as a core set of high-level secure software development practices that can be added to any development process. The aims are fewer vulnerabilities in released software, lower impact when some remain, and attention to root causes. Because it gives suppliers and buyers a common vocabulary, its practice names are useful headings for your evidence. Start by mapping what you already do to those headings and listing gaps.
Step 2: Which first controls close the most gaps?
Choose practices that produce evidence automatically.
- Protect source and build: branch protection, reviewed changes, separate build credentials.
- Control third-party code: an approved source list, version pinning and review of new packages.
- Check for vulnerabilities: dependency, code and secret scanning in CI, with a triage record.
- Provide integrity: checksums or signatures for releases, and the commit that built each.
- Respond: a vulnerability disclosure contact and a fix process.
Step 3: How do you produce the SBOM?
CISA describes an SBOM as a nested inventory, a list of ingredients that make up software components. CISA also describes VEX, the Vulnerability Exploitability eXchange: an attestation, a form of security advisory, saying whether a product is affected by a known vulnerability. An SBOM tells a customer what is inside, and a VEX tells them which listed issues matter. CISA's page points to 2026 updates to the SBOM minimum elements, so check the current list of data fields before you design your output. Generate one per release, from the build, and store it with the artifact.
Step 4: What about the attestation form?
The form incorporates selected practices from SP 800-218. Someone senior in your company signs it, so the practices must be true on the day. Run an internal review against the form before any customer sends it. Where you cannot attest, write down the plan and the date, and tell the contracting officer early.
A constructed example
A twenty person contractor delivers a case management web application to a state agency and a federal customer. Two engineers spend six weeks. They map their pipeline to SSDF headings and find three gaps: no signed releases, no record of third-party package review and no disclosure contact. They fix each, generate an SBOM per release, and complete a draft attestation. When the federal customer asks for the form, the team returns it in a day, and the SBOM request that follows is a file attachment.
What to do
- List the contracts and customers that may require attestation or SBOM delivery.
- Map your lifecycle to the SSDF and record gaps.
- Add source, build and dependency controls that generate evidence.
- Generate and store an SBOM for every release, and keep a VEX process.
- Complete the attestation form internally and review it with leadership.
- Publish a vulnerability disclosure contact.
- Keep a customer packet: SBOM, attestation, policy summary, incident contact.
- Recheck agency guidance each quarter, since requirements are changing.
Safeguard SBOM generation, dependency scanning and compliance automation can feed the evidence, as in the CI/CD actions demo. Safeguard does not certify anyone, and no FedRAMP or similar authorisation is implied.
Quick check
Must every contractor submit the attestation form?
Not in every case. CISA says agencies may choose to use it, so the requirement depends on the contract and agency.
What is the difference between an SBOM and a VEX?
An SBOM lists the components in a product. A VEX states whether a product is affected by a particular known vulnerability.
Sources
- NIST: Executive Order 14028, Improving the Nation's Cybersecurity
- NIST SP 800-218: Secure Software Development Framework
- CISA: Secure Software Development Attestation Form
- CISA: Software Bill of Materials
Last reviewed: 18 October 2026.
