Description
Each release produces a software bill of materials (SBOM) in a standard format, listing every component and version, generated from the actual build. It is stored with the release artifact for at least as long as the release is supported.
Rationale
When a vulnerability or a malicious package is announced, the SBOM answers "are we affected, and where?" for every version in the field, including old ones no longer in the repository.
Impact
Build pipelines need an extra step and storage.
Audit
- Pick a recent release and retrieve its SBOM.
- Check it uses a standard format, includes transitive dependencies and matches the shipped artifact.
Automated: every check must pass. Scanners report each check by its id.
postmortem
an SBOM step in the pipelines; storage with releases is by hand
command: postmortem harden --json
control: CB-DEP-INV-001
coverage: partial
Remediation
- Add SBOM generation to the release build.
- Store it with the release artifact.
References
- The Minimum Elements For a Software Bill of Materials (SBOM) NTIA, standard, accessed 2026-10-16
- NIST SP 800-218 - Secure Software Development Framework (SSDF) 1.1 NIST, standard, accessed 2026-10-16
Mappings
| Framework | ID | Relation | Note |
|---|---|---|---|
| NIST SP 800-53 Rev. 55.1.1 | CM-8 | related | |
| NIST SP 800-53 Rev. 55.1.1 | SR-4 | related |
How this control relates to the other framework's: equivalent, stricter, looser, partial or related.
Related controls
- related
CB-DEP-INV-002Know where any package version is used within a set time
People and lifecycle
| Authors | Alice |
| Introduced in | v1.0.0 |
| Created, updated | 2026-10-16, 2026-10-16 |