NIST SP 800-218 (SSDF):

Overview

NIST SP 800-218 v1.1 (February 2022) defines the Secure Software Development Framework: a set of outcome-based practices, not a prescriptive checklist, organized into four families: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. Executive Order 14028 and the resulting OMB memoranda made conformance with SSDF a precondition for selling software to the federal government.

Producers must sign the CISA-hosted attestation form, and the CEO or an authorized designee attests, to the best of their knowledge, that the practices are followed. The framework carries no formal third-party certification scheme, so demonstrating conformance rests on internal evidence and attestation rather than an audit certificate, which shifts the burden onto the organization to retain evidence that would hold up if the attestation were ever challenged.

Why it matters

The attestation is self-certification, but it is a formal, legally significant declaration: the signer is expected to retain evidence sufficient to defend it if challenged, and a false attestation carries exposure under the False Claims Act, a materially higher stakes outcome than a typical compliance gap.

PS.2 and PS.3, protecting code from tampering and providing a mechanism to verify release integrity, are two of the most evidence-intensive practices, and they map directly onto code signing and build-provenance capabilities that many software producers have not yet formalized. SSDF has also become the reference vocabulary buyers outside government use in vendor security questionnaires, so gaps here increasingly show up in commercial sales cycles as well as federal ones.

How this maps to cryptography 

NIST SP 800-218 (SSDF) addresses cryptography through several interlocking control areas. The key areas with direct cryptographic implications are:

Audit readiness

Assessments and examinations, whether self-conducted, performed by a regulator, or reviewed by an independent assessor, focus on demonstrated evidence rather than policy statements alone. Key areas that examiners and assessors commonly probe:

• Attestation Evidence Package:  Can the organization produce the evidence underlying its CISA attestation, not just the signed form itself?
• Code-Signing Key Protection:  Are code-signing keys protected against compromise, with access restricted to authorized build systems and personnel?
• Release Integrity Verification Mechanism:  Is there a working mechanism, not just a policy statement, for a consumer to verify that a release matches what the producer published?
• Build Pipeline Access Control Evidence:  Is access to source, build, and release infrastructure restricted and logged in a way that supports the PS.2 attestation?
• SBOM and Provenance Signing:  Are Software Bills of Materials and provenance attestations signed, enabling rapid verification when a component vulnerability is disclosed?
• CEO/Designee Attestation Defensibility:  Would the evidence on file actually support the attestation if it were challenged, rather than assumed to be sufficient?

TAKE THIS TO MANAGEMENT

Our CEO or an authorized designee is personally signing a legally significant document when we submit the CISA attestation, and that signature is only as defensible as the evidence sitting behind it. PS.2 and PS.3, protecting our code and proving release integrity, are exactly the practices code signing and key management were built to satisfy, so this isn’t a new capability to build, it’s evidence we may already be most of the way toward, if we can produce it.

This has stopped being a government-only requirement. Commercial buyers, particularly in finance and healthcare, are asking about SSDF alignment in vendor questionnaires now, which means a gap here costs us in sales cycles we don’t think of as federal at all. Getting our code-signing and provenance story straight once answers both audiences.