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 <enge...@apache.org> Date: Friday, 3. May 2024 at 14:28 To: security-disc...@community.apache.org <security-disc...@community.apache.org> Cc: Tomcat Users List <users@tomcat.apache.org> 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 <jan.von.loewenst...@sap.com.invalid> 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) > <thomas.hoffm...@speed4trade.com.INVALID> > Date: Monday, 15. April 2024 at 13:14 > To: Tomcat Users List <users@tomcat.apache.org> > 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%7C7c65d1d7e6434f1ac5bb08dc6b6c81fd%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638503360979650241%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2BVLXTSlKQJX3aN0ZrnNzHEOdn8oYX%2FHN9CX8Mndhab0%3D&reserved=0<https://osv.dev/> > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fosv.dev%2F&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7C7c65d1d7e6434f1ac5bb08dc6b6c81fd%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638503360979654988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=85MGKcbsLM6hxWtFtqxC02to%2BPJrHM67Jdz7wvvD%2Bm4%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%7C7c65d1d7e6434f1ac5bb08dc6b6c81fd%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638503360979658965%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=WtRls3zaNGC71qGOle85hsmxoNYGkYoq6vWY4zI3yPM%3D&reserved=0<https://github.com/package-url/purl-> > > 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%7C7c65d1d7e6434f1ac5bb08dc6b6c81fd%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638503360979662764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2FEwEMc6J0JWmOj7P0C3%2F9w6VbwhphBZxpnt%2BuKwlRQ0%3D&reserved=0<https://lists.apache.org/thread/7hs5ooqhfozmhlvq24k5xztzn1nwp9yv> > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2F7hs5ooqhfozmhlvq24k5xztzn1nwp9yv&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7C7c65d1d7e6434f1ac5bb08dc6b6c81fd%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638503360979666995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=pz3fp9P6yjfKYHrzrSpGpLZ14zL3EnEPRURHu2VIC2I%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%7C7c65d1d7e6434f1ac5bb08dc6b6c81fd%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638503360979670871%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=nrGEJLopVLC9EG72BtvwP6QQiSnIK8KDn0cOepDJMwU%3D&reserved=0')%20and%20product%20manufacturers<https://medium.com/@interlynkblog/eu-cra-and-sbom-5100c55752fa#:~:text=The%20CRA%20text%20implies%20that,regulators> > < > 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%7C7c65d1d7e6434f1ac5bb08dc6b6c81fd%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638503360979674943%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zfcEMCbwtjKGdHDQimYecXt8YdcoB%2BrivJNTTBRQpLo%3D&reserved=0<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 > -- Arnout Engelen ASF Security Response Apache Pekko PMC member, ASF Member NixOS Committer Independent Open Source consultant
