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 (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.
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.
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.
Sources (1)
NIST SP 800-218 supports this SBOM and provenance workflow through SSDF tasks for protecting software, archiving release files, and retaining provenance data.
core set of high-level secure software development practices
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.
Sources (1)
Primary NIST source for the Secure Software Development Framework.
core set of high-level secure software development practices
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.
Sources (1)
Primary NIST source for the Secure Software Development Framework.
core set of high-level secure software development practices
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.
Sources (1)
Primary NIST source for the Secure Software Development Framework.
core set of high-level secure software development practices
Define the release boundary, assign record owners, document collection limits, and connect each SBOM or provenance record to the matching release and response process.
Create cited tasks, evidence requests, and review checkpoints for this NIST SSDF scope.
Review the release boundary, component identities, collection limits, sharing rules, and response links.
"core set of high-level secure software development practices"
Build a task-level SSDF evidence index for internal assurance, customers, acquirers, and contract reviews without implying NIST certification.
Practical answers on SSDF Version 1.1 code analysis, components, builds, release gates, provenance, threat modeling, coding evidence, and vulnerability response.
Implement final SSDF v1.1 by defining the software boundary, selecting applicable tasks by risk, assigning shared responsibilities, and retaining task-level evidence.
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.
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.
SSDF v1.1 does not require self-attestation. Check the requesting agency or contract: OMB rescinded the former government-wide mandate in January 2026.
Validate an SSDF-based attestation request, bound the covered software and producer, test each representation against evidence, and retain the signed submission.
Map NIST SSDF tasks to SP 800-53 Rev. 5 SA controls without treating references, shared evidence, or partial overlap as full implementation.
Compare NIST SSDF v1.1 with SLSA v1.2 Source and Build tracks, including scope, levels, evidence, provenance, verification, and limits.
Decide which code review, analysis, and executable testing apply, then retain scope, results, triage, remediation, and exception records.
Evaluate third-party and in-house components, track source, version, provenance, approval, affected releases, maintenance, and known-vulnerability decisions.
Define risk-based release criteria, gather protected evidence, record approvals and exceptions, and bind the decision to the shipped artifact.
Use risk modeling to assess software risk, connect findings to security requirements and design decisions, and revisit the record when its assumptions change.
Run a documented path from vulnerability intake and credibility review through risk-based remediation, acquirer communication, and root-cause feedback.
Connect each release to its protected build environment, approved tool configuration, integrity-verification data, provenance, and archived release record.
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.
SSDF provenance records component origin and change history for each release so acquirers, operations, and response teams can identify affected software.