Is Grype a single point of failure for Chainguard’s CVE detection?
Spoiler alert: it’s not. Grype is just one part of an interconnected system at Chainguard.
As explained in a previous blog, Chainguard relies on Grype as our first line of CVE detection. A Grype finding triggers updates to the affected package or container to keep customers safe.
Recently, we had an interesting question come in:
“If Grype is compromised, or the information is no longer reliable, how can we (i.e., Chainguard customers) trust what we are receiving?”
As part of our ongoing commitment to customer obsession, this post aims to answer that question by explaining how our system is designed to address this.
Building from source
In addition to using Grype to identify new upstream CVEs, Chainguard also builds a Grype image as part of our catalog.
Like all Chainguard Containers, our Grype image is built from source. This eliminates risks from precompiled binaries — a common vector in modern supply chain attacks such as xz-utils, Shai-Hulud, or the recent Trivy compromise.
An additional benefit of building from source is that this information is public and open. Chainguard believes in the principles of open source, including that sunlight is the best disinfectant.
Malware detection
Building from source reduces risk, but no single control is sufficient. We rely on layered defenses to detect upstream compromise at the source-code level. If malware is introduced into an upstream package (such as Grype) at the source code level, we can use malware detection to identify it. In fact, Chainguard uses two primary approaches to detecting malware in packages.
The first, which we call Sentinel, relies on open source information sources from across the industry to identify suspicious or malicious packages. This ensures we are up to date with the latest information disclosed.
The second, which we call Malcontent, performs direct behavior analysis to detect indicators of malicious behavior, such as network calls or privilege escalations.
Grype’s input sources
There is an alternative attack method in which an attacker could modify the data used as input to the Chainguard Grype database, while leaving the Grype image itself unchanged. A hypothetical example would be for the attacker to exclude CVE-2026-XYZ from the Grype inspection, knowing that this would leave the CVE still present in Chainguard Containers, and then deploy an attack exploiting CVE-2026-XYZ in customer environments.
To defend against this possibility, Grype uses a variety of input sources, ensuring that an attacker would need to prevent the CVE from appearing on any of these lists to prevent it from appearing in the Grype database.
Currently, this list is:
chainguard
chainguard-libraries
epss
github
kev
nvd
wolfi
Each of these data sources is public and available for inspection. Just as with open source code, open source information provides the strongest defense against manipulation. In addition, CVEs added to the Grype NAK list are audited and manually reviewed for malicious modifications.
The final layer
Even with layered controls, no system is infallible. It’s always possible that a vulnerability is missed due to an issue with Grype itself, its input sources, or another mechanism. In these cases, Chainguard has its final layer — a mechanism that allows anyone to report a vulnerability or other security incident to us for further investigation. The full details of this are available here.
Chainguard’s interconnected system keeps you safe
While it may appear at first glance that Chainguard relies too heavily on Grype for input into our CVE remediation process, in fact, this is just one part of an interconnected system. We have multiple methods in place to ensure that the information fed into Grype and Grype itself are both working as intended and independently verifiable, as all are open source. This allows Chainguard to continue to provide best-in-class supply chain security.
If you have any further questions about the security of our systems, we would love to hear from you! Just as this answer was triggered by a great question, if you have any other questions, get in touch with our team today.
Share this article
Articles connexes
- sécurité
AI is finding vulnerabilities faster than anyone can patch them. Now what?
Ed Sawma, VP of Product Marketing
- sécurité
Attacks rewritten: Where malware enters the build
Manfred Moser, Sr. Principal Developer Relations Engineer, and Patrick Smyth, Principal Developer Relations Engineer
- sécurité
Your riskiest supplier isn't a vendor. It's a registry.
Cameron Martin, Manager, Solutions Engineering - APJ
- sécurité
Malicious axios versions published to npm: Chainguard customers protected
Quincy Castro, CISO
- sécurité
How to protect your organization from the telnyx PyPI compromise
Ross Gordon, Staff Product Marketing Manager, and Bria Giordano, Director, Product Management
- sécurité
You were one pip install away from the litellm breach. Chainguard customers weren’t.
Ross Gordon, Staff Product Marketing Manager, and Bria Giordano, Director, Product Management