SBOM, VEX, Provenance and Vulnerability Intelligence Pipelines — DedSec Project
SBOM, VEX, Provenance and Vulnerability Intelligence Pipelines Turn dependency data into decisions. Learn SBOM structure, component identity, VEX statements, exploitability context, build…
Turn dependency data into decisions. Learn SBOM structure, component identity, VEX statements, exploitability context, build provenance, vulnerability feeds and evidence-based prioritization.
Learning objectives
By the end of this module you should be able to:
- Explain SBOM purpose and limitations and identify its most important trust boundary, state transition, and evidence source.
- Explain package identity and version matching and identify its most important trust boundary, state transition, and evidence source.
- Explain transitive dependencies and identify its most important trust boundary, state transition, and evidence source.
- Explain VEX status and justification and identify its most important trust boundary, state transition, and evidence source.
- Explain provenance linkage and identify its most important trust boundary, state transition, and evidence source.
- Explain vulnerability feeds and enrichment and identify its most important trust boundary, state transition, and evidence source.
Deep concepts
1. SBOM purpose and limits
A Software Bill of Materials inventories components and relationships to improve visibility, response, and dependency management. It is evidence about composition, not proof of security, reachability, authenticity, or whether the listed software actually executes in a vulnerable way.
2. package identity and version
Useful component records need an unambiguous ecosystem/name/version or package URL plus enough provenance to distinguish forks, vendored copies, and rebuilt artifacts. Ambiguous package identity creates false matches and blind spots during vulnerability response.
3. transitive dependencies
Direct dependencies pull in transitive components that may carry equal or greater risk. Generate inventories from the resolved build/runtime graph where possible and distinguish build-only, test, optional, bundled, and runtime relationships.
4. VEX status and justification
Vulnerability Exploitability eXchange communicates whether a known vulnerability affects a specific product and why. Status needs evidence, scope, author, timestamp, and justification; it should not become a permanent “not affected” label that survives architecture changes without review.
5. provenance linkage
SBOMs are stronger when linked to signed/verified build provenance identifying source, builder, inputs, parameters, and resulting artifact. This lets responders ask not only “what packages?” but “which build produced this deployed binary and under what trusted workflow?”
6. vulnerability feeds
Scanner/feed matches change as advisories, package mappings, and severity evolve. Preserve feed timestamp/source, normalize identifiers, and verify high-impact matches against authoritative package/advisory data instead of treating one vendor score as final truth.
7. reachability and exposure
A vulnerable library may be present but unreachable; conversely, “not reachable” analysis can miss configuration, reflection, native calls, or future paths. Use reachability as prioritization evidence, not an automatic reason to suppress remediation forever.
8. gates and exception lifecycle
Build/deploy policy should define which findings block, warn, or require an approved exception. Exceptions need owner, justification, compensating control, expiry, and re-evaluation when package, environment, exploitability, or business exposure changes.
Authorized lab sequence
Lab 1 — Create a small SBOM-like inventory for a local Python project using only package metadata you own.
Lab 2 — For three fictional CVEs, write VEX-style affected/not-affected/under-investigation rationales with evidence requirements.
Lab 3 — Design a pipeline that links source commit → build provenance → artifact → SBOM → deployment inventory.
Knowledge checks
Answer these without looking at the notes:
Next modules
Recommended related modules: 005, 022, 050, 084, 097, 098, 109. From the main menu, choose Search lessons to find related sections across the full guide.