You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Sebastian Stenzel <se...@gmail.com> on 2022/03/15 11:11:51 UTC
Feature Request: Add CPE String to pom.xml
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature Request: Add CPE String to pom.xml
Posted by Sebastian Stenzel <se...@gmail.com>.
Right, forging CVEs may be a serious problem, thanks for bringing this up.
> On 15. Mar 2022, at 13:41, Romain Manni-Bucau <rm...@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 <se...@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 <br...@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.stenzel@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature Request: Add CPE String to pom.xml
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <se...@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 <br...@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.stenzel@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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Feature Request: Add CPE String to pom.xml
Posted by Sebastian Stenzel <se...@gmail.com>.
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 <br...@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.stenzel@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature Request: Add CPE String to pom.xml
Posted by Brian Fox <br...@infinity.nu>.
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.stenzel@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>