Supplier ambiguities, difficulties with the example given


Tyler Pirtle
 

Hi SPDX friends, 

I have some questions about the Package supplier attribute and could use some discussion. Like many others here the EO is a concern, and in glancing at the NTIA document I'm concerned about the definitions between the two fields. Apologies if this was discussed elsewhere, I couldn't find it!

The NTIA doc says that a Supplier Name is:

The name of an entity that creates, defines, and identifies
components.

The SPDX spec for "Package Supplier" is similar but not quite the same flavor:

Identify the actual distribution source for the package/directory identified in the SPDX document. This might or might not be different from the originating distribution source for the package. The name of the Package Supplier shall be an organization or recognized author and not a web site. For example, SourceForge is a host website, not a supplier, the supplier for https://sourceforge.net/projects/bridge/ is “The Linux Foundation.”
I feel like since both specs are asking for the responsible entity, there is some confusion here in the words "Identify the actual distribution source" but explicitly "not a URL". Is there a proper definition of "distribution source"? The example given - "The Linux Foundation" is not referenced anywhere in https://sourceforge.net/projects/bridge/ either on the website itself, nor anywhere in the package contents and I'm left very confused... 

I'm wondering if the Package Supplier is materially different than the Copyright Holder (in most cases?) Am I totally off base there? Can someone illustrate for me how/when these predicates differ? 


Thanks,


Tyler


Sebastian Crane
 

Dear Tyler,

I hope I can shed some light on this. The SPDX field 'Package Supplier' doesn't refer to the original creator of a package, but rather the person or organisation that the package was distributed by - in other words, the 'middle-man' in a software supply chain. This is very common of course in free and open source environments, where you get companies such as Red Hat distributing lots of software, much of which was not created by Red Hat (such as the vast repositories of packages available in RHEL).

The SPDX 'Package Originator' field, however, refers to the initial author of the software, and seems to align more closely with what the NTIA document calls a 'Supplier'. As conjecture, I would imagine this is due to a focus on more proprietary software supply chains in the NTIA discussions, where such intermediate steps of packaging, modification and repackaging are a little less common.

Since you mentioned copyright, I'll also add that the copyright holder of a package is usually the 'Package Originator'. However, there are very often many more one-off contributors to packages who would hold copyright over some portion of the software (e.g. contractors or individuals not affiliated with the same organisation), so SPDX had a number of other fields available to more precisely capture this information (the 'Package Copyright Text' field for instance).

That 'actual distribution source' that the specification mentions just means that the name of the entity should be used in the field, rather than the entity's web address. As for that section's example, I think it used to be clear, so we probably ought to update that in SPDX 3.0 to be less confusing :-)

Hope this helps, and let me know if I've missed anything!

Best wishes,

Sebastian

On 26 October 2022 17:44:27 BST, "rtp via lists.spdx.org" <rtp=google.com@...> wrote:
Hi SPDX friends,

I have some questions about the Package supplier attribute and could use some discussion. Like many others here the EO is a concern, and in glancing at the NTIA document ( https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf ) I'm concerned about the definitions between the two fields. Apologies if this was discussed elsewhere, I couldn't find it!

The NTIA doc says that a Supplier Name is:


The name of an entity that creates, defines, and identifies
components.
The SPDX spec for "Package Supplier" is similar but not quite the same flavor:


Identify the actual distribution source for the package/directory
identified in the SPDX document. This might or might not be different from
the originating distribution source for the package. The name of the
Package Supplier shall be an organization or recognized author and not a
web site. For example, SourceForge is a host website, not a supplier, the
supplier for https://sourceforge.net/projects/bridge/ is “The Linux
Foundation.”
I feel like since both specs are asking for the *responsible* *entity* , there is some confusion here in the words "Identify the actual distribution source" but explicitly "not a URL". Is there a proper definition of "distribution source"? The example given - "The Linux Foundation" is not referenced anywhere in https://sourceforge.net/projects/bridge/ either on the website itself, nor anywhere in the package contents and I'm left very confused...

I'm wondering if the Package Supplier is materially different than the Copyright Holder (in most cases?) Am I totally off base there? Can someone illustrate for me how/when these predicates differ?

Thanks,

Tyler





Tyler Pirtle
 

Thanks Sebastian, one more comment below here - 

On Wed, Oct 26, 2022 at 11:28 AM Sebastian Crane <seabass-labrax@...> wrote:


Dear Tyler,

I hope I can shed some light on this. The SPDX field 'Package Supplier' doesn't refer to the original creator of a package, but rather the person or organisation that the package was distributed by - in other words, the 'middle-man' in a software supply chain. This is very common of course in free and open source environments, where you get companies such as Red Hat distributing lots of software, much of which was not created by Red Hat (such as the vast repositories of packages available in RHEL).

The SPDX 'Package Originator' field, however, refers to the initial author of the software, and seems to align more closely with what the NTIA document calls a 'Supplier'. As conjecture, I would imagine this is due to a focus on more proprietary software supply chains in the NTIA discussions, where such intermediate steps of packaging, modification and repackaging are a little less common.

Since you mentioned copyright, I'll also add that the copyright holder of a package is usually the 'Package Originator'. However, there are very often many more one-off contributors to packages who would hold copyright over some portion of the software (e.g. contractors or individuals not affiliated with the same organisation), so SPDX had a number of other fields available to more precisely capture this information (the 'Package Copyright Text' field for instance).

That 'actual distribution source' that the specification mentions just means that the name of the entity should be used in the field, rather than the entity's web address. As for that section's example, I think it used to be clear, so we probably ought to update that in SPDX 3.0 to be less confusing :-)

Hope this helps, and let me know if I've missed anything!



This is super helpful - one last clarification then regarding the SourceForge example? "Linux Foundation" is assumed to be the entity responsible for the distribution source (SourceForge in this case?) Is that correct? 

(If so i think that might be out of date, SourceForge is currently owned and operated by Slashdot Media


 
Best wishes,

Sebastian

On 26 October 2022 17:44:27 BST, "rtp via lists.spdx.org" <rtp=google.com@...> wrote:
>Hi SPDX friends,
>
>I have some questions about the Package supplier attribute and could use some discussion. Like many others here the EO is a concern, and in glancing at the NTIA document ( https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf ) I'm concerned about the definitions between the two fields. Apologies if this was discussed elsewhere, I couldn't find it!
>
>The NTIA doc says that a Supplier Name is:
>
>>
>> The name of an entity that creates, defines, and identifies
>> components.
>>
>
>The SPDX spec for "Package Supplier" is similar but not quite the same flavor:
>
>>
>> Identify the actual distribution source for the package/directory
>> identified in the SPDX document. This might or might not be different from
>> the originating distribution source for the package. The name of the
>> Package Supplier shall be an organization or recognized author and not a
>> web site. For example, SourceForge is a host website, not a supplier, the
>> supplier for https://sourceforge.net/projects/bridge/ is “The Linux
>> Foundation.”
>>
>
>I feel like since both specs are asking for the *responsible* *entity* , there is some confusion here in the words "Identify the actual distribution source" but explicitly "not a URL". Is there a proper definition of "distribution source"? The example given - "The Linux Foundation" is not referenced anywhere in https://sourceforge.net/projects/bridge/ either on the website itself, nor anywhere in the package contents and I'm left very confused...
>
>I'm wondering if the Package Supplier is materially different than the Copyright Holder (in most cases?) Am I totally off base there? Can someone illustrate for me how/when these predicates differ?
>
>Thanks,
>
>Tyler
>
>
>
>
>






Dick Brooks
 

Sebastian,

 

That differs from what I see in the NTIA SBOM Framing document:

https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf

 

2.2.3 Supplier Name

name or other identifier of the supplier of a component in an SBOM entry

Supplier Name should include some capability to handle multiple names or aliases. When the

author and supplier are the same, the supplier created an SBOM for their own component.

When the author and supplier are different, the author is making claims or assertions about a

component for which the author is not the supplier.

 

 

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.com

Email: dick@...

Tel: +1 978-696-1788

 

-----Original Message-----
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Sebastian Crane
Sent: Wednesday, October 26, 2022 2:28 PM
To: spdx-tech@...
Subject: Re: [spdx-tech] Supplier ambiguities, difficulties with the example given

 

 

 

Dear Tyler,

 

I hope I can shed some light on this. The SPDX field 'Package Supplier' doesn't refer to the original creator of a package, but rather the person or organisation that the package was distributed by - in other words, the 'middle-man' in a software supply chain. This is very common of course in free and open source environments, where you get companies such as Red Hat distributing lots of software, much of which was not created by Red Hat (such as the vast repositories of packages available in RHEL).

 

The SPDX 'Package Originator' field, however, refers to the initial author of the software, and seems to align more closely with what the NTIA document calls a 'Supplier'. As conjecture, I would imagine this is due to a focus on more proprietary software supply chains in the NTIA discussions, where such intermediate steps of packaging, modification and repackaging are a little less common.

 

Since you mentioned copyright, I'll also add that the copyright holder of a package is usually the 'Package Originator'. However, there are very often many more one-off contributors to packages who would hold copyright over some portion of the software (e.g. contractors or individuals not affiliated with the same organisation), so SPDX had a number of other fields available to more precisely capture this information (the 'Package Copyright Text' field for instance).

 

That 'actual distribution source' that the specification mentions just means that the name of the entity should be used in the field, rather than the entity's web address. As for that section's example, I think it used to be clear, so we probably ought to update that in SPDX 3.0 to be less confusing :-)

 

Hope this helps, and let me know if I've missed anything!

 

Best wishes,

 

Sebastian

 

On 26 October 2022 17:44:27 BST, "rtp via lists.spdx.org" <rtp=google.com@...> wrote:

>Hi SPDX friends,

>I have some questions about the Package supplier attribute and could use some discussion. Like many others here the EO is a concern, and in glancing at the NTIA document ( https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf ) I'm concerned about the definitions between the two fields. Apologies if this was discussed elsewhere, I couldn't find it!

>The NTIA doc says that a Supplier Name is:

>>

>> The name of an entity that creates, defines, and identifies

>> components.

>>

>The SPDX spec for "Package Supplier" is similar but not quite the same flavor:

>>

>> Identify the actual distribution source for the package/directory

>> identified in the SPDX document. This might or might not be different

>> from the originating distribution source for the package. The name of

>> the Package Supplier shall be an organization or recognized author

>> and not a web site. For example, SourceForge is a host website, not a

>> supplier, the supplier for https://sourceforge.net/projects/bridge/

>> is “The Linux Foundation.”

>>

>I feel like since both specs are asking for the *responsible* *entity* , there is some confusion here in the words "Identify the actual distribution source" but explicitly "not a URL". Is there a proper definition of "distribution source"? The example given - "The Linux Foundation" is not referenced anywhere in https://sourceforge.net/projects/bridge/ either on the website itself, nor anywhere in the package contents and I'm left very confused...

>I'm wondering if the Package Supplier is materially different than the Copyright Holder (in most cases?) Am I totally off base there? Can someone illustrate for me how/when these predicates differ?

>Thanks,

>Tyler

 

 

 

 


Brandon Lum
 

I have a follow-up question around forked code, in that case, would the supplier be the owner of the forked code or the original code repo? or how would one encode this such that we can capture the pedigree? 


On Wed, Oct 26, 2022 at 3:33 PM Dick Brooks <dick@...> wrote:

Sebastian,

 

That differs from what I see in the NTIA SBOM Framing document:

https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf

 

2.2.3 Supplier Name

name or other identifier of the supplier of a component in an SBOM entry

Supplier Name should include some capability to handle multiple names or aliases. When the

author and supplier are the same, the supplier created an SBOM for their own component.

When the author and supplier are different, the author is making claims or assertions about a

component for which the author is not the supplier.

 

 

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.com

Email: dick@...

Tel: +1 978-696-1788

 

-----Original Message-----
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Sebastian Crane
Sent: Wednesday, October 26, 2022 2:28 PM
To: spdx-tech@...
Subject: Re: [spdx-tech] Supplier ambiguities, difficulties with the example given

 

 

 

Dear Tyler,

 

I hope I can shed some light on this. The SPDX field 'Package Supplier' doesn't refer to the original creator of a package, but rather the person or organisation that the package was distributed by - in other words, the 'middle-man' in a software supply chain. This is very common of course in free and open source environments, where you get companies such as Red Hat distributing lots of software, much of which was not created by Red Hat (such as the vast repositories of packages available in RHEL).

 

The SPDX 'Package Originator' field, however, refers to the initial author of the software, and seems to align more closely with what the NTIA document calls a 'Supplier'. As conjecture, I would imagine this is due to a focus on more proprietary software supply chains in the NTIA discussions, where such intermediate steps of packaging, modification and repackaging are a little less common.

 

Since you mentioned copyright, I'll also add that the copyright holder of a package is usually the 'Package Originator'. However, there are very often many more one-off contributors to packages who would hold copyright over some portion of the software (e.g. contractors or individuals not affiliated with the same organisation), so SPDX had a number of other fields available to more precisely capture this information (the 'Package Copyright Text' field for instance).

 

That 'actual distribution source' that the specification mentions just means that the name of the entity should be used in the field, rather than the entity's web address. As for that section's example, I think it used to be clear, so we probably ought to update that in SPDX 3.0 to be less confusing :-)

 

Hope this helps, and let me know if I've missed anything!

 

Best wishes,

 

Sebastian

 

On 26 October 2022 17:44:27 BST, "rtp via lists.spdx.org" <rtp=google.com@...> wrote:

>Hi SPDX friends,

> 

>I have some questions about the Package supplier attribute and could use some discussion. Like many others here the EO is a concern, and in glancing at the NTIA document ( https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf ) I'm concerned about the definitions between the two fields. Apologies if this was discussed elsewhere, I couldn't find it!

> 

>The NTIA doc says that a Supplier Name is:

> 

>>

>> The name of an entity that creates, defines, and identifies

>> components.

>>

> 

>The SPDX spec for "Package Supplier" is similar but not quite the same flavor:

> 

>>

>> Identify the actual distribution source for the package/directory

>> identified in the SPDX document. This might or might not be different

>> from the originating distribution source for the package. The name of

>> the Package Supplier shall be an organization or recognized author

>> and not a web site. For example, SourceForge is a host website, not a

>> supplier, the supplier for https://sourceforge.net/projects/bridge/

>> is “The Linux Foundation.”

>>

> 

>I feel like since both specs are asking for the *responsible* *entity* , there is some confusion here in the words "Identify the actual distribution source" but explicitly "not a URL". Is there a proper definition of "distribution source"? The example given - "The Linux Foundation" is not referenced anywhere in https://sourceforge.net/projects/bridge/ either on the website itself, nor anywhere in the package contents and I'm left very confused...

> 

>I'm wondering if the Package Supplier is materially different than the Copyright Holder (in most cases?) Am I totally off base there? Can someone illustrate for me how/when these predicates differ?

> 

>Thanks,

> 

>Tyler

> 

> 

> 

> 

> 

 

 

 

 


Dick Brooks
 

Brandon,

 

IMO, forked code that becomes a derivative work would identify the party producing the derivative work as the Supplier Name.

 

Forked code, that is distributed without modification should identify the original supplier of the code as the Supplier Name.

 

The Supplier Name is the party that needs to provide SBOM’s.

 

Again, just IMO.

 

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.com

Email: dick@...

Tel: +1 978-696-1788

 

From: Brandon Lum <lumb@...>
Sent: Wednesday, November 2, 2022 10:25 AM
To: dick@...
Cc: seabass-labrax@...; spdx-tech@...
Subject: Re: [spdx-tech] Supplier ambiguities, difficulties with the example given

 

I have a follow-up question around forked code, in that case, would the supplier be the owner of the forked code or the original code repo? or how would one encode this such that we can capture the pedigree? 

 

On Wed, Oct 26, 2022 at 3:33 PM Dick Brooks <dick@...> wrote:

Sebastian,

 

That differs from what I see in the NTIA SBOM Framing document:

https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf

 

2.2.3 Supplier Name

name or other identifier of the supplier of a component in an SBOM entry

Supplier Name should include some capability to handle multiple names or aliases. When the

author and supplier are the same, the supplier created an SBOM for their own component.

When the author and supplier are different, the author is making claims or assertions about a

component for which the author is not the supplier.

 

 

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.com

Email: dick@...

Tel: +1 978-696-1788

 

-----Original Message-----
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Sebastian Crane
Sent: Wednesday, October 26, 2022 2:28 PM
To: spdx-tech@...
Subject: Re: [spdx-tech] Supplier ambiguities, difficulties with the example given

 

 

 

Dear Tyler,

 

I hope I can shed some light on this. The SPDX field 'Package Supplier' doesn't refer to the original creator of a package, but rather the person or organisation that the package was distributed by - in other words, the 'middle-man' in a software supply chain. This is very common of course in free and open source environments, where you get companies such as Red Hat distributing lots of software, much of which was not created by Red Hat (such as the vast repositories of packages available in RHEL).

 

The SPDX 'Package Originator' field, however, refers to the initial author of the software, and seems to align more closely with what the NTIA document calls a 'Supplier'. As conjecture, I would imagine this is due to a focus on more proprietary software supply chains in the NTIA discussions, where such intermediate steps of packaging, modification and repackaging are a little less common.

 

Since you mentioned copyright, I'll also add that the copyright holder of a package is usually the 'Package Originator'. However, there are very often many more one-off contributors to packages who would hold copyright over some portion of the software (e.g. contractors or individuals not affiliated with the same organisation), so SPDX had a number of other fields available to more precisely capture this information (the 'Package Copyright Text' field for instance).

 

That 'actual distribution source' that the specification mentions just means that the name of the entity should be used in the field, rather than the entity's web address. As for that section's example, I think it used to be clear, so we probably ought to update that in SPDX 3.0 to be less confusing :-)

 

Hope this helps, and let me know if I've missed anything!

 

Best wishes,

 

Sebastian

 

On 26 October 2022 17:44:27 BST, "rtp via lists.spdx.org" <rtp=google.com@...> wrote:

>Hi SPDX friends,

>I have some questions about the Package supplier attribute and could use some discussion. Like many others here the EO is a concern, and in glancing at the NTIA document ( https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf ) I'm concerned about the definitions between the two fields. Apologies if this was discussed elsewhere, I couldn't find it!

>The NTIA doc says that a Supplier Name is:

>>

>> The name of an entity that creates, defines, and identifies

>> components.

>>

>The SPDX spec for "Package Supplier" is similar but not quite the same flavor:

>>

>> Identify the actual distribution source for the package/directory

>> identified in the SPDX document. This might or might not be different

>> from the originating distribution source for the package. The name of

>> the Package Supplier shall be an organization or recognized author

>> and not a web site. For example, SourceForge is a host website, not a

>> supplier, the supplier for https://sourceforge.net/projects/bridge/

>> is “The Linux Foundation.”

>>

>I feel like since both specs are asking for the *responsible* *entity* , there is some confusion here in the words "Identify the actual distribution source" but explicitly "not a URL". Is there a proper definition of "distribution source"? The example given - "The Linux Foundation" is not referenced anywhere in https://sourceforge.net/projects/bridge/ either on the website itself, nor anywhere in the package contents and I'm left very confused...

>I'm wondering if the Package Supplier is materially different than the Copyright Holder (in most cases?) Am I totally off base there? Can someone illustrate for me how/when these predicates differ?

>Thanks,

>Tyler

 

 

 

 


Joe Bussell
 

This seems more of a discussion of provenance than SBOM. We use COSE signed SPDX v2 SBOMs to protect the contents of our internal packages. We use a different .json file to give us the repo id, commit hash, and machine info for the package’s build. This provenance record, in combination with the SBOM, allows us to follow an auditable trail back to the origin. This is very important to us for servicing multiple versions.

 

We are working hard to get our SBOMs ready for public consumption via SCITT. I do not see the value of sharing our internal provenance data as the private repos will not be meaningful to the SBOM reader. However, if I had a complete SBOM and provenance record for the open-source packages we consume I would like to forward that data along.

 

Is there allowance for provenance containing repo address and commit ID from Git repos in SPDX 3?

 

What is the intended workflow for moving something from proprietary to public in terms of detailed 1st party supplier data? Would you have an internal SBOM that is associated with the external one by hash, or ensure that the original SBOM produced by the origin service wrote down the public bits into a sharable SBOM and the private bits into another record?

 

--

Joe Bussell

Windows Engineering System | Tool Benders

 

🙋‍♂️ My pronouns are he/him (why this matters)

🗓️ Book a meeting with me

👍 Inviting Feedback

Timezone: (GMT-8) US Pacific

 

N.B.: I may send mail during times when others are not working. I do not expect engagement from you when you are not working.

 

 

From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Dick Brooks via lists.spdx.org
Sent: Wednesday, November 2, 2022 7:33 AM
To: 'Brandon Lum' <lumb@...>
Cc: seabass-labrax@...; spdx-tech@...
Subject: [EXTERNAL] Re: [spdx-tech] Supplier ambiguities, difficulties with the example given

 

Brandon,

 

IMO, forked code that becomes a derivative work would identify the party producing the derivative work as the Supplier Name.

 

Forked code, that is distributed without modification should identify the original supplier of the code as the Supplier Name.

 

The Supplier Name is the party that needs to provide SBOM’s.

 

Again, just IMO.

 

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.com

Email: dick@...

Tel: +1 978-696-1788

 

From: Brandon Lum <lumb@...>
Sent: Wednesday, November 2, 2022 10:25 AM
To: dick@...
Cc: seabass-labrax@...; spdx-tech@...
Subject: Re: [spdx-tech] Supplier ambiguities, difficulties with the example given

 

I have a follow-up question around forked code, in that case, would the supplier be the owner of the forked code or the original code repo? or how would one encode this such that we can capture the pedigree? 

 

On Wed, Oct 26, 2022 at 3:33 PM Dick Brooks <dick@...> wrote:

Sebastian,

 

That differs from what I see in the NTIA SBOM Framing document:

https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf

 

2.2.3 Supplier Name

name or other identifier of the supplier of a component in an SBOM entry

Supplier Name should include some capability to handle multiple names or aliases. When the

author and supplier are the same, the supplier created an SBOM for their own component.

When the author and supplier are different, the author is making claims or assertions about a

component for which the author is not the supplier.

 

 

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.com

Email: dick@...

Tel: +1 978-696-1788

 

-----Original Message-----
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Sebastian Crane
Sent: Wednesday, October 26, 2022 2:28 PM
To: spdx-tech@...
Subject: Re: [spdx-tech] Supplier ambiguities, difficulties with the example given

 

 

 

Dear Tyler,

 

I hope I can shed some light on this. The SPDX field 'Package Supplier' doesn't refer to the original creator of a package, but rather the person or organisation that the package was distributed by - in other words, the 'middle-man' in a software supply chain. This is very common of course in free and open source environments, where you get companies such as Red Hat distributing lots of software, much of which was not created by Red Hat (such as the vast repositories of packages available in RHEL).

 

The SPDX 'Package Originator' field, however, refers to the initial author of the software, and seems to align more closely with what the NTIA document calls a 'Supplier'. As conjecture, I would imagine this is due to a focus on more proprietary software supply chains in the NTIA discussions, where such intermediate steps of packaging, modification and repackaging are a little less common.

 

Since you mentioned copyright, I'll also add that the copyright holder of a package is usually the 'Package Originator'. However, there are very often many more one-off contributors to packages who would hold copyright over some portion of the software (e.g. contractors or individuals not affiliated with the same organisation), so SPDX had a number of other fields available to more precisely capture this information (the 'Package Copyright Text' field for instance).

 

That 'actual distribution source' that the specification mentions just means that the name of the entity should be used in the field, rather than the entity's web address. As for that section's example, I think it used to be clear, so we probably ought to update that in SPDX 3.0 to be less confusing :-)

 

Hope this helps, and let me know if I've missed anything!

 

Best wishes,

 

Sebastian

 

On 26 October 2022 17:44:27 BST, "rtp via lists.spdx.org" <rtp=google.com@...> wrote:

>Hi SPDX friends,

>I have some questions about the Package supplier attribute and could use some discussion. Like many others here the EO is a concern, and in glancing at the NTIA document ( https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf ) I'm concerned about the definitions between the two fields. Apologies if this was discussed elsewhere, I couldn't find it!

>The NTIA doc says that a Supplier Name is:

>>

>> The name of an entity that creates, defines, and identifies

>> components.

>>

>The SPDX spec for "Package Supplier" is similar but not quite the same flavor:

>>

>> Identify the actual distribution source for the package/directory

>> identified in the SPDX document. This might or might not be different

>> from the originating distribution source for the package. The name of

>> the Package Supplier shall be an organization or recognized author

>> and not a web site. For example, SourceForge is a host website, not a

>> supplier, the supplier for https://sourceforge.net/projects/bridge/

>> is “The Linux Foundation.”

>>

>I feel like since both specs are asking for the *responsible* *entity* , there is some confusion here in the words "Identify the actual distribution source" but explicitly "not a URL". Is there a proper definition of "distribution source"? The example given - "The Linux Foundation" is not referenced anywhere in https://sourceforge.net/projects/bridge/ either on the website itself, nor anywhere in the package contents and I'm left very confused...

>I'm wondering if the Package Supplier is materially different than the Copyright Holder (in most cases?) Am I totally off base there? Can someone illustrate for me how/when these predicates differ?

>Thanks,

>Tyler

 

 

 

 


Dick Brooks
 

Good points Joe.

 

How is MS going to communicate the SCITT download location for the SBOM to consumers?

 

The government procurement officers are facing a deluge of varying responses from different vendors in response to OMB memo M-22-18. Automation will be imperative to success of the M-22-18 program.

https://energycentral.com/c/pip/1000%E2%80%99s-vendors-1000%E2%80%99s-products-1000%E2%80%99s-sbom%E2%80%99s-1000%E2%80%99s-attestation-%E2%80%93-oh-my

 

I posted another article advising software vendors on preparations for M-22-18:

https://energycentral.com/c/pip/advice-software-vendors-prepare-omb-m-22-18-requirements

 

I think everyone is waiting on the FAR to provide explicit guidance on how all of this will work.

 

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.com

Email: dick@...

Tel: +1 978-696-1788

 

From: Joe Bussell <joe.bussell@...>
Sent: Wednesday, November 2, 2022 11:24 AM
To: Richard Brooks <dick@...>; 'Brandon Lum' <lumb@...>
Cc: seabass-labrax@...; spdx-tech@...
Subject: RE: [EXTERNAL] Re: [spdx-tech] Supplier ambiguities, difficulties with the example given

 

This seems more of a discussion of provenance than SBOM. We use COSE signed SPDX v2 SBOMs to protect the contents of our internal packages. We use a different .json file to give us the repo id, commit hash, and machine info for the package’s build. This provenance record, in combination with the SBOM, allows us to follow an auditable trail back to the origin. This is very important to us for servicing multiple versions.

 

We are working hard to get our SBOMs ready for public consumption via SCITT. I do not see the value of sharing our internal provenance data as the private repos will not be meaningful to the SBOM reader. However, if I had a complete SBOM and provenance record for the open-source packages we consume I would like to forward that data along.

 

Is there allowance for provenance containing repo address and commit ID from Git repos in SPDX 3?

 

What is the intended workflow for moving something from proprietary to public in terms of detailed 1st party supplier data? Would you have an internal SBOM that is associated with the external one by hash, or ensure that the original SBOM produced by the origin service wrote down the public bits into a sharable SBOM and the private bits into another record?

 

--

Joe Bussell

Windows Engineering System | Tool Benders

 

🙋‍♂️ My pronouns are he/him (why this matters)

🗓️ Book a meeting with me

👍 Inviting Feedback

Timezone: (GMT-8) US Pacific

 

N.B.: I may send mail during times when others are not working. I do not expect engagement from you when you are not working.

 

 

From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Dick Brooks via lists.spdx.org
Sent: Wednesday, November 2, 2022 7:33 AM
To: 'Brandon Lum' <lumb@...>
Cc: seabass-labrax@...; spdx-tech@...
Subject: [EXTERNAL] Re: [spdx-tech] Supplier ambiguities, difficulties with the example given

 

Brandon,

 

IMO, forked code that becomes a derivative work would identify the party producing the derivative work as the Supplier Name.

 

Forked code, that is distributed without modification should identify the original supplier of the code as the Supplier Name.

 

The Supplier Name is the party that needs to provide SBOM’s.

 

Again, just IMO.

 

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.com

Email: dick@...

Tel: +1 978-696-1788

 

From: Brandon Lum <lumb@...>
Sent: Wednesday, November 2, 2022 10:25 AM
To: dick@...
Cc: seabass-labrax@...; spdx-tech@...
Subject: Re: [spdx-tech] Supplier ambiguities, difficulties with the example given

 

I have a follow-up question around forked code, in that case, would the supplier be the owner of the forked code or the original code repo? or how would one encode this such that we can capture the pedigree? 

 

On Wed, Oct 26, 2022 at 3:33 PM Dick Brooks <dick@...> wrote:

Sebastian,

 

That differs from what I see in the NTIA SBOM Framing document:

https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf

 

2.2.3 Supplier Name

name or other identifier of the supplier of a component in an SBOM entry

Supplier Name should include some capability to handle multiple names or aliases. When the

author and supplier are the same, the supplier created an SBOM for their own component.

When the author and supplier are different, the author is making claims or assertions about a

component for which the author is not the supplier.

 

 

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.com

Email: dick@...

Tel: +1 978-696-1788

 

-----Original Message-----
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Sebastian Crane
Sent: Wednesday, October 26, 2022 2:28 PM
To: spdx-tech@...
Subject: Re: [spdx-tech] Supplier ambiguities, difficulties with the example given

 

 

 

Dear Tyler,

 

I hope I can shed some light on this. The SPDX field 'Package Supplier' doesn't refer to the original creator of a package, but rather the person or organisation that the package was distributed by - in other words, the 'middle-man' in a software supply chain. This is very common of course in free and open source environments, where you get companies such as Red Hat distributing lots of software, much of which was not created by Red Hat (such as the vast repositories of packages available in RHEL).

 

The SPDX 'Package Originator' field, however, refers to the initial author of the software, and seems to align more closely with what the NTIA document calls a 'Supplier'. As conjecture, I would imagine this is due to a focus on more proprietary software supply chains in the NTIA discussions, where such intermediate steps of packaging, modification and repackaging are a little less common.

 

Since you mentioned copyright, I'll also add that the copyright holder of a package is usually the 'Package Originator'. However, there are very often many more one-off contributors to packages who would hold copyright over some portion of the software (e.g. contractors or individuals not affiliated with the same organisation), so SPDX had a number of other fields available to more precisely capture this information (the 'Package Copyright Text' field for instance).

 

That 'actual distribution source' that the specification mentions just means that the name of the entity should be used in the field, rather than the entity's web address. As for that section's example, I think it used to be clear, so we probably ought to update that in SPDX 3.0 to be less confusing :-)

 

Hope this helps, and let me know if I've missed anything!

 

Best wishes,

 

Sebastian

 

On 26 October 2022 17:44:27 BST, "rtp via lists.spdx.org" <rtp=google.com@...> wrote:

>Hi SPDX friends,

>I have some questions about the Package supplier attribute and could use some discussion. Like many others here the EO is a concern, and in glancing at the NTIA document ( https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf ) I'm concerned about the definitions between the two fields. Apologies if this was discussed elsewhere, I couldn't find it!

>The NTIA doc says that a Supplier Name is:

>>

>> The name of an entity that creates, defines, and identifies

>> components.

>>

>The SPDX spec for "Package Supplier" is similar but not quite the same flavor:

>>

>> Identify the actual distribution source for the package/directory

>> identified in the SPDX document. This might or might not be different

>> from the originating distribution source for the package. The name of

>> the Package Supplier shall be an organization or recognized author

>> and not a web site. For example, SourceForge is a host website, not a

>> supplier, the supplier for https://sourceforge.net/projects/bridge/

>> is “The Linux Foundation.”

>>

>I feel like since both specs are asking for the *responsible* *entity* , there is some confusion here in the words "Identify the actual distribution source" but explicitly "not a URL". Is there a proper definition of "distribution source"? The example given - "The Linux Foundation" is not referenced anywhere in https://sourceforge.net/projects/bridge/ either on the website itself, nor anywhere in the package contents and I'm left very confused...

>I'm wondering if the Package Supplier is materially different than the Copyright Holder (in most cases?) Am I totally off base there? Can someone illustrate for me how/when these predicates differ?

>Thanks,

>Tyler

 

 

 

 


Dick Brooks
 

Joe,

 

FYI

 

I’ve prepared a conceptual example for how a software consumer could potentially use SCITT to check the trustworthiness of an SBOM, as part of the IETF London SCITT Hackathon:

https://github.com/ietf-scitt/use-cases/issues/26

 

I’m using REA’s Community Trust Registry (SAG-CTR™) as a “fill-in” for a SCITT registry in the Hackathon.

I’m anticipating the methods I plan to show in the Hackathon for how a consumer might query a SCITT registry using a REST API may be very similar to the example shown at the IETF meeting, when it’s all worked out, i.e.,

https://softwareassuranceguardian.com/REA_api/gettrustData?REACUSTID=SCITT_HACKATHON&FileHash=A0F8A0B3FEB6D89947CC4F6ABF420E1EFBE4EB1EAF90B77203683904B0C9DD85&SKID=2C17B5D1A50EA9144AAF8DD6D4EB22CCB8A6A3AB

 

All of the protocol details of SCITT interactions and functional features still need to be worked out.

 

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.com

Email: dick@...

Tel: +1 978-696-1788

 

From: Joe Bussell <joe.bussell@...>
Sent: Wednesday, November 2, 2022 11:24 AM
To: Richard Brooks <dick@...>; 'Brandon Lum' <lumb@...>
Cc: seabass-labrax@...; spdx-tech@...
Subject: RE: [EXTERNAL] Re: [spdx-tech] Supplier ambiguities, difficulties with the example given

 

This seems more of a discussion of provenance than SBOM. We use COSE signed SPDX v2 SBOMs to protect the contents of our internal packages. We use a different .json file to give us the repo id, commit hash, and machine info for the package’s build. This provenance record, in combination with the SBOM, allows us to follow an auditable trail back to the origin. This is very important to us for servicing multiple versions.

 

We are working hard to get our SBOMs ready for public consumption via SCITT. I do not see the value of sharing our internal provenance data as the private repos will not be meaningful to the SBOM reader. However, if I had a complete SBOM and provenance record for the open-source packages we consume I would like to forward that data along.

 

Is there allowance for provenance containing repo address and commit ID from Git repos in SPDX 3?

 

What is the intended workflow for moving something from proprietary to public in terms of detailed 1st party supplier data? Would you have an internal SBOM that is associated with the external one by hash, or ensure that the original SBOM produced by the origin service wrote down the public bits into a sharable SBOM and the private bits into another record?

 

--

Joe Bussell

Windows Engineering System | Tool Benders

 

🙋‍♂️ My pronouns are he/him (why this matters)

🗓️ Book a meeting with me

👍 Inviting Feedback

Timezone: (GMT-8) US Pacific

 

N.B.: I may send mail during times when others are not working. I do not expect engagement from you when you are not working.

 

 

From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Dick Brooks via lists.spdx.org
Sent: Wednesday, November 2, 2022 7:33 AM
To: 'Brandon Lum' <lumb@...>
Cc: seabass-labrax@...; spdx-tech@...
Subject: [EXTERNAL] Re: [spdx-tech] Supplier ambiguities, difficulties with the example given

 

Brandon,

 

IMO, forked code that becomes a derivative work would identify the party producing the derivative work as the Supplier Name.

 

Forked code, that is distributed without modification should identify the original supplier of the code as the Supplier Name.

 

The Supplier Name is the party that needs to provide SBOM’s.

 

Again, just IMO.

 

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.com

Email: dick@...

Tel: +1 978-696-1788

 

From: Brandon Lum <lumb@...>
Sent: Wednesday, November 2, 2022 10:25 AM
To: dick@...
Cc: seabass-labrax@...; spdx-tech@...
Subject: Re: [spdx-tech] Supplier ambiguities, difficulties with the example given

 

I have a follow-up question around forked code, in that case, would the supplier be the owner of the forked code or the original code repo? or how would one encode this such that we can capture the pedigree? 

 

On Wed, Oct 26, 2022 at 3:33 PM Dick Brooks <dick@...> wrote:

Sebastian,

 

That differs from what I see in the NTIA SBOM Framing document:

https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf

 

2.2.3 Supplier Name

name or other identifier of the supplier of a component in an SBOM entry

Supplier Name should include some capability to handle multiple names or aliases. When the

author and supplier are the same, the supplier created an SBOM for their own component.

When the author and supplier are different, the author is making claims or assertions about a

component for which the author is not the supplier.

 

 

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.com

Email: dick@...

Tel: +1 978-696-1788

 

-----Original Message-----
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Sebastian Crane
Sent: Wednesday, October 26, 2022 2:28 PM
To: spdx-tech@...
Subject: Re: [spdx-tech] Supplier ambiguities, difficulties with the example given

 

 

 

Dear Tyler,

 

I hope I can shed some light on this. The SPDX field 'Package Supplier' doesn't refer to the original creator of a package, but rather the person or organisation that the package was distributed by - in other words, the 'middle-man' in a software supply chain. This is very common of course in free and open source environments, where you get companies such as Red Hat distributing lots of software, much of which was not created by Red Hat (such as the vast repositories of packages available in RHEL).

 

The SPDX 'Package Originator' field, however, refers to the initial author of the software, and seems to align more closely with what the NTIA document calls a 'Supplier'. As conjecture, I would imagine this is due to a focus on more proprietary software supply chains in the NTIA discussions, where such intermediate steps of packaging, modification and repackaging are a little less common.

 

Since you mentioned copyright, I'll also add that the copyright holder of a package is usually the 'Package Originator'. However, there are very often many more one-off contributors to packages who would hold copyright over some portion of the software (e.g. contractors or individuals not affiliated with the same organisation), so SPDX had a number of other fields available to more precisely capture this information (the 'Package Copyright Text' field for instance).

 

That 'actual distribution source' that the specification mentions just means that the name of the entity should be used in the field, rather than the entity's web address. As for that section's example, I think it used to be clear, so we probably ought to update that in SPDX 3.0 to be less confusing :-)

 

Hope this helps, and let me know if I've missed anything!

 

Best wishes,

 

Sebastian

 

On 26 October 2022 17:44:27 BST, "rtp via lists.spdx.org" <rtp=google.com@...> wrote:

>Hi SPDX friends,

>I have some questions about the Package supplier attribute and could use some discussion. Like many others here the EO is a concern, and in glancing at the NTIA document ( https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf ) I'm concerned about the definitions between the two fields. Apologies if this was discussed elsewhere, I couldn't find it!

>The NTIA doc says that a Supplier Name is:

>>

>> The name of an entity that creates, defines, and identifies

>> components.

>>

>The SPDX spec for "Package Supplier" is similar but not quite the same flavor:

>>

>> Identify the actual distribution source for the package/directory

>> identified in the SPDX document. This might or might not be different

>> from the originating distribution source for the package. The name of

>> the Package Supplier shall be an organization or recognized author

>> and not a web site. For example, SourceForge is a host website, not a

>> supplier, the supplier for https://sourceforge.net/projects/bridge/

>> is “The Linux Foundation.”

>>

>I feel like since both specs are asking for the *responsible* *entity* , there is some confusion here in the words "Identify the actual distribution source" but explicitly "not a URL". Is there a proper definition of "distribution source"? The example given - "The Linux Foundation" is not referenced anywhere in https://sourceforge.net/projects/bridge/ either on the website itself, nor anywhere in the package contents and I'm left very confused...

>I'm wondering if the Package Supplier is materially different than the Copyright Holder (in most cases?) Am I totally off base there? Can someone illustrate for me how/when these predicates differ?

>Thanks,

>Tyler