Why Chainguard uses Grype as its first line of defense for CVEs

In order for Chainguard to ship images with few to zero-known vulnerabilities, we need to:

‍

• Detect vulnerabilities as far “left” in our software delivery pipeline as possible,

• Cast a wide enough net in our search for vulnerabilities to avoid missing any, and

• Form a comprehensive understanding of the impact of any vulnerabilities we do find.

‍

We realized early on that we have to be strategic about how we address these needs — the “what” and “how” of our internal scanning approach has a big impact on our ability to scale our CVE remediation efforts for our Chainguard Images users and customers. To achieve this level of fast, accurate remediation, we selected Grype to be the foundation of our internal vulnerability detection system.

‍

In a prior role, I helped launch and maintain Grype. Now, at Chainguard, my duty is to keep the count of CVEs in our images as low as possible, and to partner with a variety of scanner teams and organizations to support their success in scanning Chainguard Images.

‍

In this blog post, we’ll examine why Chainguard uses Grype, how Grype helps us achieve our mission to minimize CVE counts, and how we use Grype to provide all vulnerability scanners with better data.

‍

Why Grype?

‍

Grype is open source

‍

Predictably, this sets up a virtuous cycle where we’re able to consume Grype code without friction, adapt it to our needs, and contribute improvements and fixes back upstream. To date, Chainguard employees have opened over 25 PRs and issues in Grype and its related repos.

‍

An added bonus is that just like almost everything we build at Chainguard, Grype is written in Go, and it was straightforward to use Grype as a library within our own tooling. This lets us customize scanning behavior to a T, which we leverage to scan Wolfi APK packages before ever creating container images. This means we can identify and fix vulnerabilities significantly faster. And because we’re analyzing software upstream of our Image builds, we can give image scanners visibility into otherwise hidden CVEs.

‍

Grype’s entire data pipeline is also open source. This makes it possible for us to directly contribute support for our data feeds to Grype (which we've done!), giving Grype access to more contextualized data for more accurate scan results.

‍

Speaking of open source scanners, Trivy is another fantastic tool with an open source data pipeline. In a lot of ways, Trivy was the pioneer for this modern style of vulnerability scanner. I’ve found working on open source contributions to Trivy and its related repositories to be a great experience.

‍‍

Grype biases toward false positives over false negatives

‍

Generally speaking, false positives are a huge pain in vulnerability scanning. Check out this recent Chainguard Labs research on why or learn more on Chainguard Academy.

‍

But for scanner designers, there come times when the matching logic is necessarily fuzzy, usually due to low fidelity upstream data. In these cases, it’s just not possible to entirely avoid false positives or false negatives — and you have to make trade-offs. Grype’s design consciously makes trade-offs that favor false positives, in cases where the only alternative leads to false negatives.

‍

In this regard, Chainguard’s incentives align with Grype’s. Our images are getting scanned by various scanners with various data sources. We’d much rather investigate a vulnerability in our images that turns out to be a false positive than overlook a real vulnerability that impacts our customers and find out much later (or never).

‍

In addition, finding and identifying false positives helps us provide useful insights to our customers who may be seeing the same false positives in their own scans. Because we’re seeing these false positives ahead of time, our team can analyze each vulnerability finding and record in our advisory data our diagnosis of why the false positive is showing up. This happens on a frequent basis and is already paying off with customers.

‍

Grype’s bias toward false positives casts a wider net in its searches for vulnerabilities, which helps us provide more complete vulnerability data in our public security feeds that scanners consume.

‍‍

Grype can scan SBOMs (Software Bills of Materials)

‍

SBOMs are a critical mechanism for software transparency. When we’re on the hunt for vulnerabilities, we need as much transparency as possible.

‍

Grype’s companion tool Syft has become one of the SBOM generator tools most used and invested in by the open source community (and its list of supported ecosystems is extensive). Grype was designed to work well with Syft since its beginning, and we’re unashamedly capitalizing on this harmony at Chainguard.

‍

As part of our vulnerability detection process, we use SBOMs as the basis for vulnerability scans rather than raw software artifacts themselves. Grype’s deeply embedded SBOM support gives us features like strong references to SBOM components from vulnerability scan reports. This separation of concerns means we get the best of both worlds — detailed match analysis from Grype, and rich software composition and relationship information from the SBOM. This gives Chainguard staff more context as we’re analyzing scan results and recording conclusions in our advisory data.

‍

For the benefit of all scanners

We use Grype internally knowing that our customers use a wide range of scanners. Grype isn’t the only vulnerability scanner we use — but as of today, it’s the most deeply integrated in our internal processes, and now it should make sense why.

‍

At the same time, it’s important to recognize that what Chainguard uses internally and what Chainguard customers use for compliance or other security requirements for scanning are two distinct concepts. While Grype helps Chainguard manage its unique approach to package distribution, any scanner that implements support for Chainguard Images and Wolfi reaps the benefits of our continuously evolving vulnerability detection and remediation process. In many cases, a full-featured enterprise container security solution that integrates with Chainguard Images, like Snyk or Prisma Cloud, is an ideal choice for our customers because it leads to high-trust, low-toil security workflows.

‍

Looking ahead

We’re eager to find the next deep scanner integration for our vulnerability detection system. We also are committed to collaborating with scanners on enhancements to our security feeds that help scanner tools and platforms provide more value to their end users. For example, one area we’re excited about is the recent uptick in VEX support among scanners and we plan to ship VEX data for Chainguard Images in the near future.

‍

Reach out to our team today to get started exploring unique capabilities Chainguard can leverage in your scanner to eliminate CVEs. To learn more about our existing scanner integrations in Chainguard Images and Wolfi, check out our recent announcement.