The CISA Secure Software Development Attestation Form asked a producer to attest to four groups of practices drawn from NIST SSDF: secure build environments, trusted source code supply chains, provenance, and vulnerability checking. A CEO or designee with authority to bind the company signed it.
The four areas
Section III of the form (version 1.0) opens with "to the best of my knowledge, [the producer] presently makes consistent use of the following practices."
1. Secure development and build environments. Six sub-items: separate and protect each environment; log, monitor and audit trust relationships used for access; enforce multi-factor authentication and conditional access; document and minimize use of software products that create undue risk; encrypt sensitive data such as credentials to the extent practicable; and run defensive practices including continuous monitoring and incident response.
2. Trusted source code supply chains. A "good-faith effort" using automated tools or comparable processes to address the security of internal code and third-party components and manage related vulnerabilities.
3. Provenance. Maintain provenance for internal code and third-party components "to the greatest extent feasible."
4. Vulnerability checks. Use automated tools or comparable processes to check for security vulnerabilities, run them on an ongoing basis and before releases, have a policy to address findings before release, and operate a vulnerability disclosure program that handles reports in a timely way.
The form also commits the producer to notify any agency it submitted to if the producer stops making consistent use of the practices.
What the words commit you to
Note the hedges: "to the best of my knowledge," "good-faith effort," "to the greatest extent feasible," "to the extent practicable." They are real limits, but the form still says that willfully giving false or misleading information may violate 18 U.S.C. section 1001. Treat the hedges as room for honest judgment, not for guesses.
Who signed
The instructions say the CEO of the software producer or a designee who is an employee and has authority to bind the corporation signs. Alternatively, a third-party assessor organization, either FedRAMP certified or approved in writing by an agency official, could evaluate conformance, and the assessment is attached. In that case the producer need not sign.
Turning the four areas into evidence
If you want your own evidence file, keep one page per area.
- Environments: network diagram, SSO and MFA settings, log retention for build systems.
- Source chain: dependency scanning configuration and a sample of results.
- Provenance: how you record where internal and third-party code came from, for example signed commits or build provenance.
- Vulnerability checks: scan schedule, release gate rules, your disclosure policy URL.
The same pages answer many security questionnaires. For related questions, see RFP questions about a vendor's secure development practices.
Status today
CISA's page still lists the form and says agencies may choose to use resources created under M-22-18 after OMB M-26-05. See what changed for suppliers under M-26-05.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the inventory and notice how each component carries a source and version. That is the raw material for the provenance and vulnerability check areas.
Quick check
Did the form require an SBOM?
No. The form lists development practices. M-22-18 separately allowed agencies to ask for an SBOM based on criticality or their own determination.
Could a third party replace the CEO signature?
A qualifying third-party assessment could be attached instead, and then the producer need not sign.
Sources
Last reviewed: 19 October 2026.
