FP CVEs since 12.1.8 when using a proxy for Maven Central

[Schmidor]

Since an update to 12.1.8 we are getting false positives on org.openjfx:javafx-* dependencies with a classifier when using a Sonatype Proxy for libraries from maven-central.

• the reported CVEs are related to openjdk, but only for older versions
• using maven-central directly does not report any CVE
• using the dependency without a classifier does not report any CVE
• using 12.1.6 or older does not report any CVE

Debug log using a Sonatype Proxy with reported false positives:
sonatypeproxy.txt
Debug log using maven central, without the false positives:
mavencentral.txt

This might be related to

buildscript{
  repositories {
        maven { url = "https://plugins.gradle.org/m2/" }
  }
  dependencies {
        classpath 'org.owasp:dependency-check-gradle:12.1.8'
  }
}

plugins {
  id 'java'
  id 'eclipse'
}

apply plugin: 'org.owasp.dependencycheck'

repositories {
  maven {
  	url = 'https://..../repository/maven-central/'
  }
}

dependencies {
  ext.jfxVersion = '25'
  implementation "org.openjfx:javafx-base:${jfxVersion}:win"
  implementation "org.openjfx:javafx-controls:${jfxVersion}:win"
  implementation "org.openjfx:javafx-graphics:${jfxVersion}:win"
  implementation "org.openjfx:javafx-media:${jfxVersion}:win"
  implementation "org.openjfx:javafx-swing:${jfxVersion}:win"
  implementation "org.openjfx:javafx-web:${jfxVersion}:win"
}

dependencyCheck {
    failBuildOnCVSS = 6
    failOnError = true
    nvd{
      datafeedUrl = '...'
    }
    analyzers {
      assemblyEnabled=false
      ossIndex.username = "..."
      ossIndex.password = "..."
    }
}

[chadlwilson]

12.1.7 disabled retrieval of POMs directly from Maven Central, preferring to use whichever POMs that Gradle has available, and resolving using Gradle-defined repos/libraries. That should have made the plugin start resolving from your proxy, rather than going out directly to Maven Central via the Central Analyzer

https://github.com/dependency-check/dependency-check-gradle/releases/tag/v12.1.7

it may be that

• the classifier is causing the POMs to not be found via your proxy with the new logic
• that even earlier with 12.1.6 you were relying on the default value of analyzers.centralEnabled = true to look up POMs separately directly initiated from ODC You may want to try re-enable this and see if the FPs go away

I'm not sure why that wouldn't be working with your proxy, but do you have a debug log with 12.1.6 with your proxy turned on we can compare to see where it was getting the additional metadata from? (needed to avoid FPs)

[Schmidor]

We are using centralEnabled=true, but that didn't make a difference, so I had it excluded from the example.

this is with our proxy, 12.1.6 and "centralEnabled" not explicitely set, no FP:
sonatypeproxy_12.1.6.txt
and using out proxy, 12.1.8 and "centralEnabled = true", with FP:
sonatypeproxa+centralEnabled_12.1.8.txt

[chadlwilson]

dependency-check-gradle doesn't really support variants properly, so it may be related to that, but in the debug log for 12.1.8 I'd expect to see POM resolution failed or Resolved POM for or Could not find dependency in one or other of the logs - but none of that is there, which probably means it is not trying to resolve it via Gradle, which makes me suspect this line:

dependency-check-gradle/src/main/groovy/org/owasp/dependencycheck/gradle/tasks/AbstractAnalyze.groovy

Line 675 in 93551e7

if (!project.gradle.startParameter.offline && deps != null && deps.size() == 1) {

or this line

dependency-check-gradle/src/main/groovy/org/owasp/dependencycheck/gradle/tasks/AbstractAnalyze.groovy

Line 678 in 93551e7

if (compId instanceof ModuleComponentIdentifier) {

Not quite sure why it'd work differently when talking to Maven Central though; unless there is something different about cached information you have.

[chadlwilson]

Are you running with a "clean" build environment between each attempt? Reason I ask is that they seem to be seeing different sets of files between some runs.

Running 12.1.8 with Maven Central

• it seemed to not discover any archives/jars to scan, so it is not looking inside some of the jars that might have nested jars
• this means it scanned fewer dependencies, and thus possibly no FPs as a result - rather than anything being "fixed" by using Maven Central
• you might want to ensure you are comparing like-with-like? In particular you might want to compare the # of dependencies scanned between the HTML reports of each to check there is the same scan set.

It'd help if you can specifically share the HTML report or something that contains the summary of the dependencies with alleged FPs and the metadata. In particular need to see the CVEs, the package URLs and the CPEs matched as if with a normal FP report. You could use https://github.com/dependency-check/DependencyCheck/issues/new/choose as a reference for what we'd normally need.

Then we can evaluate whether it is actually

1. FPs due to insufficient metadata (12.1.8 plugin is not looking up something it used to be able to)
2. FPs due to actually improving dependency metadata with 12.1.8 - but exposing a different FP issue with the core project we might need to address rather than a specific plugin issue
   • On 12.1.6 with your proxy, I see a lot of Artifact not found in repository: 'javafx-graphics-25-win.jar. This means it could not enrich with metadata so it has a lot less information to go off. Sometimes that leads to FPs but sometimes that decreases FPs.
   • On 12.1.8 with your proxy, I instead see a lot of Resolved POM for org.openjfx:javafx-graphics:25: which is the new logic finding the metadata via Gradle and your proxy. This is generally a good thing.

After looking through further, I suspect at this stage the plugin is working broadly as expected and we may just need to add some suppressions to stop it matching the openjdk CPEs.

[Schmidor]

There is a big difference in the scanned "vulnerability IDs" in the report.

dependency-check-report-12.1.8.html
dependency-check-report-12.1.6.html

Unfortunately, I think the CVEs which affect OpenJFX are not matched to the maven coordinates, e.g. the CVEs from the last Oracle Security Advisory https://openjdk.org/groups/vulnerability/advisories/2025-07-15 CVE-2025-27113 and CVE-2025-24855 are not reported against versions <=24.0.1
As OpenJDK and OpenJFX are released together and Oracle reports those as different subcompontents of the JDK (at least in the advisory), matching those should be okay if the version ranges are correct. So the issue might not be detecting those CVEs for OpenJFX in the first place, but reporting the current version still as vulnerable.

[chadlwilson]

There are no relevant CPEs in those NVD entries so no possible way they can be matched unless OSS Index has them mapped to the specific maven artifacts.

When a native component has a vuln and that is included in a Java jar it needs sophisticated analysis/mapping to get reported against the additional 'products' and the NVD has well publicized problems keeping up at the moment (and funding that might dry up in 6 months).

I'll take another look tomorrow and see if there is anything that can be reasonably done here to address the FPs without creating a risk of false negatives.

[chadlwilson]

There is a big difference in the scanned "vulnerability IDs" in the report.

dependency-check-report-12.1.8.html dependency-check-report-12.1.6.html

Yes, your report confirms you are mainly getting more FPs because there is much more metadata - now you have all the source=pom metadata and ODC now understands that javafx/openjfx has a close relationship to openjdk based on the vendor and product data in the "Evidence" section.

However, what is weird, is that the version number 25 is not inside the CPE / vulnerability IDs, which is mostly what is causing the FPs - it should know the version is 25. This might be a bug somewhere in Core ODC, so I'll move this entry there.

CVE / CPE analysis

The CVEs mentioned in the OpenJFX risk matrix entries are a bit confusing, as many seem to bear little relation to OpenJFX itself - including some MacOS vulns. I suspect they are reporting issues that affect OpenJFX, even if they are not directly from OpenJFX itself. Most of the NVD entries have not been properly enriched to include the OpenJFX "affected configurations" which is normally in a separate section to distinguish between the directly affected software, and transitive consumers that are confirmed affected.

Issues affecting OpenJFX but not directly in OpenJFX

• https://nvd.nist.gov/vuln/detail/CVE-2021-3517
  • marked against cpe:2.3:a:oracle:openjdk:8:update301:*:*:*:*:*:* configuration

Issues directly affecting OpenJFX

• https://nvd.nist.gov/vuln/detail/CVE-2023-22043
  • marked against specifically the Oracle JDK: cpe:2.3:a:oracle:jdk:1.8.0:update371:*:*:-:*:*:* (sigh, openjdk vs jdk - NVD are nothing but inconsistent)
  • marked against specifically the Oracle JDK: cpe:2.3:a:oracle:jre:1.8.0:update371:*:*:-:*:*:*
• https://nvd.nist.gov/vuln/detail/CVE-2020-14664
  • marked against cpe:2.3:a:oracle:jdk:1.8.0:update251:*:*:*:*:*:* and cpe:2.3:a:oracle:jre:1.8.0:update251:*:*:*:*:*:* again

What I conclude from this, is that we probably cannot suppress the oracle:openjdk, oracle:jdk or oracle:jre CPEs, but we could probably suppress ones other than these.

cpe:2.3:a:oracle:javafx
cpe:2.3:a:oracle:openjdk

Unfortunately, that won't fix most of the FPs from old openjdk versions, so first we need to look at why the first issue with version numbers is happening.

However, even if we fix that issue, since the OpenJFX releases are less frequent than the jdk releases, you may still get FPs from the JDK itself which we might not be able to do much about (while relying on NVD) without creating a risk of false negatives. Let's see.