Secure Software Development Attestation for Software Companies, Explained
By Philip Luca — Founder of GovExpress; prior domain experience at Bloomberg Government and GovWin IQ.
At some point an agency, a prime or a reseller may send your software company a form asking you to attest that your product was built securely. Most often it’s the Secure Software Development Attestation Form published by CISA. It’s short and it asks for a signature, which makes it easy to underestimate.
This guide explains where the form came from, what it asks you to attest to, which software it covers, and how to answer it so the signature holds up.
Where the attestation came from
The requirement traces back to Executive Order 14028, Improving the Nation’s Cybersecurity, signed in May 2021. Section 4 of the order directed the government to set standards for the security of software it buys. NIST answered with the Secure Software Development Framework (SSDF), SP 800-218, a set of practices for building software securely.
OMB then told agencies how to apply it. Memorandum M-22-18 (September 2022) directed agencies to obtain a self-attestation from software producers that they follow secure development practices, and M-23-16 (June 2023) refined it. CISA published the common attestation form in March 2024, along with an online repository where producers can submit it.
Federal policy on this has continued to shift since then, and agencies apply it differently. Before you assume the form is mandatory for a particular deal, check the current OMB guidance and what your solicitation, contract or reseller actually asks for. The practices behind it remain the federal baseline either way.
What you attest to
The form groups SSDF practices into four commitments. The signer attests that the company:
| Commitment | What it means in practice |
|---|---|
| Secure development environments | Build and development systems are separated and protected, with access controls, multi-factor authentication, logging and monitoring |
| Trusted source code supply chain | You make a good-faith effort to manage the risk in the code you depend on, including third-party and open-source components |
| Provenance | You keep records of where your internal code and third-party components came from |
| Automated vulnerability checking | Tools check for security vulnerabilities, and you have a process to fix and disclose what they find |
The form is signed by the CEO or a designee who can bind the company. That is a corporate statement to the government, not a checkbox a developer fills in.
Which software it covers
As written, the attestation covers software a producer develops that runs on, or is used by, federal systems. It reaches:
- Software built after September 14, 2022, the date of M-22-18.
- Existing software that receives a major version change after that date.
- Software delivered through continuous changes, which describes most SaaS.
Software an agency develops itself, and open-source software an agency obtains directly and freely, are outside it. Third-party components inside your product are not: you answer for how you manage them under the supply chain and provenance commitments.
If you can’t attest to every practice, the process allows a plan of action and milestones that documents the gaps and how you’ll close them. An agency can then decide whether to keep using the software. A third-party assessment, for example by a FedRAMP third-party assessment organization, can be offered in place of a self-attestation.
SBOMs are a separate request
A software bill of materials lists the components in your product. The attestation doesn’t require you to hand one over, but agencies may ask for an SBOM separately, especially for software they treat as critical. If you already generate SBOMs in your build pipeline, the provenance commitment is much easier to stand behind.
An attestation is a vendor claim
The word that matters is self. Nobody inspects your build system before the form is accepted. The government relies on your signature, and so do resellers and primes that flow the request down. That is why it has to be accurate. A knowingly false statement to the government can create liability under the False Claims Act, and the Department of Justice has said it will pursue cybersecurity misrepresentations.
Self-attested isn’t the same as verified, and federal buyers know the difference. See verified vs. self-attested: what federal buyers actually check.
A practical approach before anyone signs:
- Map the four commitments to evidence: where the controls live, who owns them, and what logs or tool output show they run.
- Inventory your third-party and open-source components, ideally as an SBOM generated at build time.
- Document gaps honestly in a plan of action and milestones, not with an optimistic signature.
- Have the signer review the evidence, not only a summary of it.
- Revisit the record at each major release, since a major version change can bring the software back into scope.
How it relates to FedRAMP and CMMC
The attestation is about how your software is built. FedRAMP is about how a cloud service is operated and authorized, and an authorization doesn’t replace the attestation. The SSDF practices do overlap with the secure development controls an assessor will look at, so work on one supports the other. See from SOC 2 to FedRAMP and ATO for SaaS companies.
CMMC is a separate program for Department of War contractors that handle controlled information. It assesses your organization’s environment, not your product’s development lifecycle. See CMMC in 2026.
Where it fits in your federal readiness
Secure development is one line in a longer list of things a buyer expects to be settled before an offer arrives. It sits alongside the Section 889 telecom representation, country of origin under the Trade Agreements Act, license terms an agency can sign and accessibility documentation.
To see where your company stands across the categories federal buyers check, score your company’s federal readiness.
Related reading
The CMMC brief
What the Phase 2 suspension changed and what it did not — the obligations that still bind, the assessment path a contract puts you on, the scoping decision that drives the cost, and the sequence that fits inside a pipeline. Sourced from the primary record.