DevOps Professional · Module 4: DevSecOps and supply chain
SBOM and Provenance: Knowing What You Ship
You cannot defend what you cannot list. SBOMs inventory every component in an artifact, provenance attests how it was built, and prioritization turns a thousand findings into the few that actually threaten you.
10 min reading
Objectives
- Explain what an SBOM lists and what provenance attests
- Generate an SBOM for a small artifact and read it
- Prioritize fixture findings by reachability and severity, not by count
- Verify provenance before trusting an artifact's origin story
Why this matters
A critical vulnerability lands in a ubiquitous library and the question is immediate: where do we ship it. Teams without SBOMs answer by searching repos by hand for a week; teams with them query the inventory in minutes. The difference is not tooling budget, it is the habit of generating the list at build time and storing it with the artifact. The L58 lab builds an SBOM for a small artifact and prioritizes its fixture findings; this lesson explains what the list means and what it cannot do.
Concepts
An SBOM names components: libraries, versions, licenses, relationships. Generate it at build from the actual resolved dependencies (lock files, build attestations), never by scanning afterward and hoping the scan sees what the build used. Store it with the artifact, versioned together; an SBOM that drifts from its artifact is a second fiction to maintain.
Provenance answers the harder question: who built this, from what source, with which steps. Signed attestations bind the artifact to its build (source commit, build configuration, materials), and verification checks the binding before deploy. Unsigned artifacts carry claims, not evidence; policy decides which sources require provenance, and the requirement lands in admission (lesson 3), not in documentation.
Prioritization beats counting. Findings rank by severity adjusted for reachability: a critical in an unreachable test dependency waits, a high in the request path ships now. Fixture findings in labs are labeled fixtures and prioritized as practice; the skill transfers, the verdicts do not. Track mean time to fix per severity band, not raw counts, or the program optimizes for closing tickets instead of reducing exposure.
Worked example
A small fixture artifact gets an SBOM at build time; the learner reads it (components, versions, licenses) and triages ten fixture findings down to two that are reachable and severe. Provenance is generated and verified for the artifact, then a tampered copy fails verification with the mismatch quoted. List, prioritize, verify: the three motions in one sitting.
Common wrong move
Generating SBOMs and filing them unread. An inventory nobody queries during incidents is compliance theater; the value arrives when the vulnerability lands and the answer takes minutes. Query in drills, or the list rots.
Quick check
An optional 4-question self-check. Answers never leave your device, are not stored, and never count toward any assessment.
Lesson feedback
No published feedback yet.
Log in and complete the lesson to leave feedback.
Exercise
Generate an SBOM for a small fixture artifact, triage its fixture findings to the reachable and severe, verify provenance, and quote a tampered copy failing verification.
Pass criteria
The record shows the readable SBOM, the triaged findings with reasons, the verified provenance, and the quoted verification failure.