Hi Sebastian, The challenge is that CPE as a coordinate system doesn’t have enough specificity to match artifacts. It has organization/product/version and therefore doesn’t have the ability to capture sub module. This is what leads to most of the mismatch issues seen in CVE based tools (but not all tools have this problem).
Since the coordinates for CPE don’t have enough parts, it’s not clear to me how recording it in the Pom changes anything. Alas if the CPE was coded into the Pom, it almost certainly would be derived from the coordinates anyway and therefore really shouldn’t even have to be repeated. On Tue, Mar 15, 2022 at 7:12 AM Sebastian Stenzel < sebastian.sten...@gmail.com> wrote: > 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 > >
