snyk/snyk-gradle-plugin

Gradle transitive dependencies affect auto-fixable

Closed this issue · 1 comments

  • gradle version: 6.4.1
  • snyk -v: 1.511.0 (standalone)
  • OS: MasOS Catalina
  • Command run: snyk test --fail-on=all

Expected behaviour

The log doesn't contain transitive dependencies inside the Issues to fix by upgrading

Actual behaviour

The log contains transitive dependencies inside the Issues to fix by upgrading

Why is it happening? I had some 1.3.* Snyk CLI version before and it was wine, all the transitives/deep dependencies were inside the different blocks and the command returned 0.

Yes, we're vulnerable by transitive dependencies but we shouldn't update these kinds of dependencies on our side, explicitly declaring child deps, thus these are not autofixable

Example

One transitive is upgradable and another is not.

Gradle file:

dependencies {
    implementation 'org.openapitools:openapi-generator-gradle-plugin:5.0.0'
}
Issues to fix by upgrading:

  Upgrade com.google.guava:guava@27.0.1-android to com.google.guava:guava@30.0-android to fix
  ✗ Information Disclosure [Medium Severity][https://snyk.io/vuln/SNYK-JAVA-COMGOOGLEGUAVA-1015415] in com.google.guava:guava@27.0.1-android
    introduced by com.google.guava:guava@27.0.1-android


Issues with no direct upgrade or patch:
  ✗ Information Exposure [Low Severity][https://snyk.io/vuln/SNYK-JAVA-COMMONSCODEC-561518] in commons-codec:commons-codec@1.11
    introduced by org.apache.httpcomponents:httpclient@4.5.13 > commons-codec:commons-codec@1.11
  This issue was fixed in versions: 1.13

Where guava and httpclient both are transitive relatively to the current Gradle module, but Snyk considers it as different spicies.

UPD.

Just tried with 1.240.1 -> no transitives in autofixable

This is duplicate of https://github.com/snyk/snyk/issues/1776 sorry I opened it here as really need an explanation here, it affects pipeline creation. I'd like to create a pipeline that wouldn't fail on vulnerabilities in transitives but just inform about it.

@gitphill this can be closed

Fixed with an update mentioned in #174