Supply Chain Integrity & Code-to-Cloud Visibility

🎯 Workshop Overview

“Secure code is not enough. You must also secure the PATH from source to runtime — and prove what arrived is what you built.”

This is Workshop 3 of 4 in the Agentic DevSecOps series. A hands-on workshop (30–45 min, 3 exercises) for DevSecOps engineers who need to eliminate credential theft, prove artifact provenance, and trace runtime vulnerabilities back to their source commit — using OIDC, GitHub artifact attestations, and Microsoft Defender for Cloud.

📚 Learning Objectives

By the end of this workshop, you will be able to:

1. Explain why supply chain integrity requires controls beyond code scanning — protecting the delivery path, not just the code
2. Replace long-lived deployment secrets with OIDC federated credentials, eliminating an entire class of credential-theft attacks
3. Sign build artifacts with attestations and verify provenance from the consumer side using gh attestation verify
4. Trace a runtime vulnerability back through the delivery chain to its source commit using Microsoft Defender for Cloud’s code-to-runtime correlation
5. Update the threat model with supply chain controls (OIDC for credential theft, attestation for artifact tampering)

🏗️ NIST SP 800-204D Alignment

This workshop focuses on PS — Protect the Software: ensuring that all forms of the software are protected from unauthorized access and tampering.

📖 Curriculum

💬 Discussion Prompts

1. Blast Radius of OIDC Misconfiguration — If your OIDC federated credential configuration is compromised (e.g., wildcard subject claim), what’s the blast radius? How does this compare to a leaked static secret? How would you recover?

2. Pipeline Integrity Beyond Credentials — NIST SP 800-204D calls for CI/CD pipeline integrity verification. We secured credentials (OIDC) and artifacts (attestation). What other pipeline steps could be compromised? (Think: build dependencies, runner images, action versions.)

3. Attestation for Auditors — How would you explain artifact attestation to a non-technical auditor? What evidence would you show them to prove a production deployment matches a reviewed PR?

4. Scaling OIDC Across the Organization — Your team has 200 repositories deploying to 5 cloud environments. How would you roll out OIDC at scale? What governance controls would you put in place to manage federated credential configurations?

🚀 Optional Extensions

Extension A: Copilot Pipeline Updates

Can GitHub Copilot help update CI/CD infrastructure?

1. Open the Dockerfile in VS Code with Copilot enabled
2. Ask Copilot: “Update this Dockerfile to use a more secure base image with minimal attack surface”
3. Ask Copilot: “Add a health check to this Dockerfile”
4. Review the suggestions — does Copilot understand supply chain implications of base image selection?

Extension B: Attestation as Compliance Evidence

Export attestation data for auditor submission:

gh attestation verify oci://${ACR_NAME}.azurecr.io/supply-chain-demo:latest \
  --owner {owner} \
  --format json > attestation-evidence.json

cat attestation-evidence.json | jq '{
  buildTimestamp: .verificationResult.statement.metadata.buildFinishedOn,
  sourceRepo: .verificationResult.statement.invocation.configSource.uri,
  sourceCommit: .verificationResult.statement.materials[0].digest,
  builder: .verificationResult.statement.builder.id
}'

Extension C: Multi-Registry Provenance

Test attestation verification across different container registries:

1. Push the same image to a second registry (e.g., GitHub Container Registry)
2. Verify attestation works from both registries
3. Discuss: How does registry choice affect supply chain trust?

Extension D: Tampering Deep-Dive

Explore additional tampering scenarios:

1. Modify a workflow file to inject an extra build step — does attestation still pass? (Yes — but the provenance metadata changes)
2. Pin action versions vs. using @main — what’s the supply chain risk?
3. Discuss: What would a comprehensive pipeline integrity policy look like?

📎 References