generated from coulomb/repo-seed
Add security architecture pattern infospace
This commit is contained in:
@@ -0,0 +1,43 @@
|
||||
# Pattern: SBOM-per-Release
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: artifact-store, product repos
|
||||
Genesis family: Supply chain
|
||||
|
||||
## Problem
|
||||
|
||||
Teams cannot assess exposure, license risk, or incident impact if
|
||||
release components are not recorded.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for containers, packages, product releases, platform
|
||||
images, and deployable artifacts.
|
||||
|
||||
## Forces
|
||||
|
||||
- SBOM generation should be automated.
|
||||
- SBOMs need to stay attached to release artifacts.
|
||||
- Consumers need stable formats and storage.
|
||||
- Vulnerability triage needs component evidence.
|
||||
|
||||
## Solution
|
||||
|
||||
Generate a software bill of materials for each release artifact and
|
||||
store it with artifact metadata, provenance, signature, and deployment
|
||||
records.
|
||||
|
||||
## Verification
|
||||
|
||||
- Each production release has an SBOM.
|
||||
- SBOMs are stored with immutable artifact identity.
|
||||
- Vulnerability scans can reference SBOM components.
|
||||
- Release promotion checks require SBOM presence.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Supply-Chain Provenance.
|
||||
- SLSA Build Provenance.
|
||||
- Signed Container Images.
|
||||
- Protected Main Branch.
|
||||
Reference in New Issue
Block a user