[FP]: CVE-2020-36460 on jakarta.enterprise.lang-model@4.0.1

[azikic]

Package URl

pkg:maven/jakarta.enterprise/jakarta.enterprise.lang-model@4.0.1

CPE

cpe:2.3:a:model_project:model:4.0.1:::::::*

CVE

CVE-2020-36460

ODC Integration

{"label" => "Maven Plugin"}

ODC Version

12.1.9

Description

This vulnerability is for a rust component. I could not find any relation to the mentioned java library.

[github-actions]

Maven Coordinates

<dependency>
   <groupId>jakarta.enterprise</groupId>
   <artifactId>jakarta.enterprise.lang-model</artifactId>
   <version>4.0.1</version>
</dependency>

Suppression rule:

<suppress base="true">
   <notes><![CDATA[
   FP per issue #8176
   ]]></notes>
   <packageUrl regex="true">^pkg:maven/jakarta\.enterprise/jakarta\.enterprise\.lang-model@.*$</packageUrl>
   <cpe>cpe:/a:model_project:model</cpe>
</suppress>

Link to test results: https://github.com/dependency-check/DependencyCheck/actions/runs/19958846389

[chadlwilson]

The automation can't reproduce this when scanning with the Maven plugin. What is your configuration (apart from API keys) set to?

[azikic]

The problem appears with the "jarAnalyzerEnabled" option set to false. I hadn't noticed that before.
I will have to inverstigate why this was done... it kind of defeats the point of using the plugin for java and then disabling the jar-analyzer

I attached a simple example maven project that triggers the behaviour in any case.
8176-test.zip

Should I close this issue?

[chadlwilson]

Let me have a think about it.

Generally speaking I find the jar analyzer makes the results worse (for an existing dependency, known to Maven not something nested inside) rather than better, and strictly speaking you shouldn't need it with the maven plugin unless worried about Uber jars or jars containing code from other languages.

It does not defeat the purpose to disable the jar analyzer with a Maven or Gradle plugin - I think you misunderstand what it does. it essentially looks inside the actual jar for additional context that is not within the jar's POM metadata or the file name. For maven/gradle dependencies, usually that increases the chance of false positives (not decrease it) so need to figure out what has happened here if we want to improve it.

[chadlwilson]

The sad reality right now (my personal opinion) is that this project does create a large number of false positives at the moment for simple token matches that totally should not cause a match (e.g all these generic project names.the 'model'). And the matching can feel increasingly indeterminate. 😓

[azikic]

I am not familiar with the inner workings of dependency-check.

What I noticed is that the reported CPE looks different than the one from the nvd feed:

Source	CPE String
Maven log	cpe:2.3:a:model_project:model:4.0.1:*:*:*:*:*:*:*
NVD Json feed	cpe:2.3:a:model_project:model:*:*:*:*:*:rust:*:*

The language part might be used to categorically exclude any jvm based language from a match. Maybe this is what the jar analyzer contributes?

Source:
https://nvd.nist.gov/feeds/json/cve/2.0/nvdcve-2.0-2020.json.zip

[chadlwilson]

I am not familiar with the inner workings of dependency-check.

Sure, but I am :-) Somewhat.

https://nvd.nist.gov/feeds/json/cve/2.0/nvdcve-2.0-2020.json.zip

The legacy NVD feeds are not used, ODC only uses the API.

The language part might be used to categorically exclude any jvm based language from a match. Maybe this is what the jar analyzer contributes?

ODC doesn't understand the language discriminators from CPEs right now; nor map them to package sources or languages. It's really somewhat non-trivial - there are Ruby dependencies published to Maven data sources, for example - GRPC C++ binaries inside Nuget packages; all sorts of chaos.

A separate issue (somewhere, you can search for it perhaps) from the primary ODC maintainer says that the information isn't available in the right format to consume for ODC from the CVEs. I haven't looked at it myself to understand the problem.

Anyway, that's not super relevant, as many of these generic project names come from CVEs without single language projects without use of the discriminator, so it's not likely the major cause of this. The CPE and CVE data is the same with and without Jar Analyzer.

If you want to infer the real reason for the differences in reporting, you want to look at the "evidence" section in the reports and compare with and without Jar Analyzer enabled. But still involves guessing (and for me, generally looking at the code).

[chadlwilson]

@github-actions approved

[github-actions]

Suppress rule has been added to the generatedSuppressions branch.