Hi, I'm new on this mailing list and this might not be the appropriate place to discuss ideas to extend the pom format, so please redirect me to the right place ;-)
We've recently had a lot of struggles with both false positives and false negatives with a vulnerability scanner, as there is no reliable way to derive a CPE string from Maven dependencies. This is mostly caused by the fact that groupIds and artifactIds can not be literally translated into CPE organization and product strings. In many cases, the product name is also the groupId (e.g. Jetty) with lots of artifacts being published under this groupId. Now a vulnerability in jetty:jetty might not affect jetty:jetty-util, however probabilistic CPE matching algorithms will still report a false positive. Now one could argue that this is a problem of the vulnerability checker (I agree), however the only means they have is changing the confidence threshold (which would cause false negatives, defying the purpose) or maintaining an ever-growing list of false positives. Both are mere workarounds. What could really solve this: Replacing those fuzzy matching algorithms, if there was a reliable way to determine the CPE string from a library. Ideally the library would carry this in its metadata itself. We could add custom properties to the pom.xml or the MANIFEST.MF, but I believe that adoption would benefit if there was an official standard. Given that both published Maven artifacts as well as reported CVEs will only grow over time and the importance of correctly identifying vulnerabilities is no longer denied by anyone (at least not since log4shell), I hope CPE strings will find their place in official package metadata (not only in Maven). Can this be considered in the next pom xsd? Cheers! Sebastian --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
