To show provenance, keep a record of where each piece of code came from, who changed it and how the release was built, and make that record available to buyers. NIST SSDF task PS.3.2 names an SBOM as one way to carry it. The CISA form asked for provenance "to the greatest extent feasible."
Definition
The SSDF draft defines provenance as "the chronology of the origin, development, ownership, location, and changes to a system or system component and associated data." It may also include the personnel and processes involved.
What the SSDF asks you to keep
Task PS.3.2 says to collect, safeguard, maintain and share provenance data for all components of each software release, for example in an SBOM. Its notional examples are:
- Make the data available to software acquirers, preferably in standards-based formats.
- Make it available to your own operations and response teams.
- Protect the integrity of the data and give recipients a way to verify it.
- Update it every time any component is updated.
Provenance by kind of code
| Kind of code | Evidence that helps |
|---|---|
| Your own source | Commit history, protected branches, reviewer records, signed commits where you use them |
| Your build output | Build logs, build system identity, the commit it was built from |
| Open source dependencies | Package name, version, source registry, checksums in lockfiles |
| Commercial components | Vendor name, version, contract or license record, vendor SBOM if supplied |
| Code copied in from elsewhere | A record of its origin and license; track it as a dependency |
For open source, the 2026 CISA SBOM guidance says that when there is no clear indication of a component producer, the author should explicitly say the component is of unknown provenance. Saying "unknown" is better than leaving the field blank.
A step by step setup
- Turn on branch protection and require review for the main branch.
- Commit lockfiles and keep them current.
- Generate an SBOM in the release pipeline and store it with the build.
- Record the commit hash and build identifier in release notes.
- Decide how recipients will verify integrity, for example a signature on the SBOM or artifact.
For how signatures, provenance and SBOMs differ, read signature vs provenance vs SBOM attestation.
Try it yourself
Click through it at your own pace, or open it full screen.
Check what the inventory records for each component: name, version and where it came from.
Quick check
Is an SBOM the same as provenance?
No. An SBOM is one way to carry provenance data about components. Build and source history are also part of provenance.
What if I cannot identify a component's origin?
Say so explicitly. CISA's guidance prefers an explicit unknown over silence.
Safeguard provides SBOM and dependency scanning and policies and gates for release checks. Run the free scan at gold.safeguard.sh/scan.
Sources
- NIST SP 800-218 Rev. 1 initial public draft (PDF)
- CISA attestation form (PDF)
- CISA 2026 Minimum Elements for an SBOM (PDF)
Last reviewed: 19 October 2026.
