Vendors selling software to US agencies should keep evidence ready for secure development practices, an SBOM per release, a signed attestation if asked, and a vulnerability handling process. Since January 2026 what an agency asks for varies by agency and contract, so read each contract and ask the buyer.
What changed for federal software buyers?
OMB memo M-26-05, dated 23 January 2026, rescinded M-22-18 and M-23-16. It tells agencies to maintain an inventory of software and hardware and write assurance policies matched to risk. It lets agencies choose to use the secure software development attestation form and to adopt contract terms requiring a current SBOM on request, and for cloud platforms an SBOM of the runtime production environment.
The CISA form page confirms that agencies may choose to use the form, which is based on NIST SP 800-218.
So there is no single universal rule. Assume nothing is blanket, and confirm per contract. Other frameworks may also apply to your product, such as cloud authorization programs, which this post does not cover.
What evidence should you keep ready?
1. Secure development practices. The NIST SSDF is the reference named by both OMB and CISA. Map your own practices to it: how you protect code, build, test, review and respond to vulnerabilities. Keep dated records, not just a policy document.
2. SBOMs. One per release, in SPDX or CycloneDX, aligned with the 2026 minimum elements: all components including transitive, explicit unknowns, a tool name and version, a timestamp and ideally a signature.
3. A completed attestation, ready to sign. If an agency asks, someone with authority must sign. Decide who that is and what evidence backs each statement.
4. A vulnerability handling process. How you receive reports, rank them, fix them and tell customers. Include how you decide exploitability, and whether you issue VEX statements.
5. Build integrity evidence. Provenance for your releases, access control for your pipeline, and pinned dependencies. SLSA gives a vocabulary for build levels.
6. Third party and open source controls. How you choose, track and update components.
7. Contract tracking. A register of every government contract and the specific clauses on security.
What does this look like?
Constructed example: a vendor gets a request from one agency for the attestation form and an SBOM for the runtime environment of its hosted product. A second agency asks only for a questionnaire. The vendor's evidence folder holds an SSDF mapping, recent SBOMs, a vulnerability policy with metrics and a named signer. It answers the first in two days, and reuses the same material for the second.
What do buyers tend to probe in follow up?
Expect questions on how you handle vulnerabilities in third party components, how fast you notify customers, and how you protect your build system. Be ready with real examples: an advisory you handled, the timeline, and the notice you sent. A story with dates is stronger than a policy statement.
Also expect questions about open source. Have a short answer on how you choose and update dependencies, and show an SBOM that reflects it. Buyers rarely need a perfect answer. They need a consistent one that matches your evidence.
What to do
- Build a contract register with each security clause and its owner.
- Write an SSDF mapping with links to evidence, and review it twice a year.
- Automate SBOM generation per release, plus a runtime SBOM for hosted products.
- Name the person who signs attestations and train them on what they sign.
- Document vulnerability handling, with target times.
- Do not claim certifications or conformance you do not hold. Describe practices accurately.
- Review the current OMB memo and your contract before every renewal.
Safeguard's SBOM and dependency scanning, policies and gates and compliance automation can help organize this evidence. Safeguard makes no claim that your product or its own platform meets any federal requirement.
Quick check
Is an SBOM required for every federal sale?
Not as a blanket rule. Agencies may choose contract terms requiring one on request. Check the contract.
Does the attestation form still matter?
Agencies may still choose to use it. If a contract or buyer asks for it, you need to provide it.
Sources
- OMB M-26-05 (23 January 2026)
- CISA, Secure Software Development Attestation Form
- NIST SP 800-218, Secure Software Development Framework
- CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM)
- SLSA specification v1.0: levels and tracks
Last reviewed: 18 October 2026.
