Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for gradle in Java #2236

Closed
jinsihou19 opened this issue Nov 5, 2024 · 2 comments
Closed

Add support for gradle in Java #2236

jinsihou19 opened this issue Nov 5, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@jinsihou19
Copy link

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.

@jinsihou19 jinsihou19 added the enhancement New feature or request label Nov 5, 2024
@willmurphyscode
Copy link
Contributor

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.

@github-project-automation github-project-automation bot moved this to Done in OSS Nov 12, 2024
@jinsihou19
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Archived in project
Development

No branches or pull requests

2 participants