Resources · 16
Software supply chain assurance: components to release
Connect components, provenance, builds, vulnerabilities and updates to each release actually deployed.
· 18 min
What this guide helps achieve
- Know the dependencies actually shipped
- Verify artifact origin
- Prioritise flaws in context
- Test replacement and rollback
Quick check
- Does the bill of materials match the deployed version?
- Are transitive dependencies included?
- Who can sign a release?
- Is a vulnerability reachable in your use?
- Can a critical component be removed without improvisation?
Step-by-step method
- 01
Map shipped releases
Identify repositories, direct and transitive dependencies, build tools, images, external services and owners. Connect all of them to a verifiable release.
Deliverable: product, component, version and owner map.
- 02
Produce a usable bill of materials
Generate an SBOM for every release and compare it with the artifacts actually shipped. Resolve inaccurate names, missing versions and internal components.
Deliverable: dated and validated SBOM.
- 03
Protect the build
Limit publishing rights, isolate sensitive stages and retain provenance, digests and signatures. Verify this evidence before deployment.
Deliverable: build record and verification policy.
- 04
Triage alerts
Connect each vulnerability notice to the component, version, exposure and actual use. Assign an owner, deadline, decision and closure evidence.
Deliverable: contextual triage queue.
- 05
Rehearse change
Replace a critical component in a test environment, check business journeys and rehearse rollback. Measure dependencies that block the change.
Deliverable: replacement and fallback exercise report.
- 06
Maintain evidence
Review components and suppliers at major releases and after incidents. Retain records for a period that supports investigation and correction.
Deliverable: review calendar and release history.
Management indicators
| Indicator | What it measures | First action |
|---|---|---|
| SBOM coverage | Shipped releases with a checked component inventory | Resolve discrepancies before publication |
| Verified provenance | Artifacts checked before deployment | Block releases missing expected evidence |
| Triage time | Time from relevant notice to documented decision | Escalate exposed components |
| Reversibility | Critical replacements tested with rollback | Remove blocking dependencies |
Common pitfalls
- Confusing repository inventory with deployed components
- Keeping an SBOM without updating it
- Ranking a flaw only by score
- Signing an artifact without verifying build provenance
Frequently asked questions
Is an SBOM sufficient?
No. It helps identify components, but provenance, integrity, exposure and update capability also need verification.
Should every vulnerability block release?
Decide from actual use, exposure, compensating controls and business criticality, and record the reasoning.
Which reference framework helps?
The NIST Secure Software Development Framework offers secure development and software protection practices across the lifecycle.
Official references
Continue exploring
Related analysis
