search

anchore / grype

A vulnerability scanner for container images and filesystems
Apache License 2.0
8.87k stars 575 forks source link

Add support for gradle in Java #2236

Closed jinsihou19 closed 2 weeks ago

jinsihou19 commented 3 weeks ago

What would you like to be added:

Add support for gradle in Java.

Why is this needed:

Gradle project is one of the most popular Java projects.

willmurphyscode commented 2 weeks ago

Hi @jinsihou19! Thanks for opening an issue.

I don't have enough information to understand your request yet. There are a few ways we already support Gradle, and I'm not sure whether this answers your use case or not.

In order to "support" a given package ecosystem or build tool or whatever, two things need to happen: Grype needs to find the packages, and Grype needs to have a vulnerability data source for the packages. Generally, Grype invokes Syft internally to find packages, but you can also give Grype your own SBOM.

  1. We have vulnerabilities in the database for Java packages via GitHub security advisories (GHSA), which covers Maven Central, so if Grype knows about a Java package, it can look and see if there are vulnerabilities against it. So if Grype is given an SBOM with Java packages in it, or finds Java packages itself, Grype can search for vulnerabilities that affect the packages.
  2. We already find Java packages a few different ways: we parse Gradle lockfiles in Syft, and we catalog JARs themselves in Syft.

So when I say we support Gradle, what I mean is: if there are JARs (or, in a directory scan, gradle lockfiles), Grype will find Java packages from them, and will look for vulnerabilities in them from GHSA.

There are a couple of limitations here:

  1. When scanning images, we don't consider gradle lockfiles. (This is because we assume that, in building the image, Gradle would have downloaded the actual JARs for the dependencies, and we will get better information by looking at those.)
  2. When scanning directories, we also consider Grade lockfiles, but not Grade scripts like build.gradle or build.gradle.kts, because the Gradle scripts in Kotlin or Groovy are little programs, and we have no way to know what they'd do without running them. (See anchore/syft#2472). The upshot here is that you need to tell Gradle to install everything and generate a lockfile before a Syft or Grype directory scan will get you accurate information.

Does this answer your question? Are you doing a scan that didn't find a vulnerability you expected to? Are you trying to scan images or directories? Until we know more about your use case, we can only make general answers.

jinsihou19 commented 2 weeks ago

Hi @jinsihou19! Thanks for opening an issue.

I don't have enough information to understand your request yet. There are a few ways we already support Gradle, and I'm not sure whether this answers your use case or not.

In order to "support" a given package ecosystem or build tool or whatever, two things need to happen: Grype needs to find the packages, and Grype needs to have a vulnerability data source for the packages. Generally, Grype invokes Syft internally to find packages, but you can also give Grype your own SBOM.

  1. We have vulnerabilities in the database for Java packages via GitHub security advisories (GHSA), which covers Maven Central, so if Grype knows about a Java package, it can look and see if there are vulnerabilities against it. So if Grype is given an SBOM with Java packages in it, or finds Java packages itself, Grype can search for vulnerabilities that affect the packages.
  2. We already find Java packages a few different ways: we parse Gradle lockfiles in Syft, and we catalog JARs themselves in Syft.

So when I say we support Gradle, what I mean is: if there are JARs (or, in a directory scan, gradle lockfiles), Grype will find Java packages from them, and will look for vulnerabilities in them from GHSA.

There are a couple of limitations here:

  1. When scanning images, we don't consider gradle lockfiles. (This is because we assume that, in building the image, Gradle would have downloaded the actual JARs for the dependencies, and we will get better information by looking at those.)
  2. When scanning directories, we also consider Grade lockfiles, but not Grade scripts like build.gradle or build.gradle.kts, because the Gradle scripts in Kotlin or Groovy are little programs, and we have no way to know what they'd do without running them. (See Gradle support (non-lockfiles) syft#2472). The upshot here is that you need to tell Gradle to install everything and generate a lockfile before a Syft or Grype directory scan will get you accurate information.

Does this answer your question? Are you doing a scan that didn't find a vulnerability you expected to? Are you trying to scan images or directories? Until we know more about your use case, we can only make general answers.

Thank you for your answer, I will try the solution you mentioned. I will reply if I have any questions later.