For three decades, cryptography sat quietly in the background of software development. It protected traffic and signed the occasional release, but it rarely reached the boardroom.
That has changed. Today a chief executive personally signs a document stating that their company follows secure development practices, and the SSDF sits at the center of that promise.
That signature is not a formality. It is a formal, legally significant declaration, and the evidence behind it has to hold up if a federal buyer ever asks to see it. This guide explains what the framework asks for, why code signing and key management carry the weight, and how to build defensible proof.
What NIST SP 800-218 (SSDF) actually is
The Secure Software Development Framework (SSDF) is NIST Special Publication 800-218. NIST published version 1.1 in February 2022.
Rather than a prescriptive checklist, the SSDF describes outcomes that secure development should achieve. That lets teams map it onto whatever development life cycle they already run. The framework organizes those outcomes into four groups:
- Prepare the organization: Make sure people, processes, and tools are ready to develop software securely.
- Protect the software: Guard all forms of code from tampering and unauthorized access.
- Produce well-secured software: Design, build, and test software so it has few vulnerabilities at release.
- Respond to vulnerabilities: Find, assess, and remediate issues in released software, then prevent recurrence.
Why SSDF became a procurement requirement
The framework moved from good practice to purchasing condition because of a chain of federal policy. Executive Order 14028 (May 12, 2021) directed agencies to raise the bar on software supply chain security.
OMB Memorandum M-22-18 (September 14, 2022), as amended by M-23-16 (June 9, 2023), went further. It made attested SSDF conformance a precondition for federal agency use of covered software. In practice, producers had to sign before agencies could keep buying. Executive Order 14306 (June 6, 2025) then struck the EO 14144 provisions on attestations and FAR contract language, and directed NIST to update the SSDF.
The current position is more nuanced. OMB Memorandum M-26-05 (January 23, 2026) rescinded M-22-18 and M-23-16, replacing the government-wide mandate with an agency-led, risk-based approach. Use of the CISA Common Form is now optional for agencies rather than required. Agencies keep discretion to request attestations and SBOMs, and FAR Case 2023-002 remains open.
Who has to care (and it is not only federal vendors)
Three groups feel this directly. First, any software producer selling to federal agencies. Second, the CEO or authorized designee who actually signs.
Third, and increasingly, commercial buyers. Banks, healthcare organizations, and large enterprises now reference the SSDF in vendor risk questionnaires. The framework has become a shared vocabulary for secure development, so it reaches well beyond federal deals.
The attestation is a signature, not a checkbox
Producers sign the CISA-hosted Secure Software Development Attestation Form. The CEO or a designated executive attests, to the best of their knowledge, that the practices are in place.
Here is what raises the stakes: there is no third-party certification scheme. No auditor issues a certificate that settles the question. Conformance rests entirely on the evidence a producer retains internally.
The form warns that willfully providing false or misleading information may violate 18 U.S.C. § 1001, a criminal statute, and a false attestation can also create civil False Claims Act exposure. That turns a documentation gap into a legal risk, which is why the proof behind the signature matters as much as the signature itself.
The practices that carry the most cryptographic weight for SSDF
Several practices depend directly on code signing and key management. These are the ones assessors can verify with cryptographic evidence, so they deserve the most attention.
PS.1: protect all forms of code from tampering
PS.1 asks producers to protect source, build, and release artifacts from unauthorized change. That means enforcing access controls and integrity protection across the pipeline. Signed commits and protected build systems give you tamper evidence you can prove later.
PS.2: give consumers a way to verify release integrity
PS.2 asks for a mechanism that lets consumers confirm a release matches what the producer published. In practice, you cryptographically sign every release artifact and publish the verification material. Anyone downloading the software can then check the signature before trusting the code.
PS.2 and PO.5: protect the signing keys themselves
A signature is only as trustworthy as the key behind it. PS.2 calls for periodic review of the code signing process, including certificate renewal, rotation, revocation, and protection. PO.5 covers the secure environments where signing takes place, including build and distribution environments.
That means generating and storing private keys in hardware, restricting who can sign, and reviewing renewal, rotation, and revocation on a schedule. A stolen signing key lets an attacker sign malware that looks like yours, so this control protects both you and your customers.
PW.6: compilation hardening
PW.6 is titled “Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security.” It sits next to artifact signing rather than replacing it.
Its goal is to reduce the number of vulnerabilities, and the cost of fixing them, by eliminating defects before testing begins. It has two tasks. First, use compiler, interpreter, and build tools that offer security-improving features. Second, decide which features to use, configure them, and apply the approved configurations consistently.
RV.2: signed SBOMs and provenance for fast response
When a vulnerability is disclosed, speed depends on knowing exactly what shipped. RV.2 favors signed Software Bills of Materials and provenance attestations. Signed SBOMs let you identify affected components quickly and prove the inventory is authentic, which shortens the window between disclosure and remediation.
Building the evidence package that defends the attestation
The signed form is the smallest part of conformance. What defends it is an evidence package that shows the practices actually run. Assemble these six items and front-load the proof for each:
- Attestation evidence package: Keep the signed form plus the artifacts that substantiate every claim it makes.
- Code-signing key protection: Show that private keys live in hardware and that signing is access-controlled.
- Release-integrity verification: Demonstrate a working mechanism consumers can use to verify a release.
- Build-pipeline access control: Retain logs proving who could access build and release infrastructure, and when.
- Signed SBOM and provenance: Produce signed component inventories and provenance data for released software.
- Honest self-assessment: Ask whether this evidence would survive a challenge, then close any gap you find.
How Keyfactor can help
Keyfactor gives software producers a way to turn these practices into evidence that comes from one system rather than a dozen disconnected tools.
Keyfactor AgileSec is the foundational first step. It discovers and inventories cryptographic assets across code, build pipelines, and cloud infrastructure, so you can see where signing keys and certificates actually live. AgileSec also produces signed SBOM and provenance data that supports RV.2, along with centralized reporting for the attestation evidence package.
EJBCA issues and manages the certificates behind trusted signing. It provides the certificate authority and the code-signing certificates that anchor signing identities across your build and release chain.
Keyfactor SignServer centralizes signing itself. It signs commits, releases, build outputs, and container images from a single system, which maps directly to PS.1, PS.2, PS.3, and the hardened builds behind PW.6. For distributed CI/CD teams, Keyfactor Signum adds code signing inside existing developer workflows.
Keyfactor Command automates the certificate and key lifecycle that PO.3 and PS.2 demand. It manages the lifecycle of code-signing keys and certificates and generates the centralized reporting that feeds your attestation evidence package.
Tie these together with the Keyfactor Trust Control Plane, a single system of record that observes, provisions, orchestrates, and governs signing keys and evidence. When the proof behind your attestation comes from one place, defending it becomes routine rather than a scramble.
Make SSDF a signed, provable capability
SSDF conformance is an operating capability, not a one-time project. Keys rotate, pipelines change, and vulnerabilities surface, so the evidence has to stay current.
The upside is leverage. The same signing and evidence infrastructure that backs a federal attestation also answers commercial security questionnaires from banks, healthcare, and enterprise buyers. Build it once and you satisfy both.
Start now: inventory how your code and releases are signed, confirm how signing keys are protected, and stand up evidence you could defend under scrutiny. Request a Demo to see how Keyfactor makes secure development a signed, provable capability.
Got SSDF questions? We’ve got answers.
What is NIST SP 800-218 (SSDF)?
NIST SP 800-218 is the Secure Software Development Framework, a set of outcome-based practices in four groups: prepare the organization, protect the software, produce well-secured software, and respond to vulnerabilities. It describes what secure development should achieve rather than prescribing a fixed checklist.
Who has to comply with the SSDF?
Any software producer selling to the federal government may need to self-attest to following SSDF practices. Commercial buyers such as banks, healthcare organizations, and large enterprises increasingly reference the SSDF in vendor risk questionnaires, so its reach extends well beyond federal deals.
What is the CISA Secure Software Development Attestation Form?
It is the form software producers sign to declare that they follow SSDF practices. M-22-18 and M-23-16 required agencies to collect it. OMB rescinded both in January 2026, so use of the form is now an agency decision. Where an agency asks for it, the CEO or a designee who is an employee with authority to bind the company signs, attesting to the best of their knowledge that the practices are in place.
Is the SSDF attestation legally binding?
Yes. It is a formal, legally significant declaration, and the signer is expected to retain evidence sufficient to defend it if challenged. A false attestation can create exposure under the False Claims Act, which raises the stakes above a typical compliance gap.
How does code signing relate to the SSDF?
PS.1 protects all forms of code from tampering through commit signing, code signing, and hashes. PS.2 asks for a release-integrity verification mechanism using code signing, published hashes, and periodic review of certificate renewal, rotation, revocation, and key protection. PS.3 covers archiving releases with their integrity and provenance data.
What evidence do assessors look for?
They look for the proof behind the attestation, not just the signed form: protected code-signing keys, a working release-integrity verification mechanism, logged access control over build infrastructure, and signed SBOMs and provenance. The core question is whether that evidence would hold up if the attestation were challenged.
Does the SSDF require a third-party certification?
No. The framework carries no formal third-party certification scheme, so demonstrating conformance rests on internal evidence and attestation rather than an audit certificate. That places the burden on the organization to retain defensible proof.
What is the first practical step toward SSDF conformance?
Start by gaining visibility into how code and releases are signed and how signing keys are protected. Then formalize a signed build pipeline and centralize the evidence. Building that capability once lets you answer both federal attestations and commercial security questionnaires from the same system of record.
