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 SSDF SP 800-218 What build-integrity evidence supports NIST SP 800-218 SSDF?

Bind each release to the protected environment, approved build tools and configuration, integrity-verification information, provenance data, and archive that support it.

SSDF Version 1.1 describes several related outcomes. It does not define one build-integrity task or require a particular attestation format.

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

SSDF does not define one "" task. Use PO.3 and PO.5 to secure toolchains and development, build, test, and distribution environments; PW.6 to select and configure build tools; PS.1 to protect code; PS.2 to give acquirers integrity-verification information; and PS.3 to archive releases and provenance. Bind the evidence to the shipped artifact.

Search this module

Find a question or answer quickly

2 of 2 questions
Question 1

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

For the build process, retain the approved compiler, interpreter, and build-tool versions and configuration; evidence that the approved configuration ran; relevant access, change, and integrity records for the build environment and toolchain; and the identifier of the source and dependencies used. PW.6.2 gives a dedicated, highly controlled build environment as a notional example, not a universal implementation requirement.

For the distributed release, retain the release identifier and files, integrity-verification information made available to acquirers, and the protected archive required by organizational policy. PS.2.1 gives cryptographic hashes and code signing as examples. The organization chooses the mechanism and should protect the selected signing or hash-publication process.

Component provenance, including a software bill of materials (SBOM), supports origin and affected-release analysis under PS.3.2. It does not by itself show that an approved build ran or that the final artifact was not altered. Reproducible builds and build attestations may add assurance, but SP 800-218 lists reproducible builds only as a notional toolchain example and does not require a specific attestation scheme.

  • Platform or build owner: protect the build environment, restrict privileged access, monitor changes, and retain the records defined by policy.
  • Development or release owner: identify the source revision, dependencies, tools, configuration, build run, and resulting release.
  • Security or release reviewer: confirm that required checks ran and record approvals, rejections, exceptions, and unresolved risks.
  • Distribution owner: publish the selected integrity-verification information through a protected channel and maintain signing keys or hash-publication controls.
  • Archive owner: protect the release files, integrity data, and provenance for the retention period set by the organization.
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
Question 2

How can a reviewer trace one shipped artifact back to its build?

Select a released artifact and trace it backward. The record should identify the distributed file, its integrity-verification information, the build run and approved configuration, the source and components, the decision that allowed release, and the protected archive.

  • Identify the exact release files and record the published hash, signature, or other organization-selected verification mechanism.
  • Link the release to the source revision, component set, build run, tool versions, and approved configuration.
  • Confirm that access, toolchain integrity, and unexpected build-tool changes were reviewed under the organization's policy.
  • Record required security-check results, the release decision, and any approved exception with its owner and reassessment trigger.
  • Store release files and supporting integrity and provenance data under access and retention controls.
  • Reassess after toolchain, environment, signing, dependency, distribution, or material security-requirement changes.

What does NIST SP 800-218 require for ?

NIST SP 800-218 recommends a set of related outcomes rather than one build-integrity task. Secure and monitor the toolchain and build environment under PO.3 and PO.5, select and enforce approved build-tool configurations under PW.6, protect code under PS.1, give acquirers release-integrity verification information under PS.2, and protect the release archive and component provenance under PS.3. The organization selects the methods according to risk and binds the records to the exact shipped artifact.

Does an SBOM or signature prove under NIST SSDF?

No single SBOM or signature proves the whole build-integrity chain. An SBOM can identify release components and support provenance or vulnerability analysis. A signature or published hash can help an acquirer verify a release file. The reviewer still needs the source revision, dependencies, approved tool and configuration, build-run evidence, security-check decision, and protected archive to assess how that artifact was produced and released.

When should build-integrity evidence be reassessed?

Reassess build-integrity evidence after material changes to the toolchain, build environment, privileged access, source or dependency set, approved build configuration, signing keys, hash-publication process, distribution channel, or security requirements. Also reassess when monitoring identifies an unexpected tool or environment change or when a vulnerability or incident calls an earlier release decision into question. NIST SP 800-218 does not set one universal review interval.

Primary sources

References and citations

NIST SP 800-218 SSDF v1.1
doi.org3 citations
Referenced sections
  • Primary source for SSDF Version 1.1 practices governing toolchains, protected build environments, build configuration, code protection, release-integrity verification, archives, and component provenance.
  • PO.3 and PO.5 cover toolchains and protected development environments; PW.6 covers build-tool selection and configuration; PS.2.1 covers release-integrity verification information; PS.3.1 and PS.3.2 cover release archives and component provenance.
  • PO.4 covers security-check criteria and protected supporting information. PW.6.1 and PW.6.2 address build tools and approved configurations. PS.2.1 and PS.3 address integrity-verification information, release archives, and provenance.

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