Venkat,
We are in agreement “I said - it is important for end-to-end security.” IMO, the most important decision that must be made is to agree on a method to ensure uniqueness of Supplier Names. Fortunately we have a built in mechanism in place that already does this with two IANA registered tags: * dns – identifies unique dns domain names that are owned by a legal entity (company or person) * mailto: email addresses are guaranteed to be unique; some open source developers are only identifiable by their email address, I have found. Purl/swid is another good option, but will require mandating the currently optional owner tags that precede the product and version information in a purl/swid identifier. Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™ <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com Email: <mailto:[email protected]> [email protected] Tel: +1 978-696-1788 From: Venkatasubramaniam Ramakrishnan <[email protected]> Sent: Friday, March 29, 2024 11:55 PM To: [email protected] Cc: Gary O'Neall <[email protected]>; [email protected] Subject: Re: [spdx-tech] CISA document on identifiers Hi Dick, Your inputs are valid but come with a lot of IFs. It is tough to follow-through and enforce if the suppliers are doing the right thing. Even with a standard, it would be difficult, but CISA's document talks about reward and penalty for not implementing the naming standard, which is some hope. If we work in SBOM silos, naming may not be a big deal, but considering the end-to-end life cycle from design to vulnerability management and licensing, naming is important to see if we are referring to the same component. Yesterday, Jonathan from CISA presented the naming standard proposal at the EPSS meeting and shared how important naming is. I specifically asked if naming is important for SBOMs, and he replied the same thing I said - it is important for end-to-end security. I would appreciate further inputs. Thanks & Best Regards, Venkat. On Fri, Mar 29, 2024 at 5:18 PM Dick Brooks <[email protected] <mailto:[email protected]> > wrote: Naming is not an issue within SBOM’s so long as the Supplier Name is unique. An SBOM includes a unique product identifier by combining Supplier Name + Package Name + Package Version Each supplier maintains their own unique product name and version namespace. This works perfectly if the Supplier Name is guaranteed to be unique and each supplier manages the uniqueness of their product namespaces. Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™ <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com Email: <mailto:[email protected]> [email protected] Tel: +1 978-696-1788 From: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > On Behalf Of Venkat Ramakrishnan Sent: Friday, March 29, 2024 6:33 AM To: Gary O'Neall <[email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[email protected]> Subject: Re: [spdx-tech] CISA document on identifiers Hi Gary, I'm currently going through the CISA document and noting down my observations. Although the commenting period is over, I was asked to give my feedback on the document by one of the CISA's members. If you or anyone else are interested in looking into this further and potentially give our feedback from SPDX perspective, I am willing to work with them. Naming is so important, and as I understand, it is a major blocking factor for SBOMs/VEXs from being adopted (at least quickly. Otherwise, it may take several years is what I heard). So, it would be worthwhile to spend some time on this. Thanks & Best Regards, Venkat. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> www.avg.com On Fri, Jan 19, 2024 at 1:03 AM Gary O'Neall <[email protected] <mailto:[email protected]> > wrote: One of the proposed solutions for package verification is to use OMNIBor identifiers for verification purposes (see PR #602 <https://github.com/spdx/spdx-3-model/pull/602> for documentation on this approach). Since it relates to identifiers, I thought it might be useful to review the recently release paper on identifiers from CISA <https://www.cisa.gov/sites/default/files/2023-10/Software-Identification-Ecosystem-Option-Analysis-508c.pdf> – there is a request for comment. Note that the goal of the paper seems focused on the correlation of package artifacts with vulnerability management systems. There are other use cases which don’t seem to be considered (or at least mentioned) in the paper. A few things I noticed while scanning the paper related to the verification code discussion: * It sadly doesn’t reference Software Heritage ID’s, which I personally think is a well thought through identifier scheme. I wonder how SWHID’s compare with OmniBOR in terms of some of the issues raised in the paper. * No mention of using the identifiers for verification purpose, although there is a mention of “Inherent Identifiers” whose properties include the ability to verify * One of the criteria is “grouping” – which is stated to be unsolved at this point * Section 2.5 “Path 5: Unidentified Software Descriptor to Augment Paths 2, 3, and 4” describes a path which seems quite implementable using our current SPDX 3.0 model Gary -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#5584): https://lists.spdx.org/g/Spdx-tech/message/5584 Mute This Topic: https://lists.spdx.org/mt/103815753/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
