Right, forging CVEs may be a serious problem, thanks for bringing this up. > On 15. Mar 2022, at 13:41, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > 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 >> >>
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
