Date   

Re: SPDX Thurs General Meeting Reminder

May Wang
 

Will the meeting be recorded?  I have a conflict, but would love to listen to the updates.  Thanks.  


On Wed, Jun 1, 2022 at 11:36 AM Phil Odence via lists.spdx.org <phil.odence=synopsys.com@...> wrote:

We will start this month’s meeting with an informal presentation from Kate about the OpenSSF “White House meeting” and implications for SPDX. https://www.linuxfoundation.org/press-release/linux-foundation-openssf-gather-industry-government-leaders-open-source-software-security-summit/

Anyone else who was involved is more than welcome to pitch in on discussion.

 

GENERAL MEETING

 

Meeting Time: Thurs, June 2, 8am PT / 10 am CT / 11am ET / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html


Conf call dial-in:

Join the meeting:
https://meet.jit.si/SPDXGeneralMeeting

To join by phone instead, tap this: +1.512.647.1431,,1310118349#

Looking for a different dial-in number?
See meeting dial-in numbers: 
https://meet.jit.si/static/dialInInfo.html?room=SPDXGeneralMeeting


If also dialing-in through a room phone, join without connecting to audio: 
https://meet.jit.si/SPDXGeneralMeeting#config.startSilent=true

 

Etherpad for minutes:

https://spdx.swinslow.net/p/spdx-general-minutes

 

Administrative Agenda

Attendance

Minutes Approval  https://github.com/spdx/meetings/blob/main/general/2022-05-05.md

 

Steering Committee Update – Phil

 

Technical Team Report – Kate/Gary/Others

  • Specification and Profiles
    • Overview
    • Core
    • Legal
    • Integrity
    • Defects
    • Usage and Other Emerging
  • Tooling

 

Legal Team Report – Jilayne/Paul/Steve

 

Outreach/Website Team Report – Jack/Sebastian

 

 


SPDX Thurs General Meeting Reminder

Phil Odence
 

We will start this month’s meeting with an informal presentation from Kate about the OpenSSF “White House meeting” and implications for SPDX. https://www.linuxfoundation.org/press-release/linux-foundation-openssf-gather-industry-government-leaders-open-source-software-security-summit/

Anyone else who was involved is more than welcome to pitch in on discussion.

 

GENERAL MEETING

 

Meeting Time: Thurs, June 2, 8am PT / 10 am CT / 11am ET / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html


Conf call dial-in:

Join the meeting:
https://meet.jit.si/SPDXGeneralMeeting

To join by phone instead, tap this: +1.512.647.1431,,1310118349#

Looking for a different dial-in number?
See meeting dial-in numbers: 
https://meet.jit.si/static/dialInInfo.html?room=SPDXGeneralMeeting


If also dialing-in through a room phone, join without connecting to audio: 
https://meet.jit.si/SPDXGeneralMeeting#config.startSilent=true

 

Etherpad for minutes:

https://spdx.swinslow.net/p/spdx-general-minutes

 

Administrative Agenda

Attendance

Minutes Approval  https://github.com/spdx/meetings/blob/main/general/2022-05-05.md

 

Steering Committee Update – Phil

 

Technical Team Report – Kate/Gary/Others

  • Specification and Profiles
    • Overview
    • Core
    • Legal
    • Integrity
    • Defects
    • Usage and Other Emerging
  • Tooling

 

Legal Team Report – Jilayne/Paul/Steve

 

Outreach/Website Team Report – Jack/Sebastian

 

 


VEX integration in SPDX #spdx

Patil, Sandeep
 

Hi , 
Is there any roadmap to integrate VEX to  with SPDX ? Or is there already way in current SPDX specification to integrate vulnerability information ? 


Regards
Sandeep 


Re: End Of Life Tag in spdx #spdx

Gary O'Neall
 

Armijn raises a valid concern.  We’ve avoided dynamic information in the past, but even with version 1.0 you could argue the “Concluded License” could change over time if new information is available after publication of the SPDX document.  We’ve certainly seen project home page links change over time as well.  

 

Since having the end of life information available is useful for a few use cases and the frequency of change should be relatively low, I’m of the opinion we could include this as an optional field.

 

One suggestion is to define the field as the valid information at the time the SPDX document is created.  That way, even if one of these fields changes later, the SPDX document still records valid facts.

 

Regards,

Gary

 

From: spdx@... <spdx@...> On Behalf Of Kate Stewart
Sent: Friday, May 20, 2022 5:41 AM
To: SPDX-general <spdx@...>
Subject: Re: [spdx] End Of Life Tag in spdx #spdx

 

 

 

On Fri, May 20, 2022 at 2:32 AM Steve Kilbane <stephen.kilbane@...> wrote:

Armijn said:

> Current information inside SPDX documents is largely static […]

> This would make SPDX a lot more cumbersome, as not only do the documents need to be generated, but they also need to be updated all the time to avoid falling out of sync

 

I have no opinion on end-of-life either way, but wouldn’t the same argument apply to security vulnerabilities?

 

Sort of.   Security information is even more likely to change after release, EOL for open source components supported by the community may,  but much less frequently.   

 

Thinking so far, is that this would start out as an optional field, so that those who do know the information

when assembling an SBOM can include it.   

 

Example:  you are using a product that contains the linux 4.9 kernel.   You know from the community (https://kernel.org/category/releases.html) that it will go out of support Jan 2023 (as of today, but this may evolve), 

so including this information, which could then be queried by a script around then, and then determine next steps, 

is going to be much more efficient then expecting all consumers of your product to add it manually.    Similarly

certain distros have expectations of EOL for support from the community (https://wiki.debian.org/LTS).

 

To your point,  there may well be a contract with a supplier, with a date that extends this, and in that case there 

are likely processes already in place to track/monitor/etc. in an organization.   However those consuming open 

source based products are not necessarily tracking the upstream components EOL, and probably should be. 

Adding this field, as optional, enables more efficiency.

 

Thanks,
Kate


Re: End Of Life Tag in spdx #spdx

Kate Stewart
 



On Fri, May 20, 2022 at 2:32 AM Steve Kilbane <stephen.kilbane@...> wrote:

Armijn said:

> Current information inside SPDX documents is largely static […]

> This would make SPDX a lot more cumbersome, as not only do the documents need to be generated, but they also need to be updated all the time to avoid falling out of sync

 

I have no opinion on end-of-life either way, but wouldn’t the same argument apply to security vulnerabilities?


Sort of.   Security information is even more likely to change after release, EOL for open source components supported by the community may,  but much less frequently.   

Thinking so far, is that this would start out as an optional field, so that those who do know the information
when assembling an SBOM can include it.   

Example:  you are using a product that contains the linux 4.9 kernel.   You know from the community (https://kernel.org/category/releases.html) that it will go out of support Jan 2023 (as of today, but this may evolve), 
so including this information, which could then be queried by a script around then, and then determine next steps, 
is going to be much more efficient then expecting all consumers of your product to add it manually.    Similarly
certain distros have expectations of EOL for support from the community (https://wiki.debian.org/LTS).

To your point,  there may well be a contract with a supplier, with a date that extends this, and in that case there 
are likely processes already in place to track/monitor/etc. in an organization.   However those consuming open 
source based products are not necessarily tracking the upstream components EOL, and probably should be. 
Adding this field, as optional, enables more efficiency.

Thanks,
Kate


Re: End Of Life Tag in spdx #spdx

Dick Brooks
 

Steve,

 

Regarding: “I have no opinion on end-of-life either way, but wouldn’t the same argument apply to security vulnerabilities?”

 

Yes, if a software vendor chooses to list each known vulnerability with a separate V 2.3 “SECURITY advisory object “affecting a software product on day one, when the SBOM is finalized.

 

However, that is not the case if a vendor chooses to link to a single, dynamically generated Vulnerability Disclosure Report (VDR) using a V 2.3 “SECUIRTY advisory object”, where the link is static, but the contents delivered by the link are dynamic, which enables a software consumer to answer this question about a software product: “What is the vulnerability status NOW at the SBOM component level?”

 

The 5/5 NIST guidance for Executive order 14028 supports this dynamic VDR concept, which appears in SPDX V 2.3, Appendix G 1.3.1 and G 1.9:

https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1

 

“Maintain vendor vulnerability disclosure reports at the SBOM component level.”

 

 

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: spdx@... <spdx@...> On Behalf Of Steve Kilbane
Sent: Friday, May 20, 2022 3:33 AM
To: spdx@...
Subject: Re: [spdx] End Of Life Tag in spdx #spdx

 

Armijn said:

> Current information inside SPDX documents is largely static […]

> This would make SPDX a lot more cumbersome, as not only do the documents need to be generated, but they also need to be updated all the time to avoid falling out of sync

 

I have no opinion on end-of-life either way, but wouldn’t the same argument apply to security vulnerabilities?

 

steve

 

From: spdx@... <spdx@...> On Behalf Of Armijn Hemel - Tjaldur Software Governance Solutions
Sent: 19 May 2022 11:21
To: spdx@...
Subject: Re: [spdx] End Of Life Tag in spdx #spdx

 

[External]

 

hello,

 

I would suggest to keep this information "out of band" and not inside SPDX documents. Current information inside SPDX documents is largely static: package, license, checksum, and so on. Of course there could have been errors that need to be fixed, but overall these fields are static.

 

EOL information, commercial status and support status on the other hand are much more dynamic. Sometimes packages are supported for only a few hours, sometimes for decades. Very often it is also not clear when a package is EOL or supported as many authors/maintainers do not announce it. The support is sometimes also not done by the author/maintainers, but by an external entity (for example: enterprise grade Linux distributions). Does this mean it is supported, or only supported for people willing to pay for it, or .... ? It is simply not clear and it adds a lot of fuzziness.

 

This would make SPDX a lot more cumbersome, as not only do the documents need to be generated, but they also need to be updated all the time to avoid falling out of sync. It also mixes syntax and semantics, which is never a good idea.

 

armijn

 

Kate and Sandeep,

 

Our customers are also interested in this information. There are two concepts to consider:

Commercial Status:

        <enumeration value="Available"></enumeration>

        <enumeration value="Retired"></enumeration>

        <enumeration value="EOL"></enumeration>

        <enumeration value="BetaTest"></enumeration>

        <enumeration value="Pilot"></enumeration>

        <enumeration value="Abandoned"></enumeration>

 

Support Status:

        <enumeration value="Supported"></enumeration>
        <enumeration value="Unsupported"></enumeration>
        <enumeration value="Community"></enumeration>

 

Both are described in the open-source Vendor Response File (VRF) XML schema available here: https://raw.githubusercontent.com/rjb4standards/REA-Products/master/SAGVendorSchema.xsd

 

 

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: spdx@... <spdx@...> On Behalf Of Kate Stewart
Sent: Friday, May 6, 2022 3:34 PM
To: SPDX-general <spdx@...>
Subject: Re: [spdx] End Of Life Tag in spdx #spdx

 

Hi Sandeep,

 

     There is a pull request expected shortly from the Usage profile team, to add this specific field to 2.3.

When it comes in,  please feel free to review and make sure it's going to suffice for your needs.

 

For now, with 2.2 documents,  suggest you use the Package Comment field (https://spdx.github.io/spdx-spec/package-information/#720-package-comment-field) and standardize on a tag (like EndOfSupport: ) and the date. 

 

Will that work for now?

 

Thanks, 
Kate

 

On Fri, May 6, 2022 at 2:27 PM Patil, Sandeep via lists.spdx.org <sandeep.patil=philips.com@...> wrote:

Hi All, 
We have requirement to specify End Of Life as part of package information in SBoM ,
Is there way current SPDX format support this ? 

Regards
Sandeep 

 

-- 
Armijn Hemel, MSc
Tjaldur Software Governance Solutions


Re: End Of Life Tag in spdx #spdx

Steve Kilbane
 

Armijn said:

> Current information inside SPDX documents is largely static […]

> This would make SPDX a lot more cumbersome, as not only do the documents need to be generated, but they also need to be updated all the time to avoid falling out of sync

 

I have no opinion on end-of-life either way, but wouldn’t the same argument apply to security vulnerabilities?

 

steve

 

From: spdx@... <spdx@...> On Behalf Of Armijn Hemel - Tjaldur Software Governance Solutions
Sent: 19 May 2022 11:21
To: spdx@...
Subject: Re: [spdx] End Of Life Tag in spdx #spdx

 

[External]

 

hello,

 

I would suggest to keep this information "out of band" and not inside SPDX documents. Current information inside SPDX documents is largely static: package, license, checksum, and so on. Of course there could have been errors that need to be fixed, but overall these fields are static.

 

EOL information, commercial status and support status on the other hand are much more dynamic. Sometimes packages are supported for only a few hours, sometimes for decades. Very often it is also not clear when a package is EOL or supported as many authors/maintainers do not announce it. The support is sometimes also not done by the author/maintainers, but by an external entity (for example: enterprise grade Linux distributions). Does this mean it is supported, or only supported for people willing to pay for it, or .... ? It is simply not clear and it adds a lot of fuzziness.

 

This would make SPDX a lot more cumbersome, as not only do the documents need to be generated, but they also need to be updated all the time to avoid falling out of sync. It also mixes syntax and semantics, which is never a good idea.

 

armijn

 

Kate and Sandeep,

 

Our customers are also interested in this information. There are two concepts to consider:

Commercial Status:

        <enumeration value="Available"></enumeration>

        <enumeration value="Retired"></enumeration>

        <enumeration value="EOL"></enumeration>

        <enumeration value="BetaTest"></enumeration>

        <enumeration value="Pilot"></enumeration>

        <enumeration value="Abandoned"></enumeration>

 

Support Status:

        <enumeration value="Supported"></enumeration>
        <enumeration value="Unsupported"></enumeration>
        <enumeration value="Community"></enumeration>

 

Both are described in the open-source Vendor Response File (VRF) XML schema available here: https://raw.githubusercontent.com/rjb4standards/REA-Products/master/SAGVendorSchema.xsd

 

 

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: spdx@... <spdx@...> On Behalf Of Kate Stewart
Sent: Friday, May 6, 2022 3:34 PM
To: SPDX-general <spdx@...>
Subject: Re: [spdx] End Of Life Tag in spdx #spdx

 

Hi Sandeep,

 

     There is a pull request expected shortly from the Usage profile team, to add this specific field to 2.3.

When it comes in,  please feel free to review and make sure it's going to suffice for your needs.

 

For now, with 2.2 documents,  suggest you use the Package Comment field (https://spdx.github.io/spdx-spec/package-information/#720-package-comment-field) and standardize on a tag (like EndOfSupport: ) and the date. 

 

Will that work for now?

 

Thanks, 
Kate

 

On Fri, May 6, 2022 at 2:27 PM Patil, Sandeep via lists.spdx.org <sandeep.patil=philips.com@...> wrote:

Hi All, 
We have requirement to specify End Of Life as part of package information in SBoM ,
Is there way current SPDX format support this ? 

Regards
Sandeep 

 

-- 
Armijn Hemel, MSc
Tjaldur Software Governance Solutions


Re: End Of Life Tag in spdx #spdx

Dick Brooks
 

I agree: “I would suggest to keep this information "out of band" and not inside SPDX documents”

 

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: spdx@... <spdx@...> On Behalf Of Armijn Hemel - Tjaldur Software Governance Solutions
Sent: Thursday, May 19, 2022 6:21 AM
To: spdx@...
Subject: Re: [spdx] End Of Life Tag in spdx #spdx

 

hello,

 

I would suggest to keep this information "out of band" and not inside SPDX documents. Current information inside SPDX documents is largely static: package, license, checksum, and so on. Of course there could have been errors that need to be fixed, but overall these fields are static.

 

EOL information, commercial status and support status on the other hand are much more dynamic. Sometimes packages are supported for only a few hours, sometimes for decades. Very often it is also not clear when a package is EOL or supported as many authors/maintainers do not announce it. The support is sometimes also not done by the author/maintainers, but by an external entity (for example: enterprise grade Linux distributions). Does this mean it is supported, or only supported for people willing to pay for it, or .... ? It is simply not clear and it adds a lot of fuzziness.

 

This would make SPDX a lot more cumbersome, as not only do the documents need to be generated, but they also need to be updated all the time to avoid falling out of sync. It also mixes syntax and semantics, which is never a good idea.

 

armijn

 

Kate and Sandeep,

 

Our customers are also interested in this information. There are two concepts to consider:

Commercial Status:

        <enumeration value="Available"></enumeration>

        <enumeration value="Retired"></enumeration>

        <enumeration value="EOL"></enumeration>

        <enumeration value="BetaTest"></enumeration>

        <enumeration value="Pilot"></enumeration>

        <enumeration value="Abandoned"></enumeration>

 

Support Status:

        <enumeration value="Supported"></enumeration>
        <enumeration value="Unsupported"></enumeration>
        <enumeration value="Community"></enumeration>

 

Both are described in the open-source Vendor Response File (VRF) XML schema available here: https://raw.githubusercontent.com/rjb4standards/REA-Products/master/SAGVendorSchema.xsd

 

 

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: spdx@... <spdx@...> On Behalf Of Kate Stewart
Sent: Friday, May 6, 2022 3:34 PM
To: SPDX-general <spdx@...>
Subject: Re: [spdx] End Of Life Tag in spdx #spdx

 

Hi Sandeep,

 

     There is a pull request expected shortly from the Usage profile team, to add this specific field to 2.3.

When it comes in,  please feel free to review and make sure it's going to suffice for your needs.

 

For now, with 2.2 documents,  suggest you use the Package Comment field (https://spdx.github.io/spdx-spec/package-information/#720-package-comment-field) and standardize on a tag (like EndOfSupport: ) and the date. 

 

Will that work for now?

 

Thanks, 
Kate

 

On Fri, May 6, 2022 at 2:27 PM Patil, Sandeep via lists.spdx.org <sandeep.patil=philips.com@...> wrote:

Hi All, 
We have requirement to specify End Of Life as part of package information in SBoM ,
Is there way current SPDX format support this ? 

Regards
Sandeep 

 

-- 
Armijn Hemel, MSc
Tjaldur Software Governance Solutions


Re: End Of Life Tag in spdx #spdx

Armijn Hemel - Tjaldur Software Governance Solutions
 

hello,

I would suggest to keep this information "out of band" and not inside SPDX documents. Current information inside SPDX documents is largely static: package, license, checksum, and so on. Of course there could have been errors that need to be fixed, but overall these fields are static.

EOL information, commercial status and support status on the other hand are much more dynamic. Sometimes packages are supported for only a few hours, sometimes for decades. Very often it is also not clear when a package is EOL or supported as many authors/maintainers do not announce it. The support is sometimes also not done by the author/maintainers, but by an external entity (for example: enterprise grade Linux distributions). Does this mean it is supported, or only supported for people willing to pay for it, or .... ? It is simply not clear and it adds a lot of fuzziness.

This would make SPDX a lot more cumbersome, as not only do the documents need to be generated, but they also need to be updated all the time to avoid falling out of sync. It also mixes syntax and semantics, which is never a good idea.

armijn

Kate and Sandeep,

 

Our customers are also interested in this information. There are two concepts to consider:

Commercial Status:

        <enumeration value="Available"></enumeration>

        <enumeration value="Retired"></enumeration>

        <enumeration value="EOL"></enumeration>

        <enumeration value="BetaTest"></enumeration>

        <enumeration value="Pilot"></enumeration>

        <enumeration value="Abandoned"></enumeration>

 

Support Status:

        <enumeration value="Supported"></enumeration>
        <enumeration value="Unsupported"></enumeration>
        <enumeration value="Community"></enumeration>

 

Both are described in the open-source Vendor Response File (VRF) XML schema available here: https://raw.githubusercontent.com/rjb4standards/REA-Products/master/SAGVendorSchema.xsd

 

 

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: spdx@... <spdx@...> On Behalf Of Kate Stewart
Sent: Friday, May 6, 2022 3:34 PM
To: SPDX-general <spdx@...>
Subject: Re: [spdx] End Of Life Tag in spdx #spdx

 

Hi Sandeep,

 

     There is a pull request expected shortly from the Usage profile team, to add this specific field to 2.3.

When it comes in,  please feel free to review and make sure it's going to suffice for your needs.

 

For now, with 2.2 documents,  suggest you use the Package Comment field (https://spdx.github.io/spdx-spec/package-information/#720-package-comment-field) and standardize on a tag (like EndOfSupport: ) and the date. 

 

Will that work for now?

 

Thanks, 
Kate

 

On Fri, May 6, 2022 at 2:27 PM Patil, Sandeep via lists.spdx.org <sandeep.patil=philips.com@...> wrote:

Hi All, 
We have requirement to specify End Of Life as part of package information in SBoM ,
Is there way current SPDX format support this ? 

Regards
Sandeep 


-- 
Armijn Hemel, MSc
Tjaldur Software Governance Solutions


Re: SPDXID #spdx

Gary O'Neall
 

Hi Sandeep,

 

Although the SPDX ID is internal to SPDX documents, you can refer to an SPDX ID in a different document using the SPDX Document identifier as defined in section 6.6.  So the statement below is accurate but could probably be made a bit clearer.

 

Regards,
Gary

 

From: spdx@... <spdx@...> On Behalf Of Patil, Sandeep via lists.spdx.org
Sent: Monday, May 16, 2022 11:44 PM
To: spdx@...
Subject: Re: [spdx] SPDXID #spdx

 

Hi Gary, 
Thanks for reply, then SPDXID will be mostly internal ID and can not be referenced externally, Do you think this might need some change in SPDXID documentation statement  ? 

"Uniquely identify any element in an SPDX document which may be referenced by other elements. These may be referenced internally and externally with the addition of the SPDX document identifier."


Regards
Sandeep 


Re: SPDXID #spdx

Patil, Sandeep
 

Hi Gary, 
Thanks for reply, then SPDXID will be mostly internal ID and can not be referenced externally, Do you think this might need some change in SPDXID documentation statement  ? 

"Uniquely identify any element in an SPDX document which may be referenced by other elements. These may be referenced internally and externally with the addition of the SPDX document identifier."


Regards
Sandeep 


FYI: SPDX in the OpenSSF Mobilization Plan

VM (Vicky) Brasseur
 

Some of you probably know that OpenSSF met with a bunch of US Federal organizations in Washington DC last week to discuss cyber security wrt the open source software supply chain. (our own Kate and William were there!)

 

Prior to that meeting, the OpenSSF community prepared a “mobilization plan” to present to the Feds, detailing ten areas where they feel they can make improvements to the security of the overall ecosystem. The ninth area is “SBOMs Everywhere” and specifically calls for working with SPDX.

 

You can download the complete plan here: https://openssf.org/oss-security-mobilization-plan/

 

--V

 

-- 

VM (Vicky) Brasseur

Director, Senior Strategy Advisor

Open Source Program Office

Wipro Limited

Time Zone: Pacific/West Coast US

 

'The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com'

Internal to Wipro


Re: SPDXID #spdx

Gary O'Neall
 

Hi Sandeep – Moving the conversation over to the SPDX-tech mailing list.

 

Unfortunately, adding in a CPE ID or pURL would include characters disallowed in the SPDX ID.

 

Fortunately, there is a way to express the pURL and CPE ID in the SPDX Package using the ExternalRef property.  If you add these properties, tools such as the SPDX to OSV will pick up the references and use them to uniquely identify the packages.

 

Here’s an example in JSON format for a CPE 2.3 ID:

 

  "packages" : [ {

                   "SPDXID" : "SPDXRef-Package",

                   "externalRefs" : [ {

                     "referenceCategory" : "SECURITY",

                     "referenceLocator" : "cpe:2.3:a:pivotal_software:spring_framework:4.1.0:*:*:*:*:*:*:*",

                     "referenceType" : "cpe23Type"

                   },  …

 

See the ExternalRef subsection of the spec and the External Repository Identifiers Annex for more details.

 

Regards,
Gary

 

From: spdx@... <spdx@...> On Behalf Of Patil, Sandeep via lists.spdx.org
Sent: Monday, May 16, 2022 9:06 AM
To: spdx@...
Subject: [spdx] SPDXID #spdx

 

Hi , 
I have query regarding SPDXID , Can this be expressed along with CPE or pURL something like 

"SPDXRef-[cpe id]"   or  "SPDXRef-[pURL]"

Any further guidance on this will help. 

Regards
Sandeep 


Re: SPDX and NTIA SBOM Minimum elements #spdx

William Bartholomew (CELA)
 

This is how Microsoft has approached this:

https://devblogs.microsoft.com/engineering-at-microsoft/generating-software-bills-of-materials-sboms-with-spdx-at-microsoft/

 

The one thing I’d add is that additional identifiers would be stored in External References.

 

Regards,

 

William Bartholomew (he/him) – Let’s chat

Principal Security Strategist

Global Cybersecurity Policy – Microsoft

 

My working day may not be your working day. Please don’t feel obliged to reply to this e-mail outside of your normal working hours.

 

From: spdx@... <spdx@...> On Behalf Of Dick Brooks via lists.spdx.org
Sent: Monday, May 16, 2022 9:24 AM
To: spdx@...
Subject: [EXTERNAL] Re: [spdx] SPDX and NTIA SBOM Minimum elements #spdx

 

NTIA Framing document has the mapping you seek: see page 13

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

 

However the “EO 14028 NTIA min element list is a little different from the framing document list (see attached)

 

 

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: spdx@... <spdx@...> On Behalf Of Patil, Sandeep via lists.spdx.org
Sent: Monday, May 16, 2022 12:10 PM
To: spdx@...
Subject: [spdx] SPDX and NTIA SBOM Minimum elements #spdx

 

Hi , 
Is there any document reference which can be used to see mapping between SPDX tags and  NTIA Minimum elements ?  
Some element names can be easily confused , something like "Author of SBOM Data" in NTIA Minimum elements and "Creator" tag in SPDX are those same ? 

Regards
Sandeep 


Re: SPDX and NTIA SBOM Minimum elements #spdx

Dick Brooks
 

You’re welcome.

 

You will most likely need SPDX V2.3 if you have any “FILE” components that need to specify version info. The new PackagePurpose field supports the version info for “FILE” artifacts.

 

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: spdx@... <spdx@...> On Behalf Of Patil, Sandeep via lists.spdx.org
Sent: Monday, May 16, 2022 12:31 PM
To: spdx@...
Subject: Re: [spdx] SPDX and NTIA SBOM Minimum elements #spdx

 

Thanks you Dick, This is useful

 

From: spdx@... <spdx@...> On Behalf Of Dick Brooks via lists.spdx.org
Sent: Monday, May 16, 2022 9:54 PM
To: spdx@...
Subject: Re: [spdx] SPDX and NTIA SBOM Minimum elements #spdx

 

Caution: This e-mail originated from outside of Philips, be careful for phishing.

 

NTIA Framing document has the mapping you seek: see page 13

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

 

However the “EO 14028 NTIA min element list is a little different from the framing document list (see attached)

 

 

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: spdx@... <spdx@...> On Behalf Of Patil, Sandeep via lists.spdx.org
Sent: Monday, May 16, 2022 12:10 PM
To: spdx@...
Subject: [spdx] SPDX and NTIA SBOM Minimum elements #spdx

 

Hi , 
Is there any document reference which can be used to see mapping between SPDX tags and  NTIA Minimum elements ?  
Some element names can be easily confused , something like "Author of SBOM Data" in NTIA Minimum elements and "Creator" tag in SPDX are those same ? 

Regards
Sandeep 

 


The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.


Re: SPDX and NTIA SBOM Minimum elements #spdx

Patil, Sandeep
 

Thanks you Dick, This is useful

 

From: spdx@... <spdx@...> On Behalf Of Dick Brooks via lists.spdx.org
Sent: Monday, May 16, 2022 9:54 PM
To: spdx@...
Subject: Re: [spdx] SPDX and NTIA SBOM Minimum elements #spdx

 

Caution: This e-mail originated from outside of Philips, be careful for phishing.

 

NTIA Framing document has the mapping you seek: see page 13

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

 

However the “EO 14028 NTIA min element list is a little different from the framing document list (see attached)

 

 

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: spdx@... <spdx@...> On Behalf Of Patil, Sandeep via lists.spdx.org
Sent: Monday, May 16, 2022 12:10 PM
To: spdx@...
Subject: [spdx] SPDX and NTIA SBOM Minimum elements #spdx

 

Hi , 
Is there any document reference which can be used to see mapping between SPDX tags and  NTIA Minimum elements ?  
Some element names can be easily confused , something like "Author of SBOM Data" in NTIA Minimum elements and "Creator" tag in SPDX are those same ? 

Regards
Sandeep 



The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.


Re: SPDX and NTIA SBOM Minimum elements #spdx

Dick Brooks
 

NTIA Framing document has the mapping you seek: see page 13

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

 

However the “EO 14028 NTIA min element list is a little different from the framing document list (see attached)

 

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: spdx@... <spdx@...> On Behalf Of Patil, Sandeep via lists.spdx.org
Sent: Monday, May 16, 2022 12:10 PM
To: spdx@...
Subject: [spdx] SPDX and NTIA SBOM Minimum elements #spdx

 

Hi , 
Is there any document reference which can be used to see mapping between SPDX tags and  NTIA Minimum elements ?  
Some element names can be easily confused , something like "Author of SBOM Data" in NTIA Minimum elements and "Creator" tag in SPDX are those same ? 

Regards
Sandeep 


SPDX and NTIA SBOM Minimum elements #spdx

Patil, Sandeep
 

Hi , 
Is there any document reference which can be used to see mapping between SPDX tags and  NTIA Minimum elements ?  
Some element names can be easily confused , something like "Author of SBOM Data" in NTIA Minimum elements and "Creator" tag in SPDX are those same ? 

Regards
Sandeep 


SPDXID #spdx

Patil, Sandeep
 

Hi , 
I have query regarding SPDXID , Can this be expressed along with CPE or pURL something like 

"SPDXRef-[cpe id]"   or  "SPDXRef-[pURL]"

Any further guidance on this will help. 

Regards
Sandeep 


Re: End Of Life Tag in spdx #spdx

Dick Brooks
 

Kate and Sandeep,

 

Our customers are also interested in this information. There are two concepts to consider:

Commercial Status:

        <enumeration value="Available"></enumeration>

        <enumeration value="Retired"></enumeration>

        <enumeration value="EOL"></enumeration>

        <enumeration value="BetaTest"></enumeration>

        <enumeration value="Pilot"></enumeration>

        <enumeration value="Abandoned"></enumeration>

 

Support Status:

        <enumeration value="Supported"></enumeration>
        <enumeration value="Unsupported"></enumeration>
        <enumeration value="Community"></enumeration>

 

Both are described in the open-source Vendor Response File (VRF) XML schema available here: https://raw.githubusercontent.com/rjb4standards/REA-Products/master/SAGVendorSchema.xsd

 

 

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: spdx@... <spdx@...> On Behalf Of Kate Stewart
Sent: Friday, May 6, 2022 3:34 PM
To: SPDX-general <spdx@...>
Subject: Re: [spdx] End Of Life Tag in spdx #spdx

 

Hi Sandeep,

 

     There is a pull request expected shortly from the Usage profile team, to add this specific field to 2.3.

When it comes in,  please feel free to review and make sure it's going to suffice for your needs.

 

For now, with 2.2 documents,  suggest you use the Package Comment field (https://spdx.github.io/spdx-spec/package-information/#720-package-comment-field) and standardize on a tag (like EndOfSupport: ) and the date. 

 

Will that work for now?

 

Thanks, 
Kate

 

On Fri, May 6, 2022 at 2:27 PM Patil, Sandeep via lists.spdx.org <sandeep.patil=philips.com@...> wrote:

Hi All, 
We have requirement to specify End Of Life as part of package information in SBoM ,
Is there way current SPDX format support this ? 

Regards
Sandeep 

61 - 80 of 1590