Re: [spdx-tech] CISA document on identifiers

[Dick Brooks]

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:d...@reliableenergyanalytics.com> 
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

From: Venkatasubramaniam Ramakrishnan  
Sent: Friday, March 29, 2024 11:55 PM
To: d...@reliableenergyanalytics.com
Cc: Gary O'Neall ; spdx-tech@lists.spdx.org
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 mailto:d...@reliableenergyanalytics.com> > 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:d...@reliableenergyanalytics.com> 
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>  
mailto:Spdx-tech@lists.spdx.org> > On Behalf Of 
Venkat Ramakrishnan
Sent: Friday, March 29, 2024 6:33 AM
To: Gary O'Neall mailto:g...@sourceauditor.com> >
Cc: spdx-tech@lists.spdx.org <mailto:spdx-tech@lists.spdx.org> 
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_source=link_campaign=sig-email_content=webmail>
 

Virus-free. 
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>
 www.avg.com

 

On Fri, Jan 19, 2024 at 1:03 AM Gary O'Neall mailto:g...@sourceauditor.com> > 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 fro

Re: [spdx-tech] CISA document on identifiers

[Venkat Ramakrishnan]

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 <
d...@reliableenergyanalytics.com> 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*
>
>
>
> *Never trust software, always verify and report!
> <https://reliableenergyanalytics.com/products>* ™
>
> http://www.reliableenergyanalytics.com
>
> Email: d...@reliableenergyanalytics.com
>
> Tel: +1 978-696-1788
>
>
>
>
>
> *From:* Spdx-tech@lists.spdx.org  *On Behalf Of
> *Venkat Ramakrishnan
> *Sent:* Friday, March 29, 2024 6:33 AM
> *To:* Gary O'Neall 
> *Cc:* spdx-tech@lists.spdx.org
> *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.
>
>
>
> [image: Image removed by sender.]
> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>
> Virus-free.www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>
>
>
> On Fri, Jan 19, 2024 at 1:03 AM Gary O'Neall 
> 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 (#5583): https://lists.spdx.org/g/Spdx-tech/message/5583
Mute This Topic: https://lists.spdx.org/mt/103815753/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] CISA document on identifiers

[Dick Brooks]

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:d...@reliableenergyanalytics.com> 
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Venkat 
Ramakrishnan
Sent: Friday, March 29, 2024 6:33 AM
To: Gary O'Neall 
Cc: spdx-tech@lists.spdx.org
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_source=link_campaign=sig-email_content=webmail>
 

Virus-free. 
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>
 www.avg.com

 

On Fri, Jan 19, 2024 at 1:03 AM Gary O'Neall mailto:g...@sourceauditor.com> > 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 (#5581): https://lists.spdx.org/g/Spdx-tech/message/5581
Mute This Topic: https://lists.spdx.org/mt/103815753/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] CISA document on identifiers

[Venkat Ramakrishnan]

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.



Virus-free.www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Fri, Jan 19, 2024 at 1:03 AM Gary O'Neall  wrote:

> One of the proposed solutions for package verification is to use OMNIBor
> identifiers for verification purposes (see PR #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
> 
> – 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 (#5580): https://lists.spdx.org/g/Spdx-tech/message/5580
Mute This Topic: https://lists.spdx.org/mt/103815753/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] CISA document on identifiers

[叶涛]

发自我的 iPad在 2024年1月19日，03:42，Dick Brooks  写道：I continue to believe that PURL/SWID, with a required namespace tag for software supplier identity, offers the most potential as an international unique software identifier. There are constraints that limit the viable options for unique software identifiers. Thanks, Dick Brooks  Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! ™http://www.reliableenergyanalytics.comEmail: d...@reliableenergyanalytics.comTel: +1 978-696-1788  From: Spdx-tech@lists.spdx.org  On Behalf Of Brandon Lum via lists.spdx.orgSent: Thursday, January 18, 2024 2:38 PMTo: Gary O'Neall Cc: spdx-tech@lists.spdx.orgSubject: Re: [spdx-tech] CISA document on identifiers I know there were quite a few responses to the RFC from CISA's paper (including ones i was involved with: Google, OpenSSF, GUAC). My gut feel to the CISA paper was more of a starting point for discussion than a guidance document. I am hoping that the responses will promote a forum for us to have these discussions with them and the broader community. On Thu, Jan 18, 2024 at 2:33 PM Gary O'Neall <g...@sourceauditor.com> wrote:One of the proposed solutions for package verification is to use OMNIBor identifiers for verification purposes (see PR #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 – 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 verifyOne of the criteria is “grouping” – which is stated to be unsolved at this pointSection 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 (#5493) |


  Reply To Sender
  
	
	| Reply To Group
	
  

|

  Mute This Topic


| New Topic






Your Subscription |
Contact Group Owner |

Unsubscribe

 [arch...@mail-archive.com]
_._,_._,_

Re: [spdx-tech] CISA document on identifiers

[Dick Brooks]

I continue to believe that PURL/SWID, with a required namespace tag for 
software supplier identity, offers the most potential as an international 
unique software identifier.

 

There are constraints that limit the viable options for unique software 
identifiers.

 

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:d...@reliableenergyanalytics.com> 
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Brandon 
Lum via lists.spdx.org
Sent: Thursday, January 18, 2024 2:38 PM
To: Gary O'Neall 
Cc: spdx-tech@lists.spdx.org
Subject: Re: [spdx-tech] CISA document on identifiers

 

I know there were quite a few responses to the RFC from CISA's paper (including 
ones i was involved with: Google, OpenSSF, GUAC). My gut feel to the CISA paper 
was more of a starting point for discussion than a guidance document. I am 
hoping that the responses will promote a forum for us to have these discussions 
with them and the broader community.

 

On Thu, Jan 18, 2024 at 2:33 PM Gary O'Neall mailto:g...@sourceauditor.com> > 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 (#5492): https://lists.spdx.org/g/Spdx-tech/message/5492
Mute This Topic: https://lists.spdx.org/mt/103815753/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] CISA document on identifiers

[Brandon Lum via lists.spdx.org]

I know there were quite a few responses to the RFC from CISA's paper
(including ones i was involved with: Google, OpenSSF, GUAC). My gut feel to
the CISA paper was more of a starting point for discussion than a guidance
document. I am hoping that the responses will promote a forum for us to
have these discussions with them and the broader community.

On Thu, Jan 18, 2024 at 2:33 PM Gary O'Neall  wrote:

> One of the proposed solutions for package verification is to use OMNIBor
> identifiers for verification purposes (see PR #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
> 
> – 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 (#5491): https://lists.spdx.org/g/Spdx-tech/message/5491
Mute This Topic: https://lists.spdx.org/mt/103815753/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-