Integration of Custom Vulnerability Tracker with Grype

Grype
1

Greetings,

We are developing podarmor.org, a platform aimed at enhancing container security for enterprises. As part of this initiative, we are building a custom, hardened distribution and an in-house vulnerability tracker, designed to enable our clients to conduct thorough vulnerability scans within their container environments.

While we have a technical understanding of implementing the integration with Grype, I would appreciate guidance on any additional requirements or prerequisites necessary for acceptance as a vulnerability provider by the Grype team.

Thank you for your assistance.

Best regards,
Meet

1 Like
2

Hi @meetcshah19,

In order for Grype to match on a new data source, there are a few requirements that must be met:

Syft must be able to identify the packages and distro in question as coming from that data source. For example, when Syft scans a RedHat image, it finds from /etc/os-release that it’s a RedHat image, and it finds a bunch of RPMs, so Grype knows from this that there are a bunch of RPMs it should compare against RedHat’s vulnerability data. So some questions to ask here:

  1. Do podarmor images say what they are in /etc/os-release or similar?
  2. What package manager is used? If, when Syft finds a package in the image, if it’s from a language package manager like npm, Grype will by default compare that against GitHub Advisory data.

Once Syft can identify the images and the packages, then it’s time to start getting data into Grype’s database. This requires adding a new provider to Vunnel and making sure grype-db emits the correct rows in Grype’s database for that provider. There are a few requirements to start this:

  1. Vunnel has to be able to download all the vulnerability data from the provider. Since Vunnel often runs in the mode of “download all the vulnerabilities at once” making the vulnerability be able to handle that is important.
  2. This vulnerability API should be public, since Vunnel is open source and it’s unreasonable to expect contributors to have credentials to every vulnerability provider.
  3. Having the vulnerability API also support, “download all the vulnerabilities that have changed since some timestamp” can also help a lot.
  4. We also need some test images that we can pull without authentication. The end to end tests of the database basically say, “build a new vulnerability database with the changed code, then do an experiment to prove that Grype’s matching did not get worse.” So we need a test image with a non-empty set of vulnerabilities in it in order to test the provider.

Does that answer your question?

3

Hi Will,
Thanks for the prompt response.
Yes that answers my question, I have actually tested a partial implementation end to end with a provider in vunnel and grype locally. I will open PRs to vunnel and grype for the new provider as soon as we have the public vulnerability API and test images.
I believe this should be straightforward since we are almost exactly like Debian (in terms of structure) and also use the Debian package manager which already works with grype.
I will be in touch as soon I have the PRs ready.
Thanks,
Meet

4

Hi @meetcshah19,

I don’t think Syft can yet distinguish PodArmor from Debian images, which is a prerequisite to all the vulnerability work. syft -o json parmor.azurecr.io/nodejs/nodejs:18 | jq .distro produces this:

{
  "prettyName": "Distroless",
  "name": "Debian GNU/Linux",
  "id": "debian",
  "version": "Debian GNU/Linux 12 (bookworm)",
  "versionID": "12",
  "homeURL": "https://github.com/GoogleContainerTools/distroless",
  "supportURL": "https://github.com/GoogleContainerTools/distroless/blob/master/README.md",
  "bugReportURL": "https://github.com/GoogleContainerTools/distroless/issues/new"
}

But there’s nothing in there to tell us that we should prefer your vulnerability feed to the Debian feed.

Also, running syft -o json parmor.azurecr.io/nodejs/nodejs:18 | jq '.artifacts[] | { name: .name, purl: .purl }' and choosing an artifact as an example:

{
  "name": "netbase",
  "purl": "pkg:deb/debian/netbase@6.4?arch=all&distro=debian-12"
}

Also doesn’t tell us anything about where the package came from. Even if you build a new Vunnel and Grype-DB feed today, Grype will not know to match against them.

This also brings us to another question: If your images is Debian, should Grype also match dpkgs found in your image against the Debian vulnerability feed? What will your feed add that the Debian and GHSA feeds don’t provide today?

I think we should probably keep discussing for a minute before we open PRs, since without addressing the questions about how Syft knows it’s scanning a PodArmor image, and what the scope of your vulnerability provider is, there’s a risk we’re wasting work with the PRs.

5

Hi Will,
Sorry for the confusion, parmor.azurecr.io/nodejs/nodejs:18 is not updated yet, I will let you know when it is. I was just trying to make sure grype is open to adding new providers when I put up this thread before I implement the whole thing.

I don’t think Syft can yet distinguish PodArmor from Debian images, which is a
prerequisite to all the vulnerability work. syft -o json > parmor.azurecr.io/nodejs/nodejs:18 | jq .distro produces this

I understand this and we have changed the distro parameters to reflect that its not the debian distro and a podarmor distro. This is simply not the version we will be putting out.

This also brings us to another question: If your images is Debian, should Grype also match dpkgs found in your image against the Debian vulnerability feed? What will your feed add that the Debian and GHSA feeds don’t provide today?

The images will be similar to Debian in terms of structure but completely different otherwise. We will also be building our own packages from scratch and hence finally the container will contain packages from which will indicate they were built by PodArmor. And since we will be building packages we need to have our own vulnerability feed to reflect what is the status of vulnerabilities based on our own versions.

Thanks for taking the time to actually dig into the website and actually check out the container (I didn’t think you would do this otherwise I would have warned you beforehand that it is out of date).

Thanks,
Meet

6

I would start work in Syft: work on your images and possibly in Syft until you’re confident Syft is finding the right distro and can tell what kind of packages you are vending. It sounds like you’re using dpkg?

I’m concerned about the data quality here. If you take the same upstream source code as a major distro, say Debian, and compile your own packages from it, it is very likely that security researchers will report vulnerabilities in the code to Debian, or to the package maintainers, but not to you all. How will your data feed relate to vulnerabilities reported to your upstream code sources?

Please make sure the vulnerability feed is comprehensive. That is, report vulnerabilities when you become aware of them, and don’t wait until they are fixed. A lot of vendors want to have a vulnerability feed that is really a list of fixed vulnerabilities. That is much less useful to our users; please publish everything, especially if you expect Grype to defer to your feed entirely and not, for example, add data from your feed to data from your upstreams.

Thanks for opening a line of discussion ahead of time! It’s much better to think through these things before spending the engineering effort.

To sum up, I have a few questions:

  1. It sounds like you’ll be using dpkg packages, but compiling them yourselves, and will put something about podarmor in /etc/os-release. Is that right?
  2. What are your upstreams? That is, what is your source for the code and artifacts that you repackage?
  3. How will your vulnerability feed relate to the vulnerability feeds of your upstreams? If someone reports a vulnerability to the curl maintainers, and you repackage curl for your distro, how will Grype know this?
  4. Will your distro feed be comprehensive? That is, will you report vulnerabilities promptly after you learn of them, rather than wait until they’re fixed?
7
  1. Yes that is right.
  2. The sources we plan to build from will be exactly the ones that Debian uses to build (We will have a small subset of packages that Debian has today).
  3. So we will be writing our own tracker like Debians tracker that grype uses today (https://security-tracker.debian.org/tracker/data/json) and this will contain vulnerabilities reported to the package maintainers.
  4. Yes for sure. The whole point of doing this integration for us is to allow our customers to scan and independently verify the CVEs present in their containers. We also want to be able to show the vulnerabilities present on our dashboard using grype in our backend.
2 Likes