The NIST Secure Software Development Framework (SSDF), published as SP 800-218, is the closest thing the industry has to a shared checklist for building software securely. It does not tell you which tools to buy or which languages to use. It lists outcomes, grouped into practices and tasks, and leaves the how to you.
This post is for the engineers who end up holding the evidence. It covers the four practice groups, the specific tasks that code scanning genuinely supports, the ones it does not, and where the federal attestation requirement that made SSDF famous stands now.
Which version of the SSDF applies?
The current final version is SSDF version 1.1, SP 800-218, published in February 2022. In December 2025 NIST released an initial public draft of version 1.2 (SP 800-218r1) for comment, prepared under Executive Order 14306. A draft is not the framework, so the task numbers in this post are from version 1.1. NIST has also published SP 800-218A, a community profile that adds practices for generative AI and foundation model development.
The four practice groups
SSDF 1.1 organises its practices into four groups:
| Group | What it asks for |
|---|---|
| Prepare the Organization (PO) | People, processes and technology ready to do secure development: requirements, roles, toolchains, security check criteria, protected environments |
| Protect the Software (PS) | Code and releases protected from tampering and unauthorized access, with a way to verify release integrity and archived provenance |
| Produce Well-Secured Software (PW) | Software designed, written, reviewed, built and tested to minimise vulnerabilities |
| Respond to Vulnerabilities (RV) | Residual vulnerabilities found, prioritised, fixed and analysed so they do not recur |
Each practice has an identifier such as PW.7, and each task under it a further number such as PW.7.2. One numbering quirk trips people up: there is no PW.3 in version 1.1, because its content was moved into PW.4.
The tasks code scanning supports
Static analysis is not one SSDF control. It is evidence for a handful of tasks, mostly in PW and RV.
PW.7: review and analyze human-readable code
PW.7 is the practice that fits most directly. Its two tasks:
- PW.7.1: decide whether code review (a person reads the code), code analysis (tools find issues, automatically or with a person) or both should be used.
- PW.7.2: perform the review or analysis against your secure coding standards, and record and triage every issue and recommended fix in the team's workflow or issue tracker.
Among the notional examples NIST lists for PW.7 are using a static analysis tool with a human reviewing what it reports, and using automated tools to identify unsafe practices continuously as code is checked in. The second half of PW.7.2 is often forgotten: findings must land where they are triaged.
PW.4: reuse well-secured software
PW.4.4 asks you to verify that acquired commercial, open-source and other third-party components comply with your requirements throughout their life cycles. Dependency scanning against vulnerability data is the obvious evidence, run on every change and not only at intake.
PS.3.2: provenance for every release
PS.3.2 asks you to collect, safeguard, maintain and share provenance data for all components of each release, and names a software bill of materials (SBOM) as the example. An SBOM generated from lockfiles per release, archived with the release, is a direct answer.
RV.1 and RV.3: find what slipped through
RV.1.2 asks you to review, analyze or test the code to find previously undetected vulnerabilities, which is what re-scanning released code with updated rules does. RV.3.3 asks you to look for similar vulnerabilities to eradicate a whole class, rather than waiting for external reports. When one injection bug is found, a scan for the same pattern across every repository is the fastest way to do RV.3.3.
PO.4: criteria for security checks
PO.4.1 asks you to define criteria for software security checks and track them through the life cycle. A release gate is a written criterion that runs: for example, no new High or Critical findings in a pull request.
What code scanning does not cover
Be explicit with an auditor about the rest:
- PW.8, test executable code. PW.8 is about testing running code (dynamic testing, fuzzing, functional security tests). A static scan does not test executables, so do not claim it.
- PO.2, roles and training. People controls.
- PO.5, protected development environments and PS.1, protecting code from tampering. These are evidenced by repository permissions, branch protection, signed commits and hardened endpoints.
- PS.2, release integrity. Signing and published hashes.
- RV.1.3, a vulnerability disclosure policy. A document and a process.
- PW.1 and PW.2, design and design review. Threat modelling happens before code exists.
Where SSDF attestation stands
SSDF became widely known because of federal procurement. OMB memoranda M-22-18 and M-23-16 required agencies to collect attestations from software producers, and CISA published the Secure Software Development Attestation Form, whose statements map to SSDF practices.
On 23 January 2026 OMB issued M-26-05, which rescinds both memoranda. Agencies may still choose to use the attestation form and may require an SBOM by contract, but neither is mandated government-wide; each agency validates suppliers based on its own risk assessment. The memo points agencies to SP 800-218 as a reference.
So for most teams the SSDF is now what it always was underneath: a framework customers, auditors and contracts may ask you to map to. Federal buyers can still ask, so a mapping you can produce on demand is still worth having.
Producing SSDF evidence with Vulkro
Vulkro Core has a nist-ssdf compliance profile that maps findings to SSDF tasks, plus the commands that cover the release-level tasks:
# control view: which SSDF tasks have failing findings
vulkro compliance . --profile nist-ssdf
# the same mapping inside an HTML report for the auditor
vulkro report . --profile nist-ssdf -o ssdf-report.html
# PS.3.2: an SBOM per release, and a completeness check on it
vulkro sbom . > sbom.cdx.json
vulkro sbom --check sbom.cdx.json
# PW.7.2 and PO.4.1: review every change, fail only on what it introduced
vulkro gate --base origin/mainA control shows FAIL when a Critical or High finding maps to it, WARN for Medium or Low only, and NOT EVALUATED when nothing maps to it. Not evaluated is not a pass: it means the scan has no evidence either way. Process tasks such as PO.2 or RV.1.3 still need their own evidence whatever the profile shows. Findings come with file, line and, where Vulkro can prove it, the attack path from an entry point to the sink, so the triage step in PW.7.2 starts from evidence rather than a pattern match. vulkro scan . --save keeps a dated local history for the audit period.
FAQ
What are the four practice groups of NIST SSDF?
Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). Each group contains practices such as PW.7, and each practice contains numbered tasks such as PW.7.2.
Is SSDF attestation still required for federal software?
Not government-wide. OMB memo M-26-05 of January 2026 rescinded M-22-18 and M-23-16. Agencies may still use the CISA attestation form or ask for an SBOM by contract, so check what each agency contract says.
Does static analysis satisfy NIST SSDF?
It supports specific tasks, mainly PW.7 (code review and analysis), PW.4.4 (third-party components), PS.3.2 (provenance through an SBOM) and RV.1.2 and RV.3.3 (finding undetected and similar vulnerabilities). It does not cover executable testing in PW.8, training, environment protection or release signing.
See the compliance evidence use case and the compliance overview, or start a 14-day trial. Related: SOC 2 and ISO 27001 evidence from code scanning and what auditors accept from a scanner.