What practical checklist should teams use for provenance under NIST SP 800-218 SSDF?
Test the record against one release and one component incident. A reviewer should be able to identify the exact component, source, version, affected releases, record owner, integrity mechanism, recipients, and the update or response decision.
- Identify the release, every governed component, its version or other identifier, source or supplier, and relationship to the released software.
- Record relevant origin, development, ownership, location, and change history according to organizational policy.
- Protect the provenance record and provide a way for recipients to verify its integrity.
- Define which acquirers, operations staff, and response teams receive or can access the record.
- Update the record whenever a release component changes and retain the prior release record under policy.
- Document missing provenance, the affected release, chosen risk response, decision authority, owner, and reassessment trigger.
Is provenance the same as an SBOM under NIST SSDF?
No. An SBOM is one example of a format that can carry component information. Provenance is broader: it records relevant chronology about a system or component's origin, development, ownership, location, and changes and may include the people and processes involved. The organization chooses the format, access, sharing, and retention rules needed for its releases.
When should release provenance be updated under NIST SSDF?
PS.3.2 recommends updating provenance data every time a software component in the release changes. Keep the record tied to the exact release, protect it from unauthorized alteration, provide a way for recipients to verify its integrity, and retain prior release records according to organizational policy. The organization should also document missing provenance and the resulting risk decision.
What does component provenance fail to prove?
Component provenance alone does not prove that an approved build ran, that the final artifact was not altered, that security checks passed, that the release was approved, or that the producer implemented every SSDF practice. Link separate build-run, integrity-verification, security-check, release-decision, and archive evidence when those claims are in scope.
PS.3.1 addresses protecting archived release files and supporting integrity and provenance data. PS.3.2 addresses component provenance content, integrity, sharing, and updates. RV.1.1 supports its use in vulnerability monitoring.