Lab 01 — SLSA Provenance Verifier with Materials Reconciliation

Difficulty: 4/5 | Runs locally: yes, standard library only

Pairs with the Phase 14 WARMUP Chapters 3–4, 8 (provenance/in-toto, SLSA levels, dependency security) and the HITCHHIKERS-GUIDE. Goes deeper than the Phase 03 provenance lab — this one reconciles materials and computes the SLSA level.

Why This Lab Exists (Purpose & Goal)

SolarWinds proved that the build, not the app, is the prize: a compromised builder shipped a backdoor with perfect provenance to 18,000 organizations. The defense is verifiable provenance — but the part most teams get wrong is verifying the materials (the exact dependencies the build consumed) against the reviewed lockfile, which is where a dependency-injection attack hides. The goal of this lab is to build the policy engine that answers, before you deploy: did this artifact come from the expected source, via a trusted builder at a sufficient SLSA level, using exactly the dependencies I locked?

The Concept, In the Weeds

Provenance (an in-toto/SLSA attestation) binds an artifact (the subject, by digest) to how it was built — builder, source repo+commit, and materials (resolved dependencies by digest). Two checks beyond field-matching carry the security weight:

Materials reconciliation. Every material the build used must be in the lockfile, by matching digest, with nothing extra (an unlocked-material = an injected dependency) and nothing missing (the build used something other than what was reviewed). This is the dependency-injection defense.
SLSA level computation. The achieved level is derived from build properties — L1 (provenance exists), L2 (signed + service-generated), L3 (isolated builder + non-falsifiable provenance), L4 (hermetic + reproducible) — and the policy enforces a minimum. L3 is the practical bar because it defeats a compromised build step.

Why This Matters for Protecting the Company

A single accepted compromised artifact is a backdoor in every downstream system, signed with your name. Provenance verification — with materials reconciliation and a SLSA-level floor — is how a company ensures that only artifacts built from reviewed source, by a trusted isolated builder, with the exact reviewed dependencies, reach production. It is the control that would have caught SolarWinds (a non-falsifiable L3 build would not have let a compromised step forge clean provenance) and dependency-confusion (the injected material fails reconciliation). It is also how you offer customers a verifiable build-integrity guarantee.

Secure Implementation Patterns

The anti-pattern. Match the builder and call it verified:

if prov.builder_id == EXPECTED_BUILDER: deploy()   # ignores materials -> injected deps slip through

The secure pattern — reconcile materials + enforce a SLSA level (mirrors solution.py):

def achieved_slsa_level(prov):
    level = 1 if prov.builder_id and prov.build_type else 0
    if level >= 1 and prov.signed and prov.service_generated:      level = 2
    if level >= 2 and prov.isolated and prov.non_falsifiable:      level = 3  # defeats a compromised step
    if level >= 3 and prov.hermetic and prov.reproducible:         level = 4
    return level

def verify_provenance(prov, subject_digest, policy):
    reasons = []
    if prov.subject_digest != subject_digest:        reasons.append("subject-digest-mismatch")
    if prov.builder_id not in policy.allowed_builders: reasons.append("untrusted-builder")
    if prov.source_repo != policy.source_repo:        reasons.append("wrong-source-repo")
    locked = {m.uri: m.digest for m in policy.lockfile}
    seen = set()
    for m in prov.materials:                           # MATERIALS RECONCILIATION
        seen.add(m.uri)
        if m.uri not in locked:        reasons.append(f"unlocked-material:{m.uri}")        # injected
        elif locked[m.uri] != m.digest: reasons.append(f"material-digest-mismatch:{m.uri}") # swapped
    for uri in locked:
        if uri not in seen:            reasons.append(f"missing-material:{uri}")            # not used
    level = achieved_slsa_level(prov)
    if level < policy.required_slsa_level:
        reasons.append(f"slsa-level-{level}-below-required-{policy.required_slsa_level}")
    return (not reasons), tuple(sorted(set(reasons))), level

The real-world equivalent: cosign verify-attestation --type slsaprovenance for the signature + identity, then this policy logic on the predicate, enforced at binary authorization (Phase 14 HITCHHIKERS).

Production practices to carry forward:

Reconcile materials, don't just field-match — pin by digest, fail on extra/missing/mismatched.
Enforce SLSA ≥ 3 for production-critical artifacts (isolated, non-falsifiable provenance).
Verify the subject digest equals the deploying digest — provenance for some build isn't proof for this artifact.
Enforce at admission/deploy, fail closed — provenance you don't verify is decoration.

Validation — What You Should Be Able to Do Now

Explain provenance/in-toto and why materials reconciliation is the key check.
Compute an achieved SLSA level from build properties and enforce a minimum.
Catch an injected dependency, a swapped digest, a missing material, an untrusted builder, and a below-level build.

The Broader Perspective

This lab generalizes a theme from the whole curriculum: integrity is reconciliation against a reviewed source of truth. The materials check is the binary-hardening "verify effective state vs intent" (Phase 01), the IAM "what's granted vs needed" (Phase 07), and the attestation "PCRs vs golden" (Phase 13), applied to the dependency graph. Supply-chain security is, at heart, provenance verified against policy at every link — and once you can do it for a build, you can reason about the integrity of any assembled system.

Interview Q&A

"What does SLSA L3 buy over L2?" — L2 is signed, service-generated provenance; L3 adds a hardened, isolated builder whose provenance no build step can falsify, defeating a compromised build step (the SolarWinds class).
"How do you catch dependency injection in a build?" — Materials reconciliation: every dependency the build consumed must match the reviewed lockfile by digest, with nothing extra or missing.

Extension (Stretch)

Verify real SLSA provenance from the SLSA GitHub generator with cosign verify-attestation, parse the in-toto predicate, and wire the policy into a Kyverno/policy-controller admission rule.

References

SLSA specification; in-toto attestation framework; Phase 14 WARMUP Chapters 3–4, 8.
SolarWinds/SUNBURST and dependency-confusion post-mortems.

Security Engineer