How Chainguard secures open source and stops CVE fatigue

Keith Shaw: Hi, everybody. Welcome to DEMO, the show where companies come in and show us their latest products and platforms. Today, I'm joined by John Osborne. He is a Senior Principal Sales Engineer at Chainguard. Welcome to the show, John. John Osborne: Thanks, Keith. Happy to be here.

Keith: Tell us a little bit about Chainguard, and then what you're going to be showing us on DEMO today. John: Definitely. Chainguard is about four years old. We are the safe source for open source.

Instead of giving you more security notifications and alerts telling you what’s broken, we actually fix it for you. You can think of us as a secure build system.

There’s a quote I love that describes us — someone once said, “Imagine you're in a parallel universe where open source is secure.” Chainguard is building that parallel universe. Keith: So who is this really designed for? Just developers? Or are there others in the enterprise who would benefit?

John: Pretty much anyone using open source. Our footprint includes container images, application libraries, and VMs. We work a lot with administrators and developers. Our most common customer is a centralized engineering team responsible for implementing security standards — typically in banks, financial institutions, government agencies, that kind of thing.

Keith: What’s the big problem you're solving? John: There are two major problems. First, the vulnerability problem. It's been around a long time, but it's gotten exponentially worse. Customers are spending 30 to 40% of their engineering time just doing CVE triage. Second, malicious packages.

The difference between CVEs and malicious packages is whether the issue was intentional. Attacks on open source maintainers are growing because it's easier to compromise one developer on a Python package than, say, a Linux distro.

The overall software supply chain is at risk — making sure your software is exactly what you expect is a growing challenge. Keith: So without a platform like Chainguard, companies are manually monitoring their open-source software for vulnerabilities and risks? John: Exactly.

They’re either vulnerable to malicious packages or stuck in the never-ending CVE loop. What usually happens is that developers get tickets or alerts for critical or high-priority findings, which takes up a lot of time.

The time waste I call “CVE theater.” It's a constant downstream risk management exercise. The real issue is that many CVEs don’t even have an update available. In our analysis, updating an app to the latest version typically only fixes 3–7% of vulnerabilities.

Chainguard builds everything from source on an hourly basis. So if there are fixes, we apply them quickly. For companies not using Chainguard, those updates might come months — or years — later. Keith: So you’re reducing that 30–40% engineering time loop to... John: We’re trying to make it zero.

I like to say: you're driving down the street and all the lights turn green. Instead of constantly responding to alerts, everything just works. We build functional equivalents of software that act the same, but pass scans cleanly.

Keith: Everything comes back clean, and developers can ship software securely and easily. John: Exactly.

Keith: All right — let's go to the demo. John: Awesome. I'll show you a few things. First, this is the Chainguard Console. Our first product focuses on the image footprint of open source. We’ve built 1,400 variants of commonly used containers — not even counting versioning.

You can compare, for example, the upstream Prometheus image to the Chainguard version. Typically, there are 12 CVEs in the upstream version. If you drop in our Chainguard image — which behaves the same — the CVEs drop to zero. Keith: So it’s a drop-in replacement? John: Yep.

The switching cost is near zero. And because we build hourly, you get near real-time remediation. We also provide software supply chain artifacts like SBOMs, advisories, and upstream version tagging. Keith: What about deployment? John: Most customers use Helm to deploy open source software.

It’s simple — you just update the image reference in your Helm values file to point to Chainguard. That’s it.

I also want to show something else. To address the malicious package problem, we created an open source project called Malcontent. We use it in our build system, but it’s freely available. It detects around 15,000 issues related to privilege escalation and supply chain attacks.

For example, it can detect attacks like the recent TJ GitHub Actions compromise or the XC incident. Malcontent flags when an artifact doesn't match its source — typically due to CICD tampering. Keith: So you’re detecting when something’s been manipulated during the build? John: Exactly. Take the recent Ultralytics attack.

Instead of altering source code, attackers changed the artifact during publishing. Most users wouldn’t even know. Malcontent caught that.

It flagged several things — hardcoded IP addresses, unexpected ports, and more. These are the kinds of signals that should raise immediate red flags in your pipeline. Keith: And this is part of your second product? John: Right. It’s called Chainguard Libraries.

While container images come from about 5,000 source repos, libraries span 600,000–700,000 repos. So it’s a much bigger scope. In our second demo, I rescan a previously flagged library — this time using the Chainguard-secured version. It passes cleanly. No alerts. Everything matches.

The source code and the artifact are aligned. The scan confirms that we’re not susceptible to the earlier attack. Keith: So your tools solve both the business challenge — wasting engineering time — and the security challenge of malicious supply chain attacks. John: Exactly. Vulnerability reduction improves efficiency.

Malicious package detection improves security posture. And tools like Log4j prove how impactful this can be. Keith: Where can companies go to learn more? Do you offer a free tier or trial? John: Yes — just visit chainguard.dev. We offer a free tier for images, no signup needed.

We also offer proofs of value, where we help integrate into your existing systems. That’s part of my role — making sure it’s a smooth experience. Keith: Great. John, thanks for being on the show and for the demo. John: Thanks for your time — I really appreciate it.

Keith: That’s going to do it for this episode of DEMO. Be sure to like the video, subscribe to the channel, and leave your thoughts in the comments. Join us every week for new product showcases. I'm Keith Shaw — thanks for watching.