Hi, I got a lot of false positives too but wonder why CPE coordinates are not able to use the gavtc coordinates, it sounds easy to do instead of using a bucket for all artifacts. I don't think artifacts should be able to give their own id since it would enable to bypass identified CVE or "steal CVE" for other purposes, but pushing to get a more precise system for CVE identifier sounds like the way to go IMHO.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 15 mars 2022 à 13:26, Sebastian Stenzel <sebastian.sten...@gmail.com> a écrit : > thanks for your fast reply, Brian! > > If I'm not mistaken from a CPE's perspective each published artifact is > its own "product", no matter of whether it's being build as part of a > bigger project. Furthermore the CPEs don't get derived from Maven GAV (and > I would not force-derive anything if the value is omitted). While reverse > domain names are a de facto standard for Maven groupIds, just the 2nd level > domain name is usually used for CPE organizations. Take for example > com.google.guava:guava vs. cpe:2.3:a:google:guava. > > In cases where organization and product name are distinct, there is indeed > not much need to change anything. Difficulties arise when they overlap, > which is more common than one might think at first, e.g. org.apache:apache. > > Now if there is a CVE for a product that carries the same name as the > organization, let's say cpe:2.3:a:postgresql:postgresql, said tools will > report false positives for basically everything that has "postgresql" in > its name, such as the jdbc adapters. This could be avoided, if the jdbc jar > could introduce itself to the analyzer as cpe:2.3:a:postgresql:pgjdbc, so > it doesn't need to guess the library's name. > > > > On 15. Mar 2022, at 12:23, Brian Fox <bri...@infinity.nu> wrote: > > > > 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 > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
