DevOps / Advanced: reliability, trust, and governance / Lesson 16

Software supply-chain security

Verify artifact origin, build trust, dependency evidence, and release authorization as separate parts of a security policy.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Map trust across source, builders, artifacts, and consumers.
Separate signatures, provenance, inventories, and authorization.
Plan least privilege and evidence-based compromise response.

Map the path to executable content

The software supply chain includes source control, dependencies, build scripts, runners, caches, artifact storage, signing identities, and deployment consumers. An attacker can target any handoff, including a workflow plugin rather than application source. Identify who can modify each input and which identities can publish or promote outputs. Separate untrusted contribution execution from privileged release execution. A locked dependency graph improves repeatability but does not prove every dependency is authorized or safe. Review updates, ownership changes, and advisories in a process that can patch promptly without bypassing verification.

Distinguish integrity, provenance, and policy

A digest identifies bytes; a signature can authenticate an assertion under a trusted identity; provenance describes how an artifact was produced. The consumer still needs a policy that accepts the expected source, builder, workflow, parameters, and artifact binding. A valid signature from an unrelated project is not authorization to deploy. The first synthetic policy record makes these independent checks visible. It is not a complete cryptographic verifier or a product-specific policy. Verify the currently adopted specification and tool versions; this course refers to SLSA 1.2 concepts without claiming a certification level for any fictional build.

yaml Synthetic consumer trust policy

artifact_binding: exact-reviewed-digest
source: approved-repository-and-revision
builder: approved-isolated-release-workflow
identity: approved-issuer-and-subject
provenance: verified-and-policy-compatible
exception: explicit-owner-and-expiry-only

All conditions matter. The record is a review checklist, not an attestation, signature, or executable enforcement policy.

Use inventories without overclaiming

A software bill of materials describes components within a stated scope and format. It helps investigation and vulnerability response, but may omit runtime-loaded plugins, operating-system packages, or generated content if collection is incomplete. Match inventories to the exact artifact, not merely the repository branch. Known-vulnerability scans depend on advisory data, matching, and configuration, so no findings does not mean no risk. Prioritize exploitable exposure, affected functionality, and available remediation while tracking exceptions with owners and expiry. Do not conceal a failing security gate by deleting an inventory entry or ignoring an advisory indefinitely.

Protect the builder and the consumer

Use ephemeral or strongly isolated execution where appropriate, minimal tokens, reviewed external steps, and controlled artifact publication. A compromised runner can produce a malicious artifact even from clean source. Protect signing or workload identities and validate verification results at the deployment boundary, not only during publication. The second harmless simulation shows a consumer rejecting an unapproved builder even when a synthetic signature flag is true. It does not verify real signatures. Keep emergency exceptions explicit, time limited, and audited; a permanent bypass quietly removes the security property the policy was meant to establish.

python Harmless authorization-policy simulation

def allowed(evidence):
    return (evidence["signature_valid"]
            and evidence["builder"] == "approved-release"
            and evidence["source_reviewed"])
print(allowed({"signature_valid": True, "builder": "untrusted-job", "source_reviewed": True}))
print(allowed({"signature_valid": True, "builder": "approved-release", "source_reviewed": True}))

Expected output

False
True

A synthetic valid-signature flag alone is insufficient. The untrusted builder fails while the fully matching record passes; no real signature or artifact is processed.

Prepare containment and replacement

When a credential, builder, or dependency is compromised, identify affected artifact identities and deployments, restrict further publication, and follow the authorized rotation and response process. Preserve safe evidence without distributing the secret or malicious payload. Rebuild from a reviewed trusted path, verify provenance and consumer policy, and assess whether running systems require additional investigation. Replacing one package does not erase possible access or external effects. Maintain an inventory and retention policy that makes exposure questions answerable. Supply-chain controls are effective when they stop the wrong artifact at the right boundary and support a clear recovery path.

Common errors and fixes

Any valid signature is accepted

Why it happens: Identity verification omitted expected source and builder policy.
How to fix it: Bind verification to approved identities, inputs, and exact artifact.
Prevent it next time: Test wrong-project and wrong-builder rejection cases.

An SBOM is treated as complete security proof

Why it happens: Inventory scope and exploitability were ignored.
How to fix it: Review scope, runtime components, advisories, and exposure.
Prevent it next time: Track inventories by artifact and update response procedures.

A runner credential leaks into logs

Why it happens: Privileged context executed untrusted or verbose steps.
How to fix it: Contain, rotate, and investigate affected artifacts and access.
Prevent it next time: Minimize tokens and separate trust domains.

Check your understanding

1. A signed artifact comes from a fork with a different release workflow. Should it be promoted?

Show worked solution

Not unless the explicit consumer policy authorizes that source and builder. Signature validity answers only part of the question. Verify exact artifact binding and expected provenance, then reject the mismatch or use a reviewed time-limited exception with accountable ownership.

2. A dependency alert affects a component present in an exact release artifact. What evidence guides response?