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 Evidence for Assurance Reviews

For each claimed SSDF task, show what operated, who performed it, which software and period it covered, what record supports it, and what limits the conclusion.

SP 800-218 does not define a certification scheme or universal audit procedure. The requester, contract, or internal review plan sets the criteria, sample, reviewer, and required depth.

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

Start with the exact claim, then collect only the needed to test it. SSDF evidence should show how a named practice and task operated for defined software, releases, environments, suppliers, and a stated period. A policy records intent, an operating record shows execution, and a decision record explains tailoring, exceptions, and accepted risk. Keep them distinct.

Section 1

1. Define the claim, scope, and review criteria

Name the requester, governing document, software boundary, period, selected SSDF tasks, and exact representation being tested. An internal improvement review, supplier response, customer questionnaire, acquisition review, and contractual assessment can use the same SSDF vocabulary while applying different criteria.

Record the producer, product and versions, development and release processes, environments, components, suppliers, exclusions, and shared responsibilities. A conclusion cannot be broader than that boundary.

  • Scope | Producer, software, software development life cycle (SDLC), release or period, environments, components, suppliers, and exclusions.
  • Claim | Exact practice and task identifier, plain-language outcome, implementation owner, and responsibility boundary.
  • Criteria | Governing source, review method, sample, period, acceptance criteria, exception treatment, and reviewer independence if required.
  • Result | inspected, limitation, gap, decision, approver, and next review trigger.
Section 2

2. Match evidence to the exact SSDF task

Build the index at task level. For each claim, state the expected outcome, owner, system of record, period, review method, result, and limitation. Link a shared record to each task it supports, but do not stretch it across unrelated outcomes. The four groups are Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV).

SP 800-218 task PO.3.3 addresses configuring tools to generate secure-development artifacts. Its examples include workflow audit trails, review frequency, retention policies, and assigned responsibility. Those examples are useful -design options, not mandatory audit criteria.

  • PO | Security requirements, role assignments, training records, toolchain configuration and audit trails, check criteria, and development-environment controls.
  • PS | Repository access and change history, release archives, integrity-verification information, component inventory, software bill of materials (SBOM), and release-linked provenance.
  • PW | Threat and design records, component reviews, coding and code-review records, build configuration, test plans and results, issue triage, and approved exceptions.
  • RV | Vulnerability intake, investigation and component monitoring, prioritization, remediation, advisories, fix delivery, and root-cause improvements.
Recommended next step

Put this NIST SSDF guidance into practice

Define the exact claim and software boundary, map it to SSDF tasks, inspect operating records, and report a bounded result with gaps and exclusions.

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

Review the software boundary, task claims, operating records, exclusions, and unresolved evidence gaps.

Explore next step
Section 3

3. Test evidence quality and operation

Inspect the record, do not merely list its filename. Confirm who produced it, when, through which process, for which software and period, and whether it records a completed action or only planned work. When a task calls for it, trace sampled items from requirement through execution, result, triage, and closure.

generated by the operating workflow is usually easier to trace than a document assembled after the fact. Protect records from inappropriate alteration, preserve relevant versions, and restrict sensitive source code, credentials, vulnerability details, build information, and supplier material.

  • Relevance | The record supports the exact task, scope, software, and period being claimed.
  • Reliability | Source system, collection method, record history, integrity protection, and reviewer are known.
  • Operation | The record shows execution, not only policy, tool purchase, or intended design.
  • Coverage | Sampling and exclusions are explicit; supplier and inherited responsibilities are visible.
  • Currency | The falls within the stated period, and material changes, vulnerabilities, releases, or expired exceptions trigger reassessment under the review plan.
Section 4

4. Report the bounded result

State which tasks were tested, for which software and period, against which criteria, using which sample, and with what result. Separate implemented, partially implemented, not implemented, not applicable, not tested, and inherited conclusions. Explain exclusions and limits.

An review supports only the scope and criteria tested. It does not create a NIST certification, erase exclusions, prove that every SSDF task applies, or establish that the same practices operate across other products, suppliers, pipelines, or periods.

  • Do not treat a policy, tool configuration, SBOM, scan, or signature as proof of all SSDF practices.
  • Do not reuse a result for another product, pipeline, supplier, release, period, or authority without reassessment.
  • Do not publish sensitive merely to make the claim verifiable; use controlled review and an evidence index.
  • Do not present NIST's notional implementation examples as mandatory audit criteria unless the governing authority adopts them.
Section 5

Evidence index fields and review sequence

Run the review from the claim backward. Define scope and criteria, map each claim to a task, inspect operating records, record the result and limits, approve the bounded conclusion, and set the next review or material-change trigger.

Keep the index separate from sensitive underlying records. A reviewer can use the index to locate controlled evidence without copying source code, credentials, vulnerability details, or supplier-confidential material into the report.

  • Claim | Governing source, exact representation, SSDF practice and task, expected outcome, and applicability rationale.
  • Scope | Producer, software and versions, release or period, environments, components, suppliers, responsibility boundary, and exclusions.
  • | Artifact name, system of record, owner, creation date, covered period, sensitivity, retention, and stable locator.
  • Test | Reviewer, method, sample, criteria, result, exceptions, corroborating records, and limitation.
  • Decision | Conclusion, approver, remediation or risk decision, due date, reassessment trigger, and prior-version link.
Primary sources

References and citations

NIST SP 800-161 Rev. 1 Update 1 C-SCRM
doi.org2 citations
Referenced sections
  • Primary NIST source for cybersecurity supply chain risk management practices.
"identifying, assessing, and mitigating cybersecurity risks"
NIST SP 800-218 SSDF v1.1
doi.org2 citations
Referenced sections
  • Primary SSDF source for high-level practices, task-level artifacts, roles, and notional review frequencies.
"core set of high-level secure software development practices"
NIST SP 800-53 Rev. 5 Controls
doi.org2 citations
Referenced sections
  • Primary NIST source for the integrated security and privacy control catalog.
"catalog of security and privacy controls"

Related guides

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.

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.