Zero‑trust moves into software supply chain

Software supply chain security used to mean scanning dependencies and hoping nothing ugly slipped in. That is not enough anymore. The newer idea is harsher and more useful — treat every step in the path from a developer commit to a production deployment as untrusted until it proves itself. Basically, zero trust has moved upstream into build systems, release tooling, and deployment policy. ### What changed in the framing? The big shift is conceptual. Zero trust started as a network and identity model — never trust, always verify. Now teams are applying the same rule to software delivery itself. NIST’s CI/CD guidance explicitly treats the pipeline as a software supply chain, with artifacts, attestations, provenance, and repositories all part of the trust problem. ### Why isn’t an SBOM enough? An SBOM is useful, but it answers only one question well: what ingredients are inside this software? NIST and CISA both frame it as a transparency tool — a machine-readable inventory of components. That helps with vulnerability response and procurement, but it does not prove the build was clean, the signer was legitimate, or the artifact was produced by the pipeline you expected. (csrc.nist.gov) ### So what does zero trust add? It adds verification at every handoff. Who is the developer? What workflow is allowed to build? Did the CI job get temporary credentials or was it sitting on a long-lived secret? Was the artifact signed? Is there provenance saying where and how it was built? Can the deployment platform verify all of that before admitting the release? Turns out this is less like checking a food label and more like checking chain of custody. (nist.gov) ### Why are short-lived credentials such a big deal? Because static secrets are supply-chain landmines. GitHub’s OIDC flow lets workflows request short-lived cloud tokens instead of storing long-lived credentials in repository secrets. That cuts down the blast radius if a workflow, runner, or repo gets compromised. The credential is tied to a specific job and expires automatically, which is exactly the kind of “trust nothing for long” behavior zero trust wants. (docs.github.com) ### What do signing and attestation actually prove? Signing proves integrity — this artifact is the one that was produced and hasn’t been swapped out. Attestation adds context — who built it, when, from what source, under what workflow. SLSA calls that provenance. Sigstore’s tooling is built around signing and verifying artifacts, including SBOMs, with ephemeral keys and a transparency log. The catch is that signatures without provenance are only half the story. You want both. (docs.github.com) ### Where does policy-as-code fit? At the gate. Policy engines let teams say, in code, that unsigned images do not deploy, missing SBOMs fail the pipeline, or only artifacts with valid provenance from approved builders can reach production. That matters because manual review does not scale. Zero trust for the software supply chain only works if verification is automatic and enforced at CI and CD time, not left as a spreadsheet exercise. (slsa.dev) ### Is this just a federal compliance story? No — but federal pressure helped normalize the vocabulary. EO 14028 pushed SBOMs and secure software development into mainstream procurement and security practice. Even where specific attestation paperwork has shifted, the underlying direction did not reverse: buyers and operators want stronger proof of software integrity, not just promises from vendors. (csrc.nist.gov) ### What’s the bottom line? The useful mental model is simple. Your build pipeline is now part identity system, part factory floor, part border checkpoint. Zero trust in software supply chains means every stage has to prove itself before the next stage accepts its output. That is where the field is heading — away from “scan and ship” and toward “verify, attest, and then deploy.” (csrc.nist.gov) (nist.gov)