SSDF PS.3.2 asks you to collect, safeguard, maintain and share provenance data for all components of each release, for example as a software bill of materials. A workable routine: generate the SBOM in your build, attach it to the release, store a protected copy and refresh it whenever components change.
What PS.3.2 says
The task text is: collect, safeguard, maintain, and share provenance data for all components of each software release (for example in a software bill of materials). The NIST examples say to make the data available to acquirers under your policies, preferably in standards-based formats, to give your operations and response teams access, to protect its integrity and let recipients verify it, and to update it every time a component changes.
A repeatable routine
- Generate in the build. Create the SBOM from the same build that makes the release, not from a developer laptop afterward.
- Name it by release. Use the version or build ID in the filename so it maps to one artifact.
- Protect it. Store it with the release files in locked, write-protected storage. NIST suggests holding integrity and provenance data separately from the release files or signing it.
- Share it. Decide who gets it: customers on request, internal response teams by default.
- Refresh it. Regenerate when any component is updated.
What the SBOM should show
| Item | Reason |
|---|---|
| Component name and version | Basic identification |
| Supplier or source | Origin of each part |
| Relationships | Which parts include which |
| Hashes where available | Integrity checking |
| Generation time and tool | Context for readers |
Pick a standards-based format your customers can read. Whichever you choose, say so in your release notes.
Evidence to keep
- The SBOM for each release, stored with the artifact
- A record showing it was generated automatically in the build
- Access rules showing who can read and change it
- A note describing how often it is refreshed
Common problems
SBOMs generated from source manifests may miss what ends up in a container image or binary. If your product ships as an image, scan the image too and compare the results. SBOMs also go stale: a release from last year with a year-old SBOM still matters when a new vulnerability arrives, so retain them as long as the release is supported.
Checking the result
After the first automated run, check the SBOM against what you know. Does it list your main frameworks and their versions? Does it include components inside container images? Compare the count of components with a manual sample. If the output looks thin, adjust the generator settings or add a second source such as an image scan. Record the check once so you can say how you validated the SBOM, not just that you produced one.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how each component carries a version and a source, the same fields a release SBOM records.
Quick check
Does SSDF require a specific SBOM format?
No. NIST says preferably a standards-based format and does not mandate one.
How long should we keep release SBOMs?
Set it in your retention policy. NIST's PO.1.2 examples say retention should depend on the SDLC model, software end of life and other factors.
Safeguard provides SBOM and dependency scanning for this inventory work. You can try the free scan at gold.safeguard.sh/scan.
Sources
- NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
- NIST CSRC publication page for SP 800-218
Last reviewed: 19 October 2026.
