Clarification on CVE Reporting Changes in OWASP Dependency-Check

[pbhuvanacs]

Hi Team,

With reference to this ticket: #8276, we are scanning our project using the following OWASP Dependency-Check Maven command:

mvn org.owasp:dependency-check-maven:13.0.0:aggregate \
  -Danalyzer.bundle.audit.enabled=false \
  -Danalyzer.central.enabled=true

When we ran this scan in June 2026 for our application with the same parameters, the following CVEs were not reported:

• CVE-2019-20445
• CVE-2019-16869
• CVE-2019-10211
• CVE-2019-10127
• CVE-2019-10128
• CVE-2019-10210

However, running the same command now on the same application reports all of the above CVEs.

Could you help us understand the reason for this discrepancy in the scan results between the June 2026 run and the current run?

Additionally, in the latest scan the identifier field is not populated for these CVEs in the OWASP output, which makes it difficult to construct a proper package URL when raising tickets (for example, similar to the approach described in Issue #8276). Any guidance on why the identifiers are missing and how we should proceed would be appreciated.

Thank you in advance for your support.

[chadlwilson]

Can you share an HTML or XML or JSON report? Are investigating false negatives (from June) or false positives (now) ... and for which libraries?

Maybe also want to enable debug logging and see what's logged there for the relevant dependencies. It's possible legacy maven Central Search is down or failing (but wasn't in June) and that is affecting the evidence, but unless you have a report from June to compare it's just speculation.

[pbhuvanacs]

We have attached a CSV report for your review. Since the data is highly sensitive, we have shared only limited information.

Could you please share the steps required to enable debug logging for the relevant dependencies and indicate which log entries we should review?

Initially (first week of august), we received the following error:

"[ERROR] Could not connect to Central search. Analysis failed; disabling Central analyzer"

This error is no longer appearing, but false-positive records are still being populated in the output report.

test 1.csv

[chadlwilson]

Unfortunately CSV report isn’t really good enough because it doesn’t include the evidence details, which is why I specifically asked for html or JSON reports. But will see where can get to with this.

So the extra CVEs are likely being displayed because

• these dependencies are not being matched to package identifiers, so you are not able to benefit from the pre-packaged managed suppressions that ODC comes with, and the matching is relying on (generally less reliable) file metadata, or embedded manifest contents.
• These libraries are produced by their projects using Gradle which does not embed Pom.xml so just having a jar file available is not enough to reliably match to a package identifier
• while you are using maven, you are scanning a zip with embedded jars, not a maven “dependency tree”. In this mode, maven cannot be relied upon to get the metadata, because it only knows about file names for these.

This is likely because Maven Central Search is either not working, or possibly has cached a “not found” result somehow (if you are working from a cache of the ODC data dir).

For example, the first dep is found on Maven Central via the sha in your report, so ODC should be finding it and populating the package url. https://central.sonatype.com/search?q=1:dcd2a47ad513571be7f0dd2a922bf06d&smo=true

To debug further with maven

• run with “-X”, the standard maven debugging mechanism
• check the logged ODC configurations what you expect. Sometimes people get maven config overrides wrong.
• Look for attempts to contact Maven Central Search or via the Sha (search.maven.org, NOT the above domain)
• if you don’t see any remote search attempts or errors but Central Analyzer is definitely showing as running, and you do have a cache locally you might want to try removing the “CENTRAL” cache from your ODC data dir (inside your maven repo by default). I can’t recall if ODC caches failed lookups, but if you see it searching after cache removal and the FPs go away, that might explain it.

Let me know how you go. If it is a “cached failed lookups” problem, we should probably consider changing ODC behaviour to ensure it only caches failed lookups temporarily, or if they are “not found” rather than “error”.