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 SBOM and Provenance Workflow

For each software release, identify its components, record their origin, bind the records to the archived release, protect their integrity, and make them available under the producer's sharing policy.

SSDF treats a software bill of materials (SBOM) as an example of provenance data. It does not prescribe one SBOM format, require public disclosure, or treat an SBOM as proof that the release is secure.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Sections
5

Structured answer sets in this page tree.

Primary sources
1

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 24, 2026
Overview

Run this workflow for every software release. SSDF task PS.3.2 calls for collecting, safeguarding, maintaining, and sharing provenance data for all release components, with a (SBOM) as an example. Keep component inventory, component origin, release-integrity information, and component-approval evidence linked but distinct.

Section 1

Know what each record answers

An SBOM records the components in a defined release. Provenance records the chronology of a component or artifact's origin, development, ownership, location, and changes; it may also cover the people and processes that modified it. PS.2 release-integrity information gives an acquirer a way to check that delivered software is legitimate and has not been altered.

PW.4 component-review evidence answers a different question: whether a commercial, open-source, or other third-party component was checked against the producer's requirements and monitored through its life cycle. Use stable product, release, artifact, and component identifiers to connect these records.

  • SBOM | Which components and versions are in this release, and what dependency relationships are known?
  • Provenance | Where did each component or artifact come from, and what known changes or transformations produced it?
  • Release integrity | How can a recipient check that the delivered release is the intended, unmodified release?
  • Component review | Which requirements, vulnerability checks, exceptions, and risk decisions allowed the component into the release?
Sources for this answer
NIST SP 800-218 SSDF v1.1
NIST SP 800-218 supports this SBOM and provenance workflow through SSDF tasks for protecting software, archiving release files, and retaining provenance data.
Section 2

1. Set the release boundary and collection method

Start with the exact product, version, release artifact, platform, and packaging form. State whether the record covers first-party modules, direct and transitive dependencies, open-source and commercial components, embedded firmware, containers, services, generated code, and build-time dependencies. Do not imply full coverage when the collection method cannot see a category.

Document how components were found, such as package manifests, lockfiles, source or binary composition analysis, supplier records, and build-system output. Record known omissions, unresolved identities, the collection date, and the tool version or other method used.

  • Trigger | A release candidate is created or its component composition changes.
  • Owner | Release engineering collects the record; product and component owners resolve scope and identity gaps.
  • Action | Assign stable identifiers and collect component name, version, supplier or source, dependency relationship, and available integrity data.
  • Evidence | Release manifest, collection logs, supplier input, validation result, and documented limitations.
  • Branch | If a component cannot be identified or its provenance cannot be confirmed, record the gap and route it to the component-risk decision before release.
Sources for this answer
NIST SP 800-218 SSDF v1.1
Primary NIST source for the Secure Software Development Framework.
Section 3

2. Validate, bind, archive, and protect the records

Compare the collected record with release inputs and outputs. Resolve duplicate or ambiguous identities, stale versions, missing transitive dependencies, and supplier records that refer to another release. Validation does not prove completeness, so preserve the method, result, and known limits.

Bind the approved SBOM and provenance record to the archived release through stable identifiers and available integrity mechanisms. Protect release files and supporting data under retention and access policy. Keep the record for the shipped release after the current product inventory changes.

  • Trigger | Collection is complete and the release artifact is fixed.
  • Owner | The release owner approves the binding; security or component owners decide unresolved provenance and component risks.
  • Action | Validate the records, record exceptions, link them to the release, and store them with controlled access and retention.
  • Evidence | Validation report, approved exceptions, archived release identifier, integrity-verification information, record digest or signature where used, and access history.
  • Branch | If the record describes a different artifact or a material gap conflicts with release criteria, correct the record, change the component, accept the documented risk under policy, or stop the release.
Sources for this answer
NIST SP 800-218 SSDF v1.1
Primary NIST source for the Secure Software Development Framework.
Section 4

3. Share for acquisition and vulnerability response

Define which acquirers, customers, operations teams, and response teams receive the SBOM or other provenance data, in which format, and through which protected channel. PS.3.2 says to make provenance available to acquirers according to organizational policy and to operations and response teams for vulnerability mitigation; it does not require every record to be public.

Connect component identities to vulnerability-monitoring and response records so responders can identify affected releases. When a component changes, create or update the release-specific provenance record instead of overwriting historical evidence.

  • Trigger | Release approval, an authorized request, a component update, or a vulnerability investigation.
  • Owner | Product assurance sets policy; release and response teams deliver or use the correct version.
  • Action | Share the permitted record, preserve the recipient and version, and update affected-release mappings after component changes.
  • Evidence | Sharing decision, recipient, channel, format, release identifier, delivery record, and vulnerability-response link.
  • Branch | If data contains sensitive supplier or build details, provide the permitted fields or controlled access without claiming that a reduced record is complete.
Sources for this answer
NIST SP 800-218 SSDF v1.1
Primary NIST source for the Secure Software Development Framework.
Section 5

What this workflow can and cannot establish

A completed workflow produces a release-specific SBOM or other provenance record, a record of known limits, an archive link, a sharing decision, and connections to component review and vulnerability response. It does not prove that the software is free of vulnerabilities or that every SSDF task operates.

An SBOM alone does not show that a component met security requirements, the build environment was protected, the delivered artifact is authentic, or a known vulnerability was remediated. Those conclusions require the corresponding SSDF evidence.

  • Do not reuse a current-state inventory for a historical release with different components.
  • Do not treat a file hash as component provenance or an SBOM as component approval.
  • Do not hide collection limits; name omitted categories and unresolved component identities.
  • Do not expose sensitive build, supplier, or vulnerability data without an explicit access and sharing decision.
Sources for this answer
NIST SP 800-218 SSDF v1.1
Primary NIST source for the Secure Software Development Framework.
Recommended next step

Put this NIST SSDF guidance into practice

Define the release boundary, assign record owners, document collection limits, and connect each SBOM or provenance record to the matching release and response process.

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 or publishing the work.

Explore next step
Primary sources

References and citations

NIST SP 800-218 SSDF v1.1
doi.org
Referenced sections
  • Primary NIST source for the Secure Software Development Framework.
"core set of high-level secure software development practices"
Related guides

Explore more topics

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.
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 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.
NIST SSDF vs SP 800-53 SA controls: practice-to-control mapping table
Compare NIST SSDF and NIST SP 800-53 SA controls with side-by-side scope, owner, trigger, evidence, cadence, assurance, and decision-rule rows.
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.