The CISA attestation form: when secure development became a signature

Most software-security requirements arrive as technical controls. The federal secure-software attestation arrived as something scarier: a form your leadership signs, under penalty of the False Claims Act, asserting that your development practices are what you say they are.

How we got here

The chain runs from Executive Order 14028 through two OMB memoranda (M-22-18 and M-23-16) to a common self-attestation form that CISA finalized in 2024. The substance: producers of software used by federal agencies attest that their development process conforms to a subset of practices drawn from NIST's Secure Software Development Framework (SSDF, SP 800-218).

The form's four practice areas are recognizable to anyone who has read the SSDF:

1. Software is developed in secured environments — access control, monitoring, separation of build infrastructure.
2. The producer makes a good-faith effort to maintain trusted source-code supply chains and manage third-party components.
3. Provenance data is maintained for internal and third-party code.
4. The producer checks for vulnerabilities with automated tooling and operates a disclosure and remediation process.

The part that changes behavior

Self-attestation sounds soft until you read who signs: the CEO or a designated corporate officer, on the record, with the government explicitly reserving fraud remedies for attestations that turn out to be false. That single design decision moved secure development from an engineering aspiration to a statement executives personally underwrite — which means executives now ask engineering for proof before signing. In our experience that conversation, more than any scanner, is what funds supply-chain work.

Attestation runs on evidence

You cannot honestly sign item 2 or 3 without knowing what third-party components are in your products — which is an SBOM program, whatever the form calls it. In practice the evidence trail for the four practice areas looks like:

• Component inventories per product and release, generated from the build, retained so you can answer for what shipped historically, not just what ships today
• Vulnerability monitoring records — findings, triage decisions, remediation timelines, and the VEX statements documenting exploitability calls
• Provenance records tying artifacts to the source and pipeline that produced them
• An audit trail showing the process operates continuously, not just in the week before signing

This is the same evidence base the EU CRA conformity assessment wants, and the same one an acquirer's diligence team wants — one program, three audiences. Teams using SBOMVault accumulate most of it as a side effect of normal operation: the inventories, the triage history, and the tamper-evident audit log are the attestation binder.

If federal isn't your market

The form technically binds only software sold into federal agencies. Practically, attestation language is already leaking into commercial procurement, because the form gives enterprise buyers convenient, pre-drafted wording for "prove your SDLC is real." Treat the SSDF practice areas as the floor your evidence should clear, and the next questionnaire — federal or not — is a lookup rather than a project.