Exercise 2: Artifact Attestation & Provenance

Goal: Understand WHAT attestation contains, prove provenance with consumer-side verification, demonstrate tamper detection, and connect to the SLSA supply chain integrity framework.

📝 Open docs/provenance-verification.md — record your provenance findings and tamper test results.

Threat Framing

Your OIDC workflow builds a container image and pushes it to a registry. But what if someone modifies the image in the registry between build and deploy? Or pushes a different image with the same tag?

Without attestation, you have no way to know. The deployment proceeds with a potentially compromised image.

Step 1: Understand What’s Inside an Attestation

Before running anything, understand the STRUCTURE of an attestation. It’s not just “a signature” — it’s structured provenance metadata proving the complete chain of who/what/where/when/how:

Attestation Structure (SLSA Provenance v1.0):

┌─ Subject ──────────────────────────────────────────────┐
│  WHAT: Container image digest (sha256:abc123...)       │
│  The specific artifact being attested                  │
├─ Builder ──────────────────────────────────────────────┤
│  WHO built it: GitHub Actions (ephemeral, isolated)    │
│  Trust basis: Hosted runner managed by GitHub          │
├─ Source ───────────────────────────────────────────────┤
│  WHERE: Repository, commit SHA, branch, trigger event  │
│  Verifiable: "Was this triggered by a reviewed PR?"    │
├─ Build Config ─────────────────────────────────────────┤
│  HOW: Workflow file, steps, inputs, environment        │
│  Reproducible: Same inputs → same verifiable artifact  │
└────────────────────────────────────────────────────────┘

When you run gh attestation verify, you’re verifying ALL of these fields — not just checking a signature.

Step 2: Review the Attestation Step in the OIDC Workflow

The .github/workflows/build-deploy-oidc.yml workflow already includes an attestation step. Examine it:

    - name: Attest Build Provenance
      uses: actions/attest-build-provenance@v2
      with:
        subject-name: $/$
        subject-digest: $
        push-to-registry: true

This step:

• Signs the container image digest with a Sigstore-based attestation
• Records which commit, workflow, and trigger produced this artifact
• Pushes the attestation to the container registry alongside the image

Step 3: Run the Workflow

# Trigger a workflow run that builds and attests the image
gh workflow run build-deploy-oidc.yml --ref main

# Wait for completion
gh run watch

Step 4: Consumer-Side Verification

Now verify the attestation from the consumer side — as if you were a deployment pipeline or auditor pulling this image:

# Verify the attestation of the built image
gh attestation verify oci://${ACR_NAME}.azurecr.io/supply-chain-demo:latest \
  --owner {owner}

Expected output includes the provenance metadata. Examine it to answer these questions:

# Detailed provenance inspection
gh attestation verify oci://${ACR_NAME}.azurecr.io/supply-chain-demo:latest \
  --owner {owner} \
  --format json | jq '.verificationResult.signature.certificate'

Step 5: Tampering Proof — “The Auditor’s Question”

An auditor asks: “How do you know the image in production wasn’t modified after it was built?” Your answer: “We can verify. Watch.”

Prove that attestation detects unauthorized modifications:

# Re-tag the image (simulating a tampering scenario)
docker pull ${ACR_NAME}.azurecr.io/supply-chain-demo:latest
docker tag ${ACR_NAME}.azurecr.io/supply-chain-demo:latest \
  ${ACR_NAME}.azurecr.io/supply-chain-demo:tampered

docker push ${ACR_NAME}.azurecr.io/supply-chain-demo:tampered

# Now verify the "tampered" tag — this should FAIL or show no attestation
gh attestation verify oci://${ACR_NAME}.azurecr.io/supply-chain-demo:tampered \
  --owner {owner}

The verification fails because no attestation exists for this digest — proving that unattested or modified images are detectable.

Side-by-side result:

Step 6: Chain of Custody — Bridge to Exercise 3

Attestation doesn’t exist in isolation. It’s one link in a chain of custody that spans the entire delivery pipeline:

Source Code → Build → ATTEST → Registry → Deploy (VERIFY) → Runtime (MONITOR)
    ↑            ↑       ↑          ↑           ↑                ↑
  WS2         GitHub   Exercise    Container   Admission       Exercise 3
Guardrails   Actions   2 (here)   Registry    Policy        (Defender)

In production, you would enforce attestation verification at deployment time — a Kubernetes admission controller that BLOCKS deployments without valid provenance. This ensures the chain is unbroken from source to runtime.

Exercise 3 shows the other end of this chain: how Defender for Cloud traces FROM runtime BACK to source, using the provenance that attestation provides.

Step 7: Update THREAT-MODEL.md

Now fill in rows 4-5 of THREAT-MODEL.md:

# Edit THREAT-MODEL.md to fill in rows 4-5
# Replace the "?" placeholders with the mitigations above

Key Insight

Artifact attestation answers the question: “Is what’s running in production actually what we reviewed and approved?” Without it, you are trusting the pipeline blindly. With it, every artifact carries cryptographic proof of its origin.

NIST Callout

NIST SP 800-204D states that each activity in the CI/CD pipeline must maintain integrity against unauthorized modification. Artifact attestation is how we prove that integrity — every build is signed, every deployment is verifiable.

SLSA Framework Alignment

GitHub artifact attestations achieve SLSA Level 3 (Supply-chain Levels for Software Artifacts), an industry standard developed by the OpenSSF:

When an auditor asks “What SLSA level do you achieve?” — the answer is Level 3, backed by GitHub artifact attestations with Sigstore-based signing.

Tip: Run scripts/verify-exercise2.sh to validate your Exercise 2 completion.