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.

FAQGLOBALNIST SP 800-218 SSDF

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

Define release criteria, review evidence for the exact artifact, and record approval, rejection, or an authorized exception for unmet criteria.

SSDF Version 1.1 supports security checks and release decisions but does not prescribe one gate, threshold, approver, or evidence bundle.

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

SSDF does not prescribe one universal or severity threshold. Define criteria under PO.4 from the software's security requirements and risk decisions. At the gate, review the applicable design, code, component, build, and executable-test evidence; record approvals, rejections, and exceptions; and bind release-integrity and provenance records to the shipped artifact.

Search this module

Find a question or answer quickly

2 of 2 questions
Question 1

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

A should answer a defined decision: whether this identified release meets the organization's documented security-check criteria or has an authorized risk response for each unmet criterion. The evidence depends on the software and may include design-review findings, component decisions, code review or analysis, executable testing, build configuration, unresolved vulnerabilities, integrity-verification information, provenance, and required archives.

PO.4.1 recommends tracking criteria throughout the software development life cycle (SDLC) and recording approvals, rejections, and exception requests in the workflow. PO.4.2 recommends gathering and safeguarding the information used for those decisions. A gate can be automated, manual, or mixed; the organization should periodically review automated decision logic.

When criteria are not met, record the unresolved finding, affected release, decision authority, risk response, temporary or compensating action, owner, and expiry or reassessment trigger. A passed gate means the organization's stated decision criteria were met or excepted. It does not prove that the software is vulnerability-free or certify compliance with SSDF.

  • Criteria owner: define measurable checks, evidence, applicability rules, and who may approve, reject, or grant an exception.
  • Engineering and security owners: produce the selected design, component, code, test, build, vulnerability, integrity, and provenance records.
  • Release decision-maker: review current evidence for the exact release and record the outcome and rationale.
  • Exception authority: document unmet criteria, affected scope, risk response, owner, and expiry or reassessment trigger.
  • Post-release owner: monitor accepted risks and residual vulnerabilities and start the response process when new information changes the decision.
Question 2

Can one failed criterion be traced to an authorized release decision?

Test the gate against one planned release and one failed criterion. The workflow should identify the exact artifact, applicable checks, current evidence, decision authority, outcome, exception path, and post-release obligations without relying on an undocumented judgment.

  • Identify the product, version, build, release files, environment, and distribution channel covered by the decision.
  • List each applicable security-check criterion, its evidence, owner, status, and source requirement or risk decision.
  • Verify that evidence is current, protected from unauthorized alteration, and linked to this release.
  • Record the approver, timestamp, decision, unresolved findings, and rationale.
  • For each exception, record the authority, affected scope, risk response, temporary action, owner, and expiry or reassessment trigger.
  • Link the approved release to integrity-verification information, provenance, and the archived release record, then monitor accepted risks.

Does NIST SP 800-218 prescribe a universal ?

No. PO.4 recommends that the organization define and track software security-check criteria and safeguard the information used for decisions. A gate can be automated, manual, or mixed, and the organization sets the applicable checks, severity or risk thresholds, evidence, decision authority, and exception path for the covered software. SSDF does not supply one mandatory gate or blocking threshold.

What should happen when a release criterion fails?

Record the failed criterion, affected product, version, build, and release files; the current evidence; the decision authority; and whether the release is rejected, remediated, or handled through an authorized risk response. An exception should state the unresolved finding, rationale, temporary or compensating action, owner, and expiry or reassessment trigger. Keep post-release monitoring tied to accepted risks.

What does a passed NIST SSDF prove?

A passed gate shows that the identified release met the organization's documented criteria or that authorized exceptions covered unmet criteria at the time of decision. It does not prove that the software is vulnerability-free, that future vulnerabilities will not emerge, or that NIST certified the product or organization. Preserve the exact criteria, evidence, approver, timestamp, rationale, and release identity.

Recommended next step

Put this NIST SSDF guidance into practice

Use the cited SSDF tasks to define the scope, assign owners, list the required records, and set the decision or review point.

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 source coverage, ownership, evidence gaps, and next steps before using the decision.

Explore next step
Primary sources

References and citations

NIST SP 800-218 SSDF v1.1
doi.org3 citations
Referenced sections
  • Primary source for SSDF Version 1.1 security-check criteria, protected decision evidence, approvals, rejections, exceptions, risk responses, and release records.
  • PO.4.1 covers organization-defined security-check criteria and recorded approvals, rejections, and exception requests. PO.4.2 covers gathering, safeguarding, and automating information used for decisions. The PW and PS groups supply release-specific evidence when applicable.
  • PO.4 supplies the decision and evidence controls. PW.1.2 supports risk responses and approved exceptions. PS.2 and PS.3 cover release-integrity information, archives, and provenance. RV.1 and RV.2 cover post-release vulnerability identification and risk response.

Related guides

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 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.

Show all related guides (17)

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.

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 Secure Development Practices Guide

Place risk-tailored SSDF v1.1 tasks at the points where teams define requirements, design software, govern components, build, test, release, and respond to vulnerabilities.

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.

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.