This Shit is Hard: Applying "Zero Trust" to Open Source Software

Chainguard’s “This Shit is Hard” series showcases the difficult engineering work we’ve tackled to deliver best-in-class outcomes for customers using our products. We’ve covered several important topics, including the Chainguard Factory, Chainguard Libraries for Java, our integrations with several scanner partners, recent hardening of glibc, and our implementation of SLSA Level 3. Today, we’re discussing the concept of Zero Trust in open source software.

If you’ve followed the headlines, you’ve seen the anxiety around open source supply chain security flare up again and again. From the latest NPM credential hack impacting packages with billions of downloads to the still-discussed xz-utils compromise, folks ask us the same question many times over: “How do you protect against threat actors in open source?”

The truth is the risk is the same no matter where an adversary sits in your threat model diagram. And in software, trust is fragile. That’s why Zero Trust doesn’t have to be just a buzzword—it’s the foundation for how Chainguard is protecting critical infrastructure in the age of open source. Here’s how we do it.

The Limits of Identity in Open Source Software

Take Git, for example. It’s the backbone of modern software collaboration, but it was never designed with security as the first priority.

• Identities are trivial to falsify: A Git commit is just a line of text with a name and email address. Anyone can impersonate anyone else with a simple configuration change. There’s no strong proof that “Linus” or “Alice” actually authored the code you’re reviewing, or that it was written at any specific time.

• Credentials are constantly under attack: Long-lived SSH keys, personal access tokens, and registry passwords can be stolen or leaked. Once compromised, attackers can publish new versions of packages or inject subtle backdoors without triggering alarms. The recently successful attacks to capture NPM push credentials is just the latest example in a long pattern of supply chain breaches.

• Trust is fragile and misplaced: As the old saying goes, “On the internet, no one knows you’re a dog.” In practice, no one knows if the person pushing a commit is the trusted maintainer you think they are, or an attacker who’s hijacked their account.

The reality of today’s software supply chain is that it runs on assumed identity. Organizations often take dependencies from strangers across the globe, yet those dependencies may end up embedded in critical infrastructure or national security systems.

The problem isn’t just about external threats or adversaries. A disgruntled employee, a careless contractor, or even an AI-generated pull request with hidden flaws can be just as dangerous. Blindly trusting identities—or the claims people make about the code they publish—simply doesn’t scale in a world where software underpins everything from hospitals to power grids. The software supply chain as it exists today uses the identity of a person or package as a perimeter defense: if you get past it, you have implicit trust for the rest of your actions.

Zero Trust: A Better Way Forward

For the software supply chain, Zero Trust means adopting the mindset: don’t trust, verify. Whether the code is coming from an open source maintainer, a subcontractor, or even an AI coding assistant, Zero Trust requires proof of integrity before that code is allowed into production.

CISA’s Zero Trust Maturity Model gives organizations a clear framework to move beyond perimeter defenses. Its five pillars—Identity, Devices, Networks, Applications & Workloads, and Data—are a roadmap for reducing implicit trust across every layer of IT and software delivery. Yet, they’re all underpinned by software themselves.

CISA guidance was written with government agencies in mind, but its wisdom applies far beyond. Energy, healthcare, finance, or any other industry that depends on open source code, can use Zero Trust as a lens to secure their software.

That’s why forward-looking organizations are treating CISA’s model not as a compliance checkbox, but as a strategic playbook for resilience.

Practical Steps for Zero Trust in the Software Supply Chain

At Chainguard, we see Zero Trust as the foundation for being the Safe Source for Open Source. Here’s what a Zero Trust approach looks like in practice:

• Building from source: At Chainguard, we build everything directly from source code, which prevents over 90% of malware (source). You can learn more about how we do it by checking out Jason Hall’s tour Inside the Chainguard Factory.

• Validate every download: Always fetch source code via HTTPS or SSH from the official upstream source, then check that it matches what’s expected to confirm integrity. If the code doesn’t match, it doesn’t ship.

• Pin all dependencies: Build configuration as code means explicit declarations of all build steps to ensure repeatable, trusted builds. It also means that no single person can push a change without a code review.

• Harden your compiler: One of the most difficult and proactive parts of our security story is how we take compiler best practices and consistently apply them to the software we build. Sergio Durigan Junior gave a great dive into how we go about hardening glibc.

• Isolate each build: Each build should take place in an ephemeral isolated virtual machine, as build environments often have access to secrets or elevated permissions that could compromise itself or other builds on the same system. Protecting these devices is not a simple task.  Supply-chain Levels for Software Artifacts (SLSA) provides actionable insights and a set of standards to use as a best practice. Mark Manning wrote about this previously in This Shit Is Hard: SLSA L3 and Beyond for Chainguard’s infrastructure.

• Test aggressively: Validate not just functionality but behavior between versions. Malicious changes often surface as unexpected behavior. Part of the Chainguard test harness is our open-source project called Malcontent that catches these differences for further (human) inspection. This further protects the integrity of each application we build.

• Verify what runs: Know what you’re running and that it hasn’t been tampered with. In theory this is simple, but in practice most artifacts don't tell you who built them, where they came from, or what's in them. As an example, our software is all signed with Sigstore, which provides cryptographic assurance of provenance. It also includes a signed SBOM (Software Bill of Materials) for accountability on every component.

Each of these maps back to the Zero Trust Maturity Model pillars. Verifying the source code you build and the finished artifacts protects application integrity. Protecting your build environment directly maps to protecting your devices, as does checking the program before it runs. While it’s impossible to truly identify everyone on the internet, it is possible to validate the identity of the machines that build the code and the behaviors of that code. The more you adopt, the closer you move toward “optimal” maturity. By trusting no one identity in this process, the entire system becomes more resilient against compromise.

How Chainguard Helps

Chainguard was founded to make Zero Trust software supply chains for open source a reality. Every piece of software we ship comes with a verifiable chain of custody. That means repeatable builds using hardened toolchains, scanned for unexpected behaviors, and with signed and traceable artifacts. The choice isn’t between spending cycles worrying about upstream compromises or mystery dependencies and spending cycles doing it all in-house. Your engineers can get a secure foundation out of the box, your security teams can have peace of mind, and everyone can ship safer software faster.

Interested in learning more about how we secure the software supply chain? Reach out today.