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 <enge...@apache.org> 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 > <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%7Cb85c9c7b0ef84a12888a08dc5d3d36f8%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638487764973925741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C40000%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%7C40000%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%7C40000%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%7C40000%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 > > > > > -- > Arnout Engelen > ASF Security Response > Apache Pekko PMC member, ASF Member > NixOS Committer > Independent Open Source consultant --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
