Add security architecture pattern infospace
This commit is contained in:
parent
3ca891de4a
commit
5bb4b40b86
81 changed files with 6836 additions and 0 deletions
|
|
@ -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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue