Lab 03 — Artifact Provenance Verifier

Difficulty: 3/5 | Runs locally: yes

Pairs with the Phase 03 WARMUP Chapter 8 (SBOM, SLSA, provenance, signing) and the HITCHHIKERS-GUIDE ("Verifying provenance at admission").

Why This Lab Exists (Purpose & Goal)

Modern software is mostly other people's code assembled by automated pipelines, and attackers learned to compromise the supply chain rather than the application — SolarWinds, the event-stream and xz backdoors, dependency-confusion attacks. Signing artifacts is now common, but signing without verification at the consumption point is theater. The goal of this lab is to build the verifier that actually checks an artifact's provenance before it is trusted, and to prove it detects each class of tampering.

The Concept, In the Weeds

Provenance is verifiable metadata about how an artifact was built — which source commit, which builder, which inputs. The verifier checks that the claimed facts match release policy:

artifact digest        — is this the exact bytes that were built and signed?
source revision        — did it come from the expected commit?
builder identity       — was it built by our trusted pipeline, not a developer laptop?
dependency lock digest — were the inputs the reviewed, pinned ones?
SBOM digest            — does the bill of materials match?
signature subject      — is the signer the identity policy expects?

The lab makes you demonstrate tamper detection by changing each field: a swapped artifact (digest mismatch), a forged source reference, a wrong builder identity, an altered SBOM. The load-bearing idea: the control is verification, with signing as its prerequisite. A signature that nothing checks changes nothing; the pipeline that builds and signs is itself the most valuable target (compromise it and you ship a backdoor with perfect provenance), so verification at deploy is the backstop.

Why This Matters for Protecting the Company

A supply-chain compromise distributes malicious code to every customer through the trusted update channel — the highest-leverage attack there is. Provenance verification is how a company answers "did this binary actually come from our source via our trusted pipeline?" before running it — at deploy time, at Kubernetes admission (Phase 07), and at dependency intake. When the next critical CVE or backdoor drops, the SBOM lets you answer "are we affected and where?" in minutes, and the provenance check ensures no unsigned or tampered artifact reaches production. This is the difference between a controlled incident and a SolarWinds-scale one.

Build It

Implement the verifier: artifact digest, source revision, builder identity, dependency-lock digest, SBOM digest, and signature subject must all match release policy. Show that altering each field is detected.

LAB_MODULE=solution pytest -q

Secure Implementation Patterns

The anti-pattern. Signing an artifact but never verifying it — or "verifying" only that a signature exists, not whose and over what:

if artifact.is_signed: deploy(artifact)            # theater: any signer, any source, any builder

The secure pattern — verify every provenance field against policy (mirrors solution.py):

FIELDS = ("artifact_digest", "source_revision", "builder", "lock_digest",
          "sbom_digest", "signature_subject")

def verify(statement: dict, policy: dict) -> tuple[str, ...]:
    issues = []
    for field in FIELDS:
        if not statement.get(field):
            issues.append(f"missing:{field}")                 # a field absent is a failure
        elif field in policy and statement[field] != policy[field]:
            issues.append(f"mismatch:{field}")                # the value must MATCH the expected policy
    if statement.get("reproducible") is not True:
        issues.append("not-reproducible")
    return tuple(sorted(issues))                              # empty == verified

Each field maps to a tampering class: a wrong artifact_digest = a swapped binary; a forged source_revision = code that didn't come from the expected commit; a wrong builder = it wasn't your trusted pipeline; a wrong signature_subject = the wrong identity signed it. The control is the match against policy, not the mere presence of a signature.

The real-world equivalent at the admission/deploy boundary:

cosign verify --certificate-identity-regexp '^https://github.com/acme/orders' \
              --certificate-oidc-issuer https://token.actions.githubusercontent.com \
              ghcr.io/acme/orders@sha256:<digest>          # verify by DIGEST, pinned identity+issuer
cosign verify-attestation --type slsaprovenance ...        # builder + source commit

Production practices to carry forward:

Pin by digest, never a mutable tag — :latest defeats provenance.
Verify at the consumption point (deploy / Kubernetes admission — Phase 07), not just at build; the build pipeline is itself the highest-value target.
Fail closed: a missing or unverifiable attestation blocks the deploy.
Keep an SBOM so "are we affected and where?" is answerable in minutes when the next CVE lands.

Validation — What You Should Be Able to Do Now

Explain SBOM, provenance, SLSA, and signing — and why verification (not signing) is the actual control.
Detect a modified artifact, a forged source reference, and a wrong builder identity, and explain the attack each prevents.
Explain why the build/sign pipeline is the highest-value target and why deploy-time verification is the backstop.
Use an SBOM to answer "are we affected and where?" when a CVE drops.

The Broader Perspective

This lab teaches you to extend the chain of trust all the way down — from the source commit, through the build, to the artifact that runs — and to treat every link as something to verify, not assume. That is the same instinct as Phase 00 evidence provenance (who collected these bytes, and can I prove the chain?) and Phase 05/07 "verify effective state, not configured intent." Supply-chain security is, at heart, provenance verification applied to software: never trust an artifact because of where it appears to come from; verify, cryptographically, that it does.

Interview Angle

"We sign our releases — are we covered?" — Only if something verifies the signature (and provenance) before deploy; signing without verification changes nothing. The pipeline that signs is itself a target, so verify at the consumption point.
"What's SLSA / provenance for?" — Verifiable build metadata (source, builder, inputs) so you can prove an artifact came from your trusted pipeline; SBOM answers "are we affected and where."

Extension (Stretch)

Replace the local model with real Sigstore/Cosign + SLSA provenance verification, and enforce it at Kubernetes admission (Phase 07).

References

Phase 03 WARMUP Chapter 8; SLSA specification; Sigstore/Cosign docs; in-toto.
SolarWinds / event-stream / xz (CVE-2024-3094) post-mortems.

Security Engineer