Build Systems are Production

Supply chain security has a habit of refusing to fade, and it’s not because the industry enjoys pain. It’s because the attacker’s logic is perfect: why break into production when you can get your pipeline to deliver the compromise for you?

That’s not a theoretical risk. It’s a simple inversion of trust.

If an attacker can slip something malicious into a dependency, a base image, a build runner, a signing process, or a registry, the organisation does the rest of the work. The artefact gets built, tested, approved, deployed, scaled. It inherits legitimacy because the pipeline is treated as a trusted machine.

This is why “we scan dependencies” isn’t the same as “we have a secure supply chain”. Scanning is about finding known badness. Supply chain security is about preventing unauthorised change and proving the integrity of authorised change.

A defensible pipeline is one you can explain under pressure. Where did this artefact come from? Which source produced it? Which build ran? What identity ran that build? What dependencies were pulled? What got signed? What got promoted? If you can’t answer those questions cleanly, you’re not controlling trust—you’re assuming it.

The architectural pattern is boring and effective: isolate build environments, treat runners like high-value assets, remove long-lived secrets from CI, use short-lived credentials, separate build identities from deploy identities, sign artefacts, and verify signatures at deploy time. Not as a ceremony, but as a gate: if provenance can’t be proven, it doesn’t run.

SBOMs fit here, but only if they’re used operationally. If the SBOM is a PDF that exists for audit day, it’s theatre. If it’s wired into impact analysis, vulnerability response, and change detection, it becomes part of your control plane.

The uncomfortable truth is that many organisations protect production better than the systems that create production. That used to be merely ironic. Now it’s the fastest path to a breach that ships itself.