Re: Package URLs for Apache Tomcat distributions

[von Loewenstein, Jan]

Hi,

I think in the end it boils down to something very simple (and probably very 
complicated from another perpsective 😉): Can the id of a piece of software be 
used to find vulnerabilities?

In the context of this mailing list and the example you brought up with 
defaulting to pkg:maven, the important question is: Will a security reseacher 
finding a vulnerability in e.g. the catalina.sh script - that’s probably not 
published to Maven Central (?) – report this against 
pkg:maven/org.apache.tomcat/tomcat, which points to artefacts that are 
published to Maven Central?

Best regards
Jan

From: Arnout Engelen 
Date: Friday, 3. May 2024 at 14:28
To: security-disc...@community.apache.org 

Cc: Tomcat Users List 
Subject: Re: Package URLs for Apache Tomcat distributions
[You don't often get email from enge...@apache.org. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

Thanks for bringing this up! The topic of software (artifact)
identification is indeed a tricky one. CPEs have long been the main
contender, but are not great for the SBOM (and 'vulnerability scanning'
based on SBOMs) use case because CPE allocations need through the NVD CPE
team, and generally are only allocated when the project has its first CVE
vulnerability advisory.

Indeed purl's seem like a promising candidate. The use of several 'purl
types' and piggy-backing on existing popular distribution mechanisms help
it scale.

A possible limitation of having the different 'purl types' is that a single
piece of software may have a name in different namespaces: if a
vulnerability is found in Tomcat, should its advisory refer to
"pkg:github/apache/tomcat", or "pkg:maven/org.apache.tomcat/tomcat", or a
to-be-introduced "apache" or "asf" type? All of them? Should there be a
database of "equivalences" or similar relationships between purls for the
same software under different types?

I've actually prototyped an approach for an 'asf' purl type based on an
Apache identifier registry in
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fddl2lnm2mbm0vm62yxlwyh3cbv47wyr7&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7C7c65d1d7e6434f1ac5bb08dc6b6c81fd%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638503360979632497%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2BPSnqhRXL7gKYvmbCT5N3kuTX0x1stgLMDjWYztx5Hs%3D&reserved=0<https://lists.apache.org/thread/ddl2lnm2mbm0vm62yxlwyh3cbv47wyr7>.
 However,
that somewhat goes against the purl design where the purl can ideally be
'inferred from context' rather than explicitly 'defined'. For example for
artifacts that are typically published to Maven Central, it currently
doesn't seem to be the convention to use any other purl type: the CycloneDX
Maven plugin pretty much hard-codes the 'maven' type (
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCycloneDX%2Fcyclonedx-maven-plugin%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fjava%2Forg%2Fcyclonedx%2Fmaven%2FDefaultModelConverter.java%23L147&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7C7c65d1d7e6434f1ac5bb08dc6b6c81fd%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638503360979642858%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=7enw%2FbIYob1koLI8BvvdGpZzUuZQqnZVd8g8gg7%2FgPM%3D&reserved=0)<https://github.com/CycloneDX/cyclonedx-maven-plugin/blob/master/src/main/java/org/cyclonedx/maven/DefaultModelConverter.java#L147>.
Should we then not have an 'apache'/'asf' type at all? Or only for
artifacts that cannot be described using any other type? Or for all
artifacts, making an 'equivalences database' a mandatory part of any
vulnerability scanner?


Kind regards,

Arnout

On Mon, Apr 15, 2024 at 2:20 PM von Loewenstein, Jan
 wrote:

> Hi all,
>
> I recently started a discussion about pURLs as package identifier on the
> Tomcat mailing list and it was brought up, that this might be a broader
> topic to be discussed here.
>
> Best regards
> Jan
>
> From: Thomas Hoffmann (Speed4Trade GmbH)
> 
> Date: Monday, 15. April 2024 at 13:14
> To: Tomcat Users List 
> Subject: AW: Package URLs for Apache Tomcat distributions
> [You don't often get email from thomas.hoffm...@speed4trade.com.invalid.
> Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> > On 11/04/2024 16:52, von Loewenstein, Jan wrote:
> > > Hi folks,
> > >
> > > I am part of the Paketo community, and we are providing Cloud Native
> > Buildpacks to create container images with – amongst other technologies –
> > Apache Tomcat and Apache TomEE as application runtimes.

Re: Package URLs for Apache Tomcat distributions

[Lars Francke]

Just as an FYI that we established an official TG (Task Group) for
PURL in yesterdays Ecma TC54 (CycloneDX) meeting:
https://docs.google.com/document/d/1BkBd4PRhpP_u1WO_GueYB89vehT_HPKgFMMfbTuKWV4/edit#heading=h.si64e7edhupe
This will take a bit to get set up but this may be something some
people here may be interested in participating in?

Cheers,
Lars

On Fri, May 3, 2024 at 2:28 PM Arnout Engelen  wrote:
>
> Thanks for bringing this up! The topic of software (artifact)
> identification is indeed a tricky one. CPEs have long been the main
> contender, but are not great for the SBOM (and 'vulnerability scanning'
> based on SBOMs) use case because CPE allocations need through the NVD CPE
> team, and generally are only allocated when the project has its first CVE
> vulnerability advisory.
>
> Indeed purl's seem like a promising candidate. The use of several 'purl
> types' and piggy-backing on existing popular distribution mechanisms help
> it scale.
>
> A possible limitation of having the different 'purl types' is that a single
> piece of software may have a name in different namespaces: if a
> vulnerability is found in Tomcat, should its advisory refer to
> "pkg:github/apache/tomcat", or "pkg:maven/org.apache.tomcat/tomcat", or a
> to-be-introduced "apache" or "asf" type? All of them? Should there be a
> database of "equivalences" or similar relationships between purls for the
> same software under different types?
>
> I've actually prototyped an approach for an 'asf' purl type based on an
> Apache identifier registry in
> https://lists.apache.org/thread/ddl2lnm2mbm0vm62yxlwyh3cbv47wyr7. However,
> that somewhat goes against the purl design where the purl can ideally be
> 'inferred from context' rather than explicitly 'defined'. For example for
> artifacts that are typically published to Maven Central, it currently
> doesn't seem to be the convention to use any other purl type: the CycloneDX
> Maven plugin pretty much hard-codes the 'maven' type (
> https://github.com/CycloneDX/cyclonedx-maven-plugin/blob/master/src/main/java/org/cyclonedx/maven/DefaultModelConverter.java#L147).
> Should we then not have an 'apache'/'asf' type at all? Or only for
> artifacts that cannot be described using any other type? Or for all
> artifacts, making an 'equivalences database' a mandatory part of any
> vulnerability scanner?
>
>
> Kind regards,
>
> Arnout
>
> On Mon, Apr 15, 2024 at 2:20 PM von Loewenstein, Jan
>  wrote:
>
> > Hi all,
> >
> > I recently started a discussion about pURLs as package identifier on the
> > Tomcat mailing list and it was brought up, that this might be a broader
> > topic to be discussed here.
> >
> > Best regards
> > Jan
> >
> > From: Thomas Hoffmann (Speed4Trade GmbH)
> > 
> > Date: Monday, 15. April 2024 at 13:14
> > To: Tomcat Users List 
> > Subject: AW: Package URLs for Apache Tomcat distributions
> > [You don't often get email from thomas.hoffm...@speed4trade.com.invalid.
> > Learn why this is important at
> > https://aka.ms/LearnAboutSenderIdentification ]
> >
> > > On 11/04/2024 16:52, von Loewenstein, Jan wrote:
> > > > Hi folks,
> > > >
> > > > I am part of the Paketo community, and we are providing Cloud Native
> > > Buildpacks to create container images with – amongst other technologies –
> > > Apache Tomcat and Apache TomEE as application runtimes.
> > > >
> > > > One of the features of Cloud Native Buildpacks is that images come with
> > > Software-Bill-of-Material. When installing Apache Tomcat, we issue the
> > > following CPE and pURL to the SBOM:
> > > >
> > > >1.  cpe:2.3:a:apache:tomcat:10.1.20:*:*:*:*:*:*:*
> > > >2.  pkg:generic/apache-tomcat@10.1.20
> > > >
> > > > The former should be the right one for users to find relevant CVEs in
> > > > e.g. the nvd.nist.gov. The latter however is made up and will likely
> > > > not lead to any findings on e.g.
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fosv.dev%2F&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7Cb85c9c7b0ef84a12888a08dc5d3d36f8%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638487764973925741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4%7C%7C%7C&sdata=THsJsmmmf%2BYnOFsfX2ET%2B9qosC%2F3%2BTmn73piJBppidA%3D&reserved=0
> > <https://osv.dev/>
> > > >
> > > > Now I am wondering if you report Tomca

Re: Package URLs for Apache Tomcat distributions

[Arnout Engelen]

Thanks for bringing this up! The topic of software (artifact)
identification is indeed a tricky one. CPEs have long been the main
contender, but are not great for the SBOM (and 'vulnerability scanning'
based on SBOMs) use case because CPE allocations need through the NVD CPE
team, and generally are only allocated when the project has its first CVE
vulnerability advisory.

Indeed purl's seem like a promising candidate. The use of several 'purl
types' and piggy-backing on existing popular distribution mechanisms help
it scale.

A possible limitation of having the different 'purl types' is that a single
piece of software may have a name in different namespaces: if a
vulnerability is found in Tomcat, should its advisory refer to
"pkg:github/apache/tomcat", or "pkg:maven/org.apache.tomcat/tomcat", or a
to-be-introduced "apache" or "asf" type? All of them? Should there be a
database of "equivalences" or similar relationships between purls for the
same software under different types?

I've actually prototyped an approach for an 'asf' purl type based on an
Apache identifier registry in
https://lists.apache.org/thread/ddl2lnm2mbm0vm62yxlwyh3cbv47wyr7. However,
that somewhat goes against the purl design where the purl can ideally be
'inferred from context' rather than explicitly 'defined'. For example for
artifacts that are typically published to Maven Central, it currently
doesn't seem to be the convention to use any other purl type: the CycloneDX
Maven plugin pretty much hard-codes the 'maven' type (
https://github.com/CycloneDX/cyclonedx-maven-plugin/blob/master/src/main/java/org/cyclonedx/maven/DefaultModelConverter.java#L147).
Should we then not have an 'apache'/'asf' type at all? Or only for
artifacts that cannot be described using any other type? Or for all
artifacts, making an 'equivalences database' a mandatory part of any
vulnerability scanner?


Kind regards,

Arnout

On Mon, Apr 15, 2024 at 2:20 PM von Loewenstein, Jan
 wrote:

> Hi all,
>
> I recently started a discussion about pURLs as package identifier on the
> Tomcat mailing list and it was brought up, that this might be a broader
> topic to be discussed here.
>
> Best regards
> Jan
>
> From: Thomas Hoffmann (Speed4Trade GmbH)
> 
> Date: Monday, 15. April 2024 at 13:14
> To: Tomcat Users List 
> Subject: AW: Package URLs for Apache Tomcat distributions
> [You don't often get email from thomas.hoffm...@speed4trade.com.invalid.
> Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> > On 11/04/2024 16:52, von Loewenstein, Jan wrote:
> > > Hi folks,
> > >
> > > I am part of the Paketo community, and we are providing Cloud Native
> > Buildpacks to create container images with – amongst other technologies –
> > Apache Tomcat and Apache TomEE as application runtimes.
> > >
> > > One of the features of Cloud Native Buildpacks is that images come with
> > Software-Bill-of-Material. When installing Apache Tomcat, we issue the
> > following CPE and pURL to the SBOM:
> > >
> > >1.  cpe:2.3:a:apache:tomcat:10.1.20:*:*:*:*:*:*:*
> > >2.  pkg:generic/apache-tomcat@10.1.20
> > >
> > > The former should be the right one for users to find relevant CVEs in
> > > e.g. the nvd.nist.gov. The latter however is made up and will likely
> > > not lead to any findings on e.g.
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fosv.dev%2F&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7Cb85c9c7b0ef84a12888a08dc5d3d36f8%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638487764973925741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4%7C%7C%7C&sdata=THsJsmmmf%2BYnOFsfX2ET%2B9qosC%2F3%2BTmn73piJBppidA%3D&reserved=0
> <https://osv.dev/>
> > >
> > > Now I am wondering if you report Tomcat vulnerabilities under any pURL
> and
> > which one that would be.
> >
> > We don't.
> >
> > > There is a proposal<
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpackage-url%2Fpurl-&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7Cb85c9c7b0ef84a12888a08dc5d3d36f8%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638487764973934423%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4%7C%7C%7C&sdata=qob5tUw6pGi%2F3crVP%2BlA%2BSqiAo4I2vWTMArkC%2F4%2BtXc%3D&reserved=0
> > spec/blob/master/PURL-TYPES.rst#other-candidate-types-to-define> to
> > introduce `pkg:apache` as a namespace, which would open up
> > `pkg:apache/tomcat@10.1.20` as a canonical pURL.
&g

Re: Package URLs for Apache Tomcat distributions

[von Loewenstein, Jan]

Hi all,

I recently started a discussion about pURLs as package identifier on the Tomcat 
mailing list and it was brought up, that this might be a broader topic to be 
discussed here.

Best regards
Jan

From: Thomas Hoffmann (Speed4Trade GmbH) 

Date: Monday, 15. April 2024 at 13:14
To: Tomcat Users List 
Subject: AW: Package URLs for Apache Tomcat distributions
[You don't often get email from thomas.hoffm...@speed4trade.com.invalid. Learn 
why this is important at https://aka.ms/LearnAboutSenderIdentification ]

> On 11/04/2024 16:52, von Loewenstein, Jan wrote:
> > Hi folks,
> >
> > I am part of the Paketo community, and we are providing Cloud Native
> Buildpacks to create container images with – amongst other technologies –
> Apache Tomcat and Apache TomEE as application runtimes.
> >
> > One of the features of Cloud Native Buildpacks is that images come with
> Software-Bill-of-Material. When installing Apache Tomcat, we issue the
> following CPE and pURL to the SBOM:
> >
> >1.  cpe:2.3:a:apache:tomcat:10.1.20:*:*:*:*:*:*:*
> >2.  pkg:generic/apache-tomcat@10.1.20
> >
> > The former should be the right one for users to find relevant CVEs in
> > e.g. the nvd.nist.gov. The latter however is made up and will likely
> > not lead to any findings on e.g. 
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fosv.dev%2F&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7Cb85c9c7b0ef84a12888a08dc5d3d36f8%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638487764973925741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4%7C%7C%7C&sdata=THsJsmmmf%2BYnOFsfX2ET%2B9qosC%2F3%2BTmn73piJBppidA%3D&reserved=0<https://osv.dev/>
> >
> > Now I am wondering if you report Tomcat vulnerabilities under any pURL and
> which one that would be.
>
> We don't.
>
> > There is a 
> > proposal<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpackage-url%2Fpurl-&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7Cb85c9c7b0ef84a12888a08dc5d3d36f8%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638487764973934423%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4%7C%7C%7C&sdata=qob5tUw6pGi%2F3crVP%2BlA%2BSqiAo4I2vWTMArkC%2F4%2BtXc%3D&reserved=0
> spec/blob/master/PURL-TYPES.rst#other-candidate-types-to-define> to
> introduce `pkg:apache` as a namespace, which would open up
> `pkg:apache/tomcat@10.1.20` as a canonical pURL.
>
> That is a foundation wide decision and not one the Tomcat project can make
> unilaterally. That is probably a topic for security-
> disc...@community.apache.org where pURL has already been touched on this
> thread:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2F7hs5ooqhfozmhlvq24k5xztzn1nwp9yv&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7Cb85c9c7b0ef84a12888a08dc5d3d36f8%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638487764973940781%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4%7C%7C%7C&sdata=GxRiFt2Dwk74ykwVxLf0rE9DItO2cnyg5u5nZ8%2Fr0%2Fs%3D&reserved=0<https://lists.apache.org/thread/7hs5ooqhfozmhlvq24k5xztzn1nwp9yv>
>
> Mark

This topic might get even more important when the cyber resilience act of the 
European Union will be released.
Software manufacturers will be obliged to provide an inventory / SBOM list.
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F%40interlynkblog%2Feu-cra-and-sbom-5100c55752fa%23%3A~%3Atext%3DThe%2520CRA%2520text%2520implies%2520that%2Cregulators&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7Cb85c9c7b0ef84a12888a08dc5d3d36f8%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638487764973945572%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4%7C%7C%7C&sdata=3SaPhtmEDR1Dsf8l5f9zZo7UMfqCpelZIgC9Bl%2FgO9o%3D&reserved=0')%20and%20product%20manufacturers<https://medium.com/@interlynkblog/eu-cra-and-sbom-5100c55752fa#:~:text=The%20CRA%20text%20implies%20that,regulators>.



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

AW: Package URLs for Apache Tomcat distributions

[Thomas Hoffmann (Speed4Trade GmbH)]

 
> On 11/04/2024 16:52, von Loewenstein, Jan wrote:
> > Hi folks,
> >
> > I am part of the Paketo community, and we are providing Cloud Native
> Buildpacks to create container images with – amongst other technologies –
> Apache Tomcat and Apache TomEE as application runtimes.
> >
> > One of the features of Cloud Native Buildpacks is that images come with
> Software-Bill-of-Material. When installing Apache Tomcat, we issue the
> following CPE and pURL to the SBOM:
> >
> >1.  cpe:2.3:a:apache:tomcat:10.1.20:*:*:*:*:*:*:*
> >2.  pkg:generic/apache-tomcat@10.1.20
> >
> > The former should be the right one for users to find relevant CVEs in
> > e.g. the nvd.nist.gov. The latter however is made up and will likely
> > not lead to any findings on e.g. https://osv.dev
> >
> > Now I am wondering if you report Tomcat vulnerabilities under any pURL and
> which one that would be.
> 
> We don't.
> 
> > There is a proposal spec/blob/master/PURL-TYPES.rst#other-candidate-types-to-define> to
> introduce `pkg:apache` as a namespace, which would open up
> `pkg:apache/tomcat@10.1.20` as a canonical pURL.
> 
> That is a foundation wide decision and not one the Tomcat project can make
> unilaterally. That is probably a topic for security-
> disc...@community.apache.org where pURL has already been touched on this
> thread:
> https://lists.apache.org/thread/7hs5ooqhfozmhlvq24k5xztzn1nwp9yv
> 
> Mark

This topic might get even more important when the cyber resilience act of the 
European Union will be released.
Software manufacturers will be obliged to provide an inventory / SBOM list.
https://medium.com/@interlynkblog/eu-cra-and-sbom-5100c55752fa#:~:text=The%20CRA%20text%20implies%20that,regulators')%20and%20product%20manufacturers.
  



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Package URLs for Apache Tomcat distributions

[Mark Thomas]

On 11/04/2024 16:52, von Loewenstein, Jan wrote:

Hi folks,

I am part of the Paketo community, and we are providing Cloud Native Buildpacks 
to create container images with – amongst other technologies – Apache Tomcat 
and Apache TomEE as application runtimes.

One of the features of Cloud Native Buildpacks is that images come with 
Software-Bill-of-Material. When installing Apache Tomcat, we issue the 
following CPE and pURL to the SBOM:

   1.  cpe:2.3:a:apache:tomcat:10.1.20:*:*:*:*:*:*:*
   2.  pkg:generic/apache-tomcat@10.1.20

The former should be the right one for users to find relevant CVEs in e.g. the 
nvd.nist.gov. The latter however is made up and will likely not lead to any 
findings on e.g. https://osv.dev

Now I am wondering if you report Tomcat vulnerabilities under any pURL and 
which one that would be.


We don't.


There is a 
proposal
 to introduce `pkg:apache` as a namespace, which would open up 
`pkg:apache/tomcat@10.1.20` as a canonical pURL.


That is a foundation wide decision and not one the Tomcat project can 
make unilaterally. That is probably a topic for 
security-disc...@community.apache.org where pURL has already been 
touched on this thread:

https://lists.apache.org/thread/7hs5ooqhfozmhlvq24k5xztzn1nwp9yv

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Package URLs for Apache Tomcat distributions

[von Loewenstein, Jan]

Hi folks,

I am part of the Paketo community, and we are providing Cloud Native Buildpacks 
to create container images with – amongst other technologies – Apache Tomcat 
and Apache TomEE as application runtimes.

One of the features of Cloud Native Buildpacks is that images come with 
Software-Bill-of-Material. When installing Apache Tomcat, we issue the 
following CPE and pURL to the SBOM:

  1.  cpe:2.3:a:apache:tomcat:10.1.20:*:*:*:*:*:*:*
  2.  pkg:generic/apache-tomcat@10.1.20

The former should be the right one for users to find relevant CVEs in e.g. the 
nvd.nist.gov. The latter however is made up and will likely not lead to any 
findings on e.g. https://osv.dev

Now I am wondering if you report Tomcat vulnerabilities under any pURL and 
which one that would be.
There is a 
proposal
 to introduce `pkg:apache` as a namespace, which would open up 
`pkg:apache/tomcat@10.1.20` as a canonical pURL.

Thanks for the time to read this.

Best regards
Jan von Löwenstein