NIST SP 800-218 (SSDF): what self-attestation actually requires you to prove
Standard & Framework · Secure Software Development
Since EO 14028, software sold to the federal government requires a signed self-attestation against NIST SP 800-218, committing an accountable executive to evidence, such as an SBOM generated per release, that its 19 practices across 4 practice groups are implemented, not aspirational.
What does NIST SP 800-218 self-attestation require you to prove?
Since EO 14028, software sold to the federal government requires a signed self-attestation against NIST SP 800-218. An accountable executive commits to evidence, such as an SBOM generated per release, that its 19 practices across 4 practice groups are implemented.
Signing the attestation is a claim about evidence, not intent
For GovCon software, the CISA Secure Software Development Attestation Form requires a company officer to attest that software was developed in accordance with NIST SP 800-218's practices — evidence such as an SBOM generated per release, not a narrative. That's a specific, checkable claim across four practice groups — not a general statement that the team "takes security seriously."
The four practice groups
| Group | What it covers | Deterministic evidence, not narrative |
|---|---|---|
| PO — Prepare the Organization | Roles, security requirements, toolchain provenance | A named security-requirements document; a documented toolchain inventory |
| PS — Protect the Software | Source access control, component provenance, release integrity | Branch-protection config; a generated SBOM per release, not a hand-maintained list |
| PW — Produce Well-Secured Software | Design review, code review, third-party component vetting | Code-review approval records tied to specific commits; SOUP evaluation records |
| RV — Respond to Vulnerabilities | Disclosure process, remediation cadence, root-cause feedback | A public vulnerability-disclosure policy URL; remediation timestamps against a defined SLA |
Machine-readable evidence over a narrative attestation packet
The practical difference between a defensible attestation and a fragile one is whether the evidence behind each practice is machine-verifiable — an SBOM generated on every build (not a spreadsheet updated quarterly), a code-review record tied to a specific commit hash (not a checkbox in a ticket), a vulnerability-remediation timestamp computed from issue-tracker data (not recalled from memory when the attestation is due).
Readiness checklist
One item per practice group's key controls. Full checklist downloadable below.
PO: security requirements defined; roles documented; toolchain provenance evaluated
PS: source access protected; SBOM generated per release; release integrity protected
PW: design + code reviewed; third-party components vetted before use
RV: disclosure process public; remediation cadence defined; root cause fed backEngineering reference only. Not formal legal counsel. The CISA attestation form itself, and your own legal/compliance function, govern what you actually sign.
Artifact: ssdf-attestation-readiness-checklist.md
Generated client-side; no server round-trip, no account required.
# NIST SP 800-218 SSDF — Self-Attestation Readiness Checklist (v1.0.0)
Engineering reference checklist mapped to the four SSDF practice groups.
Not the CISA attestation form itself — a readiness check before signing it.
## PO -- Prepare the Organization
- [ ] Security requirements for software development are defined and communicated
- [ ] Roles and responsibilities for secure development are documented
- [ ] Toolchain is documented and its own supply chain is evaluated
## PS -- Protect the Software
- [ ] All forms of source code access are protected (branch protection, signed commits)
- [ ] Provenance of all software components is documented (SBOM)
- [ ] Software is archived and protected against unauthorized change post-release
## PW -- Produce Well-Secured Software
- [ ] Software design is reviewed to verify compliance with security requirements
- [ ] Source code is reviewed/tested to identify vulnerabilities before release
- [ ] Third-party components (SOUP/OSS) are reviewed and vetted before use
- [ ] Reusable code is verified before use in production builds
## RV -- Respond to Vulnerabilities
- [ ] A vulnerability disclosure process exists and is publicly documented
- [ ] Vulnerabilities are identified, assessed, and remediated on a defined cadence
- [ ] Root cause analysis is performed for identified vulnerabilities and fed back
into PW practices (closing the loop, not just patching the instance)
Useful next step
Provenance & review state
- Last reviewed
- Sources
-
- NIST SP 800-218: Secure Software Development Framework (SSDF) v1.1 — National Institute of Standards and Technology
- Executive Order 14028 — The White House
- Ingested from
-