Java: Read CPE from MANIFEST

infeo commented 2 years ago

Is your feature request related to a problem?

I'm frustrated by the CPE-detection heuristic. In the context of #4177, instead of supressing we also tried to circumvent the problem by adding more information to the jars (enhance the pom, add infos to manifest), but without any success. As a short term fix, we need to update ~10 projects with a temporary workaround till #4184 is merged.

But just adding FPs to the base surpression file is from my point of view not a long term solution. The more lines it gets, the longer it will take to parse it. And any error in a supression regex can have a big impact.

For Java dependecies, my suggestion is to...

Describe the solution you'd like

...skip the cpe-detection algorithm, if the jar manifest file contains a cpe entry, e.g. cpe: 2.3:a:apache:james:1.4:*:*:*:*:*:*:*.

The manifest is allowed to contain individual/application specific key-value pairs. Since it is read for cpe detection anyways, it could check for the existence of such key, speeding up the process and reduces the false positive rate. Implementation wise, in method https://github.com/jeremylong/DependencyCheck/blob/3d097c4838d21d861753a0ea77cde92af19fac40/core/src/main/java/org/owasp/dependencycheck/analyzer/JarAnalyzer.java#L822, one could check first, if such a key exists and if not, continue with the already existing algorithm.

Further benefits:

build tool agnostic (gradle, maven, etc...) and is based on a known, well defined standard.
reduced maintenance of supression files in downstream libraries.
possibilty, that base supression file can shrink
less work here for checking false positives issues

Describe alternatives you've considered

Supress the false positive in every down stream library: It still creates the evidence and might need further adjusted in future due to other falsys (negative and positive).

Additional context

Example Manifest for mysql-connector-j

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.2
Created-By: 1.8.0_191-b26 (Oracle Corporation)
Built-By: pb2user
Specification-Title: JDBC
Specification-Version: 4.2
Specification-Vendor: Oracle Corporation
Implementation-Title: MySQL Connector/J
Implementation-Version: 8.0.16
Implementation-Vendor-Id: com.mysql
Implementation-Vendor: Oracle
CPE:  2.3:a:oracle:connector/j:5.1.40:*:*:*:*:*:*:*

jeremylong commented 2 years ago

While I'd be totally fine with this - how many maintainers actually put a CPE into the manifest? This appears to be one of those if we build it they will come type scenarios and we might find 1-2 maintainers actually do this?

overheadhunter commented 2 years ago

I agree, as long as there is no official standard to associate CPEs with software artifacts, adoption of some tool-specific standard will probably only be driven by false positives, where library maintainers seek a way of avoiding the "derive CPE from Maven coordinates" heuristic.

A few days back I explained this problem on the Maven mailing list and asked whether it wouldn't make sense to allow library authors to put a designated CPE name into the published artifacts but interest was quite low. The pom.xml format is not supposed to be inflated with values just to implement workarounds in third party tools... Another opinion revolved around the idea that the CPE metadata could be easily forged to sneak in false information. While true, the same is possible with GAV.

I don't know, if they got the bigger picture though. If we assume that SCA tools will become increasingly more important over time (which I firmly believe in), it is only a matter of time until this topic pops up again. The sooner this development gets picked up in artifact metadata, the better. Nevertheless, I don't expect hugely different responses from maintainers of other package formats.

That said, I still believe we do have the chance to establish a de facto standard the "bottom up" way. The proposed Manifest entry would work universally regardless of build tools and will not break anything. Therefore I'd volunteer to be the first maintainer to adopt such a standard. 😉

jeremylong commented 2 years ago

To understand why ODC uses an evidence based approach - the tool started off in 2011/2012 as an auditor tool. At the time, I did not want to create a database of hash/GAV/CPE/CVE. Maintaining a database like this is not something I would enjoy - but it really is the correct approach. We are starting to see data like this available with things like the GitHub Advisory Database. As this type of data becomes more broadly available the need for an evidence based approach is reduced - and may obviate the need for much of the code in ODC.

aikebah commented 2 years ago

In any case - if adopted the format quoted in the OP is plain wrong. If a cpe would be referenced in the manifest or some other metadata it should be a proper representation of a well-formed-name as defined in the CPE standard. There are currently two offically defined string representantions of a 'well-formed-name' (uri and formatted string) and 2.3:a:oracle:connector/j:5.1.40:*:*:*:*:*:*:* is not among them. The proper reference would be

CPE: cpe:2.3:a:oracle:connector/j:5.1.40:*:*:*:*:*:*:*

The value of the metadata attribute should be a proper binding of a well-formed-name (a URI binding could be opted for, but I think the formatted string binding is the easier choice as it is less restrictive on content)

jeremylong / DependencyCheck