We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

Artifact GuideGLOBALNIST SP 800-218 SSDF

NIST SP 800-218 SSDF Secure Development Practices Guide

Turn risk-tailored SSDF tasks into SDLC entry criteria, engineering activities, release evidence, supplier handoffs, and post-release feedback.

SSDF describes outcomes and notional examples rather than prescribing a specific SDLC, tool stack, scanner, severity threshold, or release process.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
5 sections1 primary sources
Overview

Integrate SSDF tasks throughout the (SDLC). The four groups are Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). A checklist completed after release misses PO preparation, PW design and development, PS protection of code and releases, and RV feedback into all three groups.

Section 1

Start with software, SDLC, and responsibility boundaries

Identify the producer entity, software and release family, SDLC model, repositories, build and test environments, deployment artifacts, third-party components, development suppliers, and acquirer expectations.

Map responsibilities where work occurs. An internal platform team may operate PO.3 and PO.5, product teams may perform PW tasks, suppliers may provide evidence used for PW.4, release engineering may own PS.2 and PS.3, and product security may coordinate RV. Version 1.1 retired PW.3: PW.3.1 moved to PO.1.3; the work from PW.3.2 is in final task PW.4.4 after PW.4.5 was merged into it.

  • Record each task as applicable, not applicable, inherited, supplier-performed, or deferred, with rationale.
  • Assign accountable and operating owners and state which acquirer or producer requirement the task addresses.
  • Define operating evidence and review triggers before automating checks or configuring release gates.
  • Keep SSDF guidance status separate from contractual or policy requirements that incorporate selected outcomes.
Section 2

Embed practices at the point of work

Convert outcomes into entry criteria, workflow steps, decision points, and records within existing delivery methods. A parallel "SSDF process" updated only for assurance reviews does not show how the practices operate in development.

Apply task-level checks at appropriate points: requirements and threat modeling before design decisions harden; component and code checks throughout development; integrity and provenance at release; and vulnerability monitoring and root-cause learning after release.

  • Plan | Maintain requirements, roles, training, toolchains, check criteria, and protected environments.
  • Design | Perform risk modeling, track security requirements and decisions, and review design against them.
  • Develop and build | Govern components, follow secure coding, configure builds securely, and review human-readable code.
  • Verify and release | Select executable testing by risk, triage results, configure secure defaults, archive releases, and publish integrity-verification information.
  • Operate and learn | Monitor vulnerabilities, investigate credible reports, remediate and communicate, and update the SDLC from root causes.
Section 3

Make release decisions risk-based and reviewable

A release record should identify the covered artifact, criteria, evidence, exceptions, decision-maker, and post-release owner. A tool result without its scope, configuration, triage, and disposition is not enough to support a release claim.

SSDF does not define one universal release gate. Define criteria from the software's security requirements and risk: required reviews and tests, triage thresholds, exception authority, release-integrity and provenance outputs, secure-default checks, and post-release ownership.

  • Security requirements and approved design and risk decisions for the covered release.
  • Component, code-review, analysis, test, triage, remediation, exception, and approval records.
  • Build configuration, artifact identifier, archive, integrity-verification information, and provenance or SBOM record.
  • Secure-default verification and acquirer information needed for secure deployment, operation, and maintenance.
  • Named RV owner and monitoring, disclosure, advisory, remediation, and root-cause feedback paths.
Section 4

Avoid tool-driven and release-only implementations

A scanner or software bill of materials (SBOM) covers only part of the work. It does not by itself address requirements, roles, environments, design, supplier verification, secure defaults, disclosure, remediation, or root-cause learning.

A passed gate also does not prove that the release is vulnerability-free. Preserve the test scope, limitations, triage decisions, accepted risk, and post-release response path.

  • Do not make every task identical across low- and high-risk software without a tailoring rationale.
  • Do not treat NIST's notional examples as the only permitted implementation or as mandatory tools.
  • Do not hide supplier-performed or inherited tasks inside a producer-wide claim.
  • Do not stop at release; RV monitoring and root-cause learning are part of the framework.
Section 5

Run an SSDF implementation through the release lifecycle

Run selected tasks inside the SDLC: establish PO foundations, apply PW activities during design and development, preserve PS release trust, operate RV after release, and feed vulnerability lessons back into requirements and engineering.

Record the covered software, task disposition, owners, evidence, exceptions, release decision, and reassessment triggers. This record is a practical implementation aid, not a NIST form.

  • Step 1 | Scope | Name the producer, software, release process, environments, components, suppliers, and acquirer requirements.
  • Step 2 | Tailor | Decide which PO, PS, PW, and RV tasks apply, who performs them, and what outcome and evidence each requires.
  • Step 3 | Integrate | Add the selected work to requirements, design, component intake, coding, build, review, test, and release workflows.
  • Step 4 | Release | Review current evidence, triage findings, document exceptions, archive the release, and make integrity and deployment information available as required.
  • Step 5 | Respond | Monitor vulnerability information, investigate and remediate by risk, communicate where appropriate, and update the SDLC from root causes.
Recommended next step

Put this NIST SSDF guidance into practice

Place selected SSDF tasks in the engineering workflow, name the owner and evidence for each task, and define release and reassessment decisions.

Assessment workflow
Open Assessment Autopilot for NIST SSDF

Create cited tasks, evidence requests, and review checkpoints for this NIST SSDF scope.

Explore next step
Talk to Sorena
Review this NIST SSDF scope with Sorena

Check task placement, release evidence, supplier handoffs, exceptions, and post-release feedback.

Explore next step
Primary sources

References and citations

NIST SP 800-218 SSDF v1.1
doi.org6 citations
Referenced sections
  • Primary source for task outcomes, risk-based tailoring, shared responsibility, optional examples, and the connections among PO, PS, PW, and RV.
  • Sections 2 and 3 support scoped, risk-based implementation and distributed responsibility; Appendix C records the retirement and relocation of PW.3 tasks.
  • Table 1 connects PO, PS, PW, and RV tasks to requirements, environments, design, components, code, testing, release integrity, provenance, vulnerability response, and root-cause analysis.
Show 3 more
  • PS.2 and PS.3 cover integrity information, release archiving, and provenance; PW.7 through PW.9 cover code review, executable testing, triage, and secure defaults.
  • Sections 2 and 3 say the examples are optional, practices vary by risk and applicability, and the SSDF is a basis for planning rather than a checklist.
  • Table 1 supplies the task outcomes used in this lifecycle; Section 3 states that table order does not prescribe implementation sequence or priority.

Related guides

NIST SP 800-218 SSDF Evidence Guide

Build a task-level SSDF evidence index for internal assurance, customers, acquirers, and contract reviews without implying NIST certification.

NIST SP 800-218 SSDF FAQ: practical implementation questions

Practical answers on SSDF Version 1.1 code analysis, components, builds, release gates, provenance, threat modeling, coding evidence, and vulnerability response.

NIST SP 800-218 SSDF implementation playbook

Implement final SSDF v1.1 by defining the software boundary, selecting applicable tasks by risk, assigning shared responsibilities, and retaining task-level evidence.

NIST SP 800-218 SSDF PO, PS, PW, and RV Practice Deep Dive

Map all 19 final SSDF v1.1 practices across PO, PS, PW, and RV, including each group's purpose, handoffs, tailoring decisions, and useful evidence.

NIST SP 800-218 SSDF SBOM and Provenance Workflow

Apply SSDF PS.3.2 to collect, protect, maintain, and share release-component provenance, including an SBOM, while keeping release integrity and component approval separate.

NIST SP 800-218 SSDF Self-Attestation Guide

SSDF v1.1 does not require self-attestation. Check the requesting agency or contract: OMB rescinded the former government-wide mandate in January 2026.

Show all related guides (17)

NIST SP 800-218 SSDF Self-Attestation Workflow

Validate an SSDF-based attestation request, bound the covered software and producer, test each representation against evidence, and retain the signed submission.

NIST SSDF vs NIST SP 800-53 SA controls: practical side-by-side comparison

Map NIST SSDF tasks to SP 800-53 Rev. 5 SA controls without treating references, shared evidence, or partial overlap as full implementation.

NIST SSDF vs SLSA: practical side-by-side comparison

Compare NIST SSDF v1.1 with SLSA v1.2 Source and Build tracks, including scope, levels, evidence, provenance, verification, and limits.

How should teams handle code scanning under NIST SP 800-218 SSDF?

Decide which code review, analysis, and executable testing apply, then retain scope, results, triage, remediation, and exception records.

How should teams handle components under NIST SP 800-218 SSDF?

Evaluate third-party and in-house components, track source, version, provenance, approval, affected releases, maintenance, and known-vulnerability decisions.

How should teams handle release gates under NIST SP 800-218 SSDF?

Define risk-based release criteria, gather protected evidence, record approvals and exceptions, and bind the decision to the shipped artifact.

How should teams handle threat modeling under NIST SP 800-218 SSDF?

Use risk modeling to assess software risk, connect findings to security requirements and design decisions, and revisit the record when its assumptions change.

How should teams handle vulnerability disclosure under NIST SP 800-218 SSDF?

Run a documented path from vulnerability intake and credibility review through risk-based remediation, acquirer communication, and root-cause feedback.

What build-integrity evidence supports NIST SP 800-218 SSDF?

Connect each release to its protected build environment, approved tool configuration, integrity-verification data, provenance, and archived release record.

What secure coding evidence should teams keep for NIST SSDF SP 800-218?

Keep evidence that shows which secure coding practices applied, how code was reviewed or analyzed, what issues were found, and how each issue was handled.

Why does provenance matter in NIST SP 800-218 SSDF implementation?

SSDF provenance records component origin and change history for each release so acquirers, operations, and response teams can identify affected software.