Do you still need the CISA secure software attestation form?

Maybe, but it depends on who is asking. The CISA Secure Software Development Attestation Form is a common form based on NIST SP 800-218. Since OMB M-26-05 rescinded the memos that required it, agencies may choose to use it or not. Check your contract and the agency's current policy.

What is the form?

CISA describes it as a common form that helps agencies and software producers reduce software supply chain risk, incorporating selected best practices from NIST SP 800-218, the Secure Software Development Framework. The page shows a revision date of May 14, 2024 and an English and a Spanish PDF.

The form is a statement by a producer that its software was developed in line with those practices. It is an attestation, not an audit or a certification, and no third party signs off on it.

Who is it for?

The CISA page does not say who must complete it. It says agencies may choose to use government-wide resources created under M-22-18, including the form, and may include contract terms requiring producers to provide a current SBOM.

OMB's M-26-05 memo of January 23, 2026 says agencies may choose to use the form, and rescinds the earlier memos. Under the old regime, attestations came from the producer of the end product, not from producers of third-party components, based on reporting of M-23-16.

What changed in 2026?

The shift is from a single process to agency judgment. M-26-05 says each agency head is responsible for assuring security of software on the agency's network and that there is no one-size-fits-all method. Agencies keep an inventory of software and hardware and write assurance policies to match their risk.

For a vendor that means the same product can face a full form from one agency, a questionnaire from another, and an SBOM request from a third.

How do you answer one honestly?

The form asks a company to stand behind statements about its development practices, so the answer should come from people who know them: engineering, security and legal together. Attestation is a signed claim by a named company officer. If your practice is partial, say so. A form signed over gaps can create legal exposure, while a clear plan with dates is a credible answer.

A constructed example

A software vendor receives three requests in one month. Agency A attaches the common form. Agency B asks for the vendor's SSDF mapping and an SBOM. Agency C sends its own 40 question risk survey. The vendor keeps one evidence pack: a practice-by-practice SSDF table with links to proof, a current SBOM and a list of known gaps with owners. All three requests are answered from it in a day each.

How to check or apply this

1. Ask the requester whether the form, a different questionnaire or an SBOM is wanted, and under which clause.
2. Map your practices to SSDF groups: prepare, protect, produce and respond.
3. For each practice, record the evidence: a policy, a pipeline setting, a log or a test report.
4. List gaps honestly with owners and dates.
5. Have one named officer review and sign. Do not delegate it to a form-filling tool alone.
6. Re-review before each new submission, since practices change.
7. Keep a current SBOM ready.

Safeguard can generate SBOMs and gather evidence from your pipeline through compliance automation. It does not attest on your behalf or make you compliant.

What do buyers outside government do?

Many commercial buyers borrow the form or the SSDF structure for their own vendor reviews. If a customer sends it, treat it the same way: a signed statement by an officer, backed by evidence you can produce on request. Reusing one evidence pack across the government and commercial requests keeps answers consistent and saves time.

Quick check

Sources

• CISA, Secure Software Development Attestation Form
• OMB M-26-05 (PDF)
• NIST, Secure Software Development Framework

Last reviewed: 18 October 2026.