The CISA Secure Software Development Attestation Form is a common form in which a software producer states that it follows selected secure development practices drawn from NIST's SSDF. It was created for sales to US federal agencies. Its current role has changed, so check the latest federal guidance before you rely on it.
What is the form based on?
CISA's page says the form is based on NIST SP 800-218, the Secure Software Development Framework version 1.1, and incorporates selected practices from it to help agencies and software producers safeguard the software supply chain against vulnerabilities and cyberattacks. The page lists the form's revision date as 14 May 2024 and offers it in English and Spanish.
The SSDF itself is a set of practices grouped by purpose: prepare the organization, protect the software, produce well-secured software and respond to vulnerabilities. The form picks out a subset and asks the producer to attest that it follows them.
What is its status now?
CISA's page, as fetched on 18 October 2026, says that under OMB Memorandum M-26-05, "Adopting a Risk-Based Approach to Software and Hardware Security", federal agencies must maintain a complete inventory of software and hardware and establish assurance policies and processes aligned with their risk assessments and mission needs. It says agencies may choose to use the government-wide resources created under the earlier memorandum M-22-18, including this form, and may elect to include contractual requirements for software producers to provide a current Software Bill of Materials on request.
In plain terms, the page presents the form as an available resource that agencies may use, not a blanket requirement for every sale. Individual agencies and contracts may still ask for it or for something similar. We have not fetched the text of M-26-05 itself, so read it, and your contract, for the binding wording.
Who signs it, and what does signing mean?
An attestation is a statement made by the producer. Under the original program, an authorized company officer signed. A false attestation can carry legal consequences, which is why companies should have evidence behind every line. We have not fetched legal guidance for this post, so ask counsel about liability for your own situation.
What does a constructed preparation look like?
A software company with 80 employees receives a customer request for the form. An engineering lead and the security lead sit down with the SSDF. For each practice, they write where the evidence lives: code review rules in the repository settings, build logs from the pipeline, a vulnerability tracking process with owners and dates, and a record of how the company gathers and reviews third-party components. Two gaps surface: no written vulnerability disclosure policy, and no SBOM for the oldest product. They fix both before anyone signs.
What are common pitfalls?
The most frequent mistake is signing from memory. Someone reads a statement about code review, thinks "we mostly do that", and signs. Mostly is not the same as attested. Another is scope: the form refers to specific products, and a company with several products may meet the practices in one and not another. A third is staleness. Practices that held last year may have slipped after a team change. Treat each attestation as a snapshot with a date, and refresh the evidence before renewing it.
How to check or apply this
- Download the current form from CISA's page and read each statement.
- Check the contract or request for the exact version and wording the customer expects.
- Map each statement to evidence you already hold: pipeline settings, review records, test results, tickets.
- List the gaps, fix them, and then attest. Do not sign for practices you plan to adopt later.
- Produce SBOMs for shipped products where the customer asks, and keep them current.
- Name who signs, and brief them on what is behind each line.
- Keep a dated copy of the evidence you used.
- Note in your calendar to recheck federal guidance, as the status has shifted.
Safeguard supports SBOM and dependency scanning and compliance automation, which can help gather evidence of this kind. The company attests; no tool does it for you.
Quick check
Does the form certify my software as secure?
No. It is a self-attestation about development practices. It is a statement by the producer, not a third-party certification.
Is it still required for federal sales?
CISA's page describes it as a resource agencies may choose to use. Requirements can still appear in particular contracts, so check the one you are bidding on.
Sources
- CISA, Secure Software Development Attestation Form
- NIST SP 800-218, Secure Software Development Framework
Last reviewed: 18 October 2026.
