Does SLSA Build L3 provenance mean an artifact has no known vulnerable dependencies?
answer
- process integrity, not contents
- describes the build, not the parts list
- L3 hardens the builder only
- SBOM answers what is inside
- faithful build of flawed code
basics
~10 sNo. The SLSA build track attests to how an artifact was produced and by which builder, not to what is inside it or whether those components are flawed. Vulnerable dependencies are a separate question.
solid answer
~50 sNo, and this is the most common misreading of SLSA. The build track describes the integrity of the build **process**: at Build L3 you can trust that the artifact came out of a hardened, isolated builder running the build definition the provenance names, and that nobody forged that claim. It says nothing about whether the source that was built was safe, or whether the libraries pulled into it carry known flaws. A perfectly L3 artifact can be full of vulnerable components, because the build faithfully produced exactly what the definition asked for. Keep the three statements straight: an SBOM says what is inside, provenance says how it came to be, and a signature says who vouches for it. "Am I exposed to a known vulnerable component?" is answered by an inventory plus advisory data, not by a build level.
go deeper
Be ready to state plainly that a build level describes how an artifact was produced, not what is inside it, and to name the separate document that lists components.
Explain the division of labour between the three statements - inventory, provenance, signature - and why a faithful build of flawed source still earns the top build level.
Expect to be asked what you put in front of a customer who confuses the two, and which controls you run alongside the build level to answer the components question.
Own the framing that build integrity and component risk are separate programmes with separate budgets and cadences, and be able to say where you would spend next.
## What the build track actually claims SLSA's build track is a ladder about one thing: **how much a consumer can trust the story of how an artifact was produced**. At Build L1 provenance exists and describes the build. At Build L2 the provenance is generated and signed by a hosted build platform, so its authenticity can be checked and post-build tampering becomes detectable. At Build L3 the platform is hardened: build runs are isolated from one another and the material used to sign provenance is out of reach of user-defined build steps, so a malicious build definition cannot forge the claim about itself. Every one of those statements is about **process**. None of them is about **contents**. A build system that faithfully compiles a library with a five-year-old known-flawed transitive dependency, on an isolated hardened runner, with unforgeable provenance, has earned the top of the build track. The provenance is honest; what it is honest about is the process, not the safety of the result. ## The three statements, and why people mix them up The domain has three machine-readable claims and they answer three different questions: | Statement | Question it answers | | --- | --- | | SBOM | What is inside this artifact? | | Provenance | How and by whom did it come to be? | | Signature | Who vouches for these exact bytes? | The canonical wrong answer in interviews is to swap these. Someone says "we publish provenance, so we know our components" (no, that is an inventory question), or "the image is signed, so it is safe" (no, a signature binds an identity to bytes; the identity may be vouching for something terrible), or "we are L3, so we are secure" (no, that is one axis of one track). ## Why the boundary is deliberate, not an oversight SLSA v1.0 split the framework into tracks and specified only the build track. Source review, hermeticity and dependency handling were consciously left outside it. That was a scoping decision: a level should mean something precise and verifiable, and "this artifact contains nothing exploitable" is not verifiable in the way "this artifact came from that build definition on that platform" is. Vulnerability is a moving target - a component that carries no known advisory today may carry a critical one tomorrow, with the artifact's bytes unchanged. A level pinned to the build could never track that; it would be stale the moment it was issued. This is also why the two controls have different lifecycles. Provenance is produced once, at build time, and stays true forever - it describes an event that happened. Component risk is re-evaluated continuously against feeds that change daily, against an artifact that does not. ## What provenance does buy you on the component axis Indirectly, quite a lot - but never the answer itself. Trustworthy provenance makes your inventory **believable and addressable**: - It binds a running artifact to an exact build, source revision and build definition, so when an advisory lands you can work backwards from "which releases contain this" to real builds instead of guessing from tags. - It lets you tell the difference between an SBOM that a build platform emitted from the actual resolved graph and one that someone generated by hand later. - It gives an auditor a chain from a deployed artifact to a build record, which is what "we know what we shipped" means in practice. What it does not do is enumerate components, judge whether a flaw is reachable, or tell you what to fix first. Those belong to inventory and advisory analysis, which run on their own cadence and produce their own evidence. ## How to say this in an interview Lead with the one-line separation - build level describes the process, inventory describes the contents - then give the concrete case: a hardened, isolated build of a codebase that pulls a flawed library produces an artifact that is simultaneously top-of-build-track and vulnerable. Both things are true, and they are not in tension, because they are answers to different questions. The same separation gives you the right question to ask a vendor. "We are SLSA L3" is a claim about builds, and it applies per artifact and per build run rather than to a company. So ask which artifacts, ask for a provenance statement you can verify yourself, and then ask separately what they publish about components and how they handle advisories. A vendor who cannot separate those two answers has not understood their own claim.
- If SLSA does not cover dependency vulnerabilities, does it help you deal with them at all?Indirectly. Trustworthy provenance binds a deployed artifact to a specific build and source revision, so when an advisory lands you can map an affected component back to real builds and releases rather than guessing. It makes your inventory believable and addressable; it does not produce that inventory, and it does not judge the finding.
- A vendor tells you "we are SLSA L3". What do you ask next?Which artifacts and which builds, because the level applies per artifact and per build run, not to a company. Then ask for a provenance statement you can verify yourself against their builder identity. Finally ask separately what they publish about components and how they handle advisories, because the build level answers none of that.
- Can the same artifact be top-of-build-track and still be the thing that gets you breached?Yes, and it is the case worth being able to state. The level says the builder faithfully produced what the build definition asked for on a hardened platform. If what it asked for was a flawed or malicious codebase, the provenance simply records that faithfully. Verifiable does not mean safe.
A tamper-evident seal and a delivery log prove the box reached you exactly as packed, and by whom. Neither tells you the contents are safe to eat.
saying these in an interview costs you the question
- Claims a SLSA level implies the artifact is vulnerability-free
- Treats a provenance statement as a bill of materials
- Says reaching L3 removes the need for component analysis
- Describes a signature as proof the contents are safe
- Talks about SLSA levels as a property of a company