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
