CVE-2022-25857 flagged on snakeyaml 1.30, which appears to be a dependency of the Detekt Grade plugin

[volkert-fastned]

See also https://github.com/detekt/detekt/issues/5271

The OWASP Dependency Check Gradle plugin version 7.1.2 flags vulnerability CVE-2022-25857 in dependency snakeyaml v1.30 on a project that also has the Detekt Gradle plugin configured. The ./gradlew -q dependencies command shows that snakeyaml is a transitive dependency of the Detekt plugin. The ./gradlew buildEnvironment doesn't list this dependency at all.

I've tried suppressing this issue, both by CPE and by CVE, but that didn't appear to work.

Also, overriding plugin dependencies is apparently not trivial in Gradle. See this discussion: https://discuss.gradle.org/t/how-to-change-the-version-of-dependency-of-a-gradle-plugin-as-an-end-user/32456

I think I remember having a similar conversation here before, but is there truly no way to configure the OWASP Dependency Check Gradle plugin to disregard plugin-related vulnerabilities that do not affect the build artifacts, or merely log such vulnerabilities as warnings, without failing the build?

Thanks.

[0x6a77]

un-suppresable dep-check cves come up from time-to-time, but the work-around is fairly generic:

configurations.all {
    resolutionStrategy.eachDependency {
        if ((requested.group == "org.yaml") and (requested.name == "snakeyaml")) {
            useVersion("1.31")
            because("https://github.com/jeremylong/DependencyCheck/issues/4802")
        }
    }
}

(using the kotlin dsl — groovy can do the same)

[lackovic]

Since my service is not processing YAML files my workaround was to exclude snakeyaml from being imported as transient dependency from any dependency by adding the following lines to my build.gradle:

configurations.implementation {
    exclude group: 'org.yaml', module: 'snakeyaml'
}

[volkert-fastned]

Unfortunately, another CVE is being flagged by 1.31 as well, for which no fix or mitigation is available. This is CVE-2022-38752. And the snakeyaml developers apparently consider it a non-issue, so it's not expected to be "fixed".

@jeremylong This isn't the first time that the OWASP Dependency Check Gradle plugin flags a vulnerability in the dependency of a Gradle plugin, which is not part of the actual build. Is there really no way to improve the plugin so it can be configured to ignore plugin dependencies?

[0x6a77]

there is now a 1.32 that doesn't trigger for CVE-2022-25857

[volkert-fastned]

Unfortunately, 1.32 does not prevent CVE-2022-38752 from being triggered, since that CVE doesn't specify an affected version range. :confused: See https://github.com/jeremylong/DependencyCheck/issues/4839

This is becoming quite a mess. There's (at least?) three CVEs regarding snakeyaml that have popped up lately:

• CVE-2022-25857 -> cpe:2.3:a:snakeyaml_project:snakeyaml:*:*:*:*:*:*:*:* -> mitigated in snakeyaml v. 1.31
• CVE-2022-38751 -> cpe:2.3:a:snakeyaml_project:snakeyaml:*:*:*:*:*:*:*:* -> mitigated in snakeyaml v. 1.32 (?)
• CVE-2022-38752 -> cpe:2.3:a:snakeyaml_project:snakeyaml:-:*:*:*:*:*:*:* -> no version range specified

[OrangeDog]

CVE-2022-38751 is still reported for cpe:2.3:a:snakeyaml_project:snakeyaml:1.31:*:*:*:*:*:*:* in dependency-check 7.2.1 even though the NIST data says "Up to (excluding) 1.31".

[chadlwilson]

I think the bigger weirdness is why suppression isn't working here. I was able to suppress fine in one Gradle groovy project but couldn't in a different Kotlin one with detekt. Didn't dig into why, but seems a bug somehwere with the suppressions.

As to the wider question, you can normally use skipConfigurations to skip plugin related dependencies where those plugins define a configuration (e.g detekt) if you are only concerned with things that affect the built artifacts.

[OrangeDog]

why suppression isn't working here

This suppression as been working fine for me:

<suppression>
  <note>Not parsing user input with snakeyaml</note>
  <cve>CVE-2022-38751</cve>
  <cve>CVE-2022-38752</cve>
</suppression> 

[chadlwilson]

Yeah, as I mentioned, an identical suppression rule is working fine on one project but not another so there must be something specific to the Gradle project, plugin or configuration that is preventing the suppressions from working in some cases.

FWIW 38751 isn't being reported on 1.31 from NVD CVE data now, so perhaps you had/have cached data at the time. Hopefully they fix affected versions for 38752 soon.

[EugenMayer]

For me, also 1.33 is still detected as being affected by CVE-2022-38752

Using 7.2.1 / snakeyaml 1.33 / scanning via mvn

snakeyaml-1.33.jar (pkg:maven/org.yaml/[email protected], cpe:2.3:a:snakeyaml_project:snakeyaml:1.33:*:*:*:*:*:*:*, cpe:2.3:a:yaml_project:yaml:1.33:*:*:*:*:*:*:*) : CVE-2022-38752

Interestingly, scanning via gradle i'am not confronted with this false positive. Not sure what i should think of it.

[chadlwilson]

@EugenMayer assuming you have confirmed it is coming from NVD rather than, say, OSSIndex could it be NVD cached data being different between your mvn and Gradle examples? Fix version for 38752 was only corrected to 1.32 in NVD a few days ago.

[EugenMayer]

@chadlwilson i would not say i confirmed that, sorry. I would rather say i'am not even sure how. I ensured to wipe the CI cache / local cache to have a clean scan with refreshed indexes. But i'am not sure this is what you asked for.

I'am not yet DependencyCheck bullet proof so there is a good chance i did miss something that is needed by protocol - if so, please bear with me.

So by https://nvd.nist.gov/vuln/detail/CVE-2022-38752 - which is what i checked, versions from 1.32 should no longer be affected. This is what i checked, but i cannot confirm that this actually is my result, hence the notice here. Anything i did wrong?

[jeremylong]

I have not looked at this specific issue - however, the question around suppressing items that are not actually part of the build artifacts may come down to not scanning specific configurations in gradle. See https://jeremylong.github.io/DependencyCheck/dependency-check-gradle/configuration.html for skipConfigurations and scanConfigurations.

[chadlwilson]

@chadlwilson i would not say i confirmed that, sorry. I would rather say i'am not even sure how. I ensure to wipe the CI cache / local cache to have a clean scan with refreshed indexes. But i'am not sure this is what you asked for.

@EugenMayer Not sure if your setup would allow the cache to be retained across builds, but you could try mvn dependency-check:purge per the docs. I cant recall the location that the mvn plugin caches the NVD data. If you don't override cveValidForHours to a larger cache number (4 hours by default), and there is nothing retained in your env across attempts.

So by https://nvd.nist.gov/vuln/detail/CVE-2022-38752 - which is what i checked, versions from 1.32 should no longer be affected. This is what i checked, but i cannot confirm that this actually is my result, hence the notice here. Anything i did wrong?

IIRC the text report output doesn't clarify which component of dependency check is complaining about a given issue. Could be OSSIndex, could be NVD... or others. Since OSSIndex and NVD both typically refer to Java vulnerabilities via their CVE identifier, I don't think the output above doesn't tell you where the false positive is coming from. You can confirm that from the full HTML report. Usually I look at the suggested suppression fragment to determine, as OSSIndex ones will have <vulnerabilityName> instead of <cve> in the suppression fragment, but there might be a smarter way.

The reason I suggest checking is that sometimes the same false positive is coming from two datasources, and the suppression rule needs to be adjusted to reflect that (and this issue is about suppressions not working, although likely has several possible root causes different to the one being discussed here regarding detekt as a Gradle plugin).

[EugenMayer]

Here is the full screenshot of the HTML report:

I guess the part

CVE-2022-38752 (OSSINDEX)  suppress

I what you are looking for, seems like the OSSINDEX is the cause.

I ran mvn dependency-check:purge and then ran mvn verify again and it failed the same way (and i have seen it downloading all the indexes for the usual long time).

Does this help?

[chadlwilson]

@EugenMayer As the docs indicate, only NVD data is cached. So purging it won't help if the issue is OSSIndex. You'll have to suppress until https://github.com/OSSIndex/vulns/issues/328 is addressed. Anyway, CVE-2022-38752 currently comes up via OSSINDEX with 1.33 on Gradle for me, so if it's not appearing for you there must be something different in your setup between Maven and Gradle. In any case it doesn't sound like your issue has anything to do with this specific problem with Dekekt and Gradle. I believe this is supposed to be about suppression not working in some cases, not about false positives per se.

[chadlwilson]

As to the root problem here, it's possible to have something very strange going on. It seems like in some cases Dependency Check or its Gradle plugin is not actually updating when there are any updates to the suppression file, so when one adds suppressions it doesn't see them and it seems like it's not working and keeps using the old values.

Not sure if that is what was going on here, but I can't replicate exactly the same issue I was having with detekt now; but did get something similar happening with changes to suppressions seemingly being ignored. I seemed to be able to fix it by removing the local .gradle folder and trying again. 🤷‍♂️

[EugenMayer]

@EugenMayer As the docs indicate, only NVD data is cached. So purging it won't help if the issue is OSSIndex. You'll have to suppress until OSSIndex/vulns#328 is addressed. Anyway, CVE-2022-38752 currently comes up via OSSINDEX with 1.33 on Gradle for me, so if it's not appearing for you there must be something different in your setup between Maven and Gradle. In any case it doesn't sound like your issue has anything to do with this specific problem with Dekekt and Gradle. I believe this is supposed to be about suppression not working in some cases, not about false positives per se.

I was entirely unware of https://github.com/OSSIndex/vulns/issues/328 and the entire existence of OSSindex as a second source. Thank you for bringing this up, helped me a lot.

Suppressing is not an issue, my point here was, that i was not expecting to be in need of an suppression - now i know better. Next time i check OSSindex in addition before posting FUD. Sorry!