CISA SSDAF

Why does it matter?

A signed attestation is a statement to the federal government. The form's Privacy Act notice warns that willfully providing false or misleading information may violate 18 U.S.C. 1001, and that failing to provide the information may lead an agency to stop using the software. Software producers that sell to agencies need to know what they can truthfully attest, and what agencies may still ask for after M-26-05.

Key benefits include:

• One common form

Agencies share one form rather than each writing its own, and agency-specific requirements go in an addendum (form instructions).

• A defined scope

Software needs an attestation if it was developed after September 14, 2022, had a major version change after that date, or receives continuous changes, as software-as-a-service does.

• Binding on future versions

An attestation covers future versions of the named product until the producer notifies agencies that its practices no longer conform.

• A third-party route

A FedRAMP-certified or agency-approved Third Party Assessor Organization (3PAO) can assess conformance instead of a CEO signature.

• Clear status after M-26-05

The memo makes the form optional and lets agencies choose risk-based assurance, including SBOM terms, so producers should expect agency-specific requests.

How does it work?

The form has three sections plus an appendix. Section I records the type of attestation (new, following an extension or waiver, or revised) and whether it is company-wide, for an individual product or for multiple products. Section II gives the producer and primary contact. Section III is the attestation and signature. The appendix maps each statement to Executive Order 14028 section 4(e) and to SSDF practices and tasks such as PO.5.1, PS.3.1 and RV.1.1.

A producer confirms the software is in scope, gathers evidence for the four practice areas, and has the CEO or a designee who is an employee with authority to bind the company sign, or attaches a 3PAO assessment. The form goes to an agency through the online Repository for Software Attestations and Artifacts (softwaresecurity.cisa.gov) or as a PDF named Producer_Product_Version_Date. If a producer cannot attest to every practice, the instructions let an agency still use the software when the producer lists the practices it cannot meet, its mitigations and a plan of action and milestones (POA&M).

In SmartSuite, producers hold each attestation as a record with its product, version, signatory and date, link the evidence for each practice, track any POA&M, and record agency requests.

Key Elements

• Secure development environments (practice 1)

Separate and protect each environment, log and audit trust relationships, enforce multi-factor authentication and conditional access, minimize risky software, encrypt sensitive data such as credentials, and monitor and respond to incidents (1a to 1f).

• Trusted source code supply chains (practice 2)

A good-faith effort to maintain trusted source code supply chains using automated tools or comparable processes for internal code and third-party components, and to manage related vulnerabilities.

• Provenance (practice 3)

Maintain provenance for internal code and third-party components incorporated into the software to the greatest extent feasible.

• Automated vulnerability checks (practice 4)

Check for vulnerabilities on an ongoing basis and before releases, have a policy to address findings before release, and run a vulnerability disclosure program that responds in a timely way (4a to 4c).

• Signatory and assessment

The CEO or an employee designee with authority to bind the company signs, or the producer checks the 3PAO box and attaches the assessment, in which case no signature is needed.

• Scope tests and exclusions

Excluded are software developed by federal agencies, open source freely obtained by an agency, third-party components incorporated into the product, and freely obtained public software.

• Submission and records

Submit through the online repository or by emailed PDF; the form estimates 3 hours and 20 minutes per response and notes attestations must be updated if practices lapse.

What does it cover?

The form applies to software producers whose software is used by federal agencies and that meets one of three tests: developed after September 14, 2022; developed earlier but changed by a major version after that date; or delivered with continuous changes. Producers attest to practices for the code they develop. Third-party and open source components are outside the form, but producers attest to the steps they take to minimize the risk of relying on them.

What are its objectives?

The form lets a producer state, in one document, how its development practices protect software used by federal agencies.

Secure the environments used to develop and build software.

Maintain trusted source code supply chains for internal and third-party code.

Keep provenance for code and components to the greatest extent feasible.

Check for vulnerabilities with automated tools before and after release and run a disclosure program.

Notify agencies if the producer stops following the attested practices.

Give agencies a signed or independently assessed statement they can rely on under their own risk-based policies.

Framework in Context

The form is based on NIST SP 800-218 version 1.1 (February 2022), and its appendix maps each statement to SSDF tasks and to Executive Order 14028 section 4(e). NIST issued an initial public draft of SP 800-218 Rev. 1 (SSDF 1.2) on December 17, 2025. M-26-05 points agencies to SP 800-218, CISA's draft 2025 Minimum Elements for a Software Bill of Materials and CISA's Hardware Bill of Materials framework as options for their own assurance policies.

Common Framework Mappings

The CISA Secure Software Development Attestation Form is often mapped to recognized software security and risk management frameworks to demonstrate security practices, ensure regulatory alignment, and simplify compliance reporting.

Mapped frameworks include:

CIS Controls v8.1

FedRAMP Rev. 5

ISO 27001:2022

ISO 27002:2022

NIST CSF 2.0

NIST SP 800-161 Rev.1

NIST 800-218 SSDF

NIST 800-53 Rev.5

PCI DSS 4.0.1

SOC 2