DedSec Project

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:

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

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.