|
Re: [spdx-defects] [spdx] VEX integration in SPDX
#spdx
Jeff Schutt (jefschut)
Hi Sandeep,
To add to Rose’s comments…
For version 2.3, the new Advisory identifier (F.2.3) is a catch-all that will enable linking to any VEX information, e.g., as contained within OSV or CSAF file.
We’re currently working on further security vulnerability information integrations with version 3.0 of the SPDX spec and would welcome your contributions :) Meetings are Wednesdays at 11am PT.
Jeff
From: <spdx@...> on behalf of "Rose Judge via lists.spdx.org" <rjudge=vmware.com@...>
Hi Sandeep,
The SPDX Defects working group announced security enhancements to the ExternalReference section of the spec as well as an explanatory Annex about how to include security information in an SPDX document. These changes apply to spec version 2.3 which should be released by the end of the month.
In order to include security/vulnerability information in 2.3, you will want to use the SECURITY ExternalReference Type. When using this format, there’s several security identifiers available: cpe22type, cpe23type, advisory, fix, url or swid that you can use to reference a VEX document. You can see examples of how this might be done in the link to Annex G above.
I’m also adding the SPDX Defects workgroup to the CC in case you have any further questions.
Thanks, Rose
|
||||||||||
|
|
||||||||||
|
Re: SPDX Thurs General Meeting Reminder
Hoping this is recorded – I have another unmovable meeting at this time!
Ria
From: spdx@... <spdx@...>
On Behalf Of Phil Odence via lists.spdx.org
Sent: Wednesday, June 1, 2022 11:36 AM To: SPDX-general <spdx@...> Subject: [spdx] SPDX Thurs General Meeting Reminder
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
Join the meeting:
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
Legal Team Report – Jilayne/Paul/Steve
Outreach/Website Team Report – Jack/Sebastian
|
||||||||||
|
|
||||||||||
|
Re: SPDX Thurs General Meeting Reminder
J Lovejoy
It was not recorded and I don’t think we’ve ever really done that for general meetings specifically nor for other meetings for the most part (not to say we can’t, but that has been and is the current reality for 10+ years!)
toggle quoted message
Show quoted text
|
||||||||||
|
|
||||||||||
|
Re: [spdx-defects] [spdx] VEX integration in SPDX
#spdx
Sandeep,
NIST also recommends that vendors and consumers “Maintain vendor vulnerability disclosure reports at the SBOM component level.” See 5/5 guidance:
SPDX V 2.3 supports both VEX and Vulnerability Disclosure Reports (VDR), in support of the NIST recommendations for Executive Order 14028.
Here’s an example SPDX V 2.3 reference to a VDR:
ExternalRef SECURITY advisory https://github.com/rjb4standards/REA-Products/blob/master/SBOMVDR_JSON/VDR_118.json
Here’s an example SPDX V 2.3 reference to a VEX:
ExternalRef SECURITY advisory https://cert-portal.siemens.com/productcert/csaf/ssa-661247.json
Here’s an explanation of the difference between VEX and VDR:
In summary a VEX is an artifact showing the status of vulnerabilities within a product. Components with no vulnerabilities are not listed in a VEX, unless there is a "known not affected" product status contained in the VEX.
In summary, a VDR is an attestation by a software vendor that they have checked each component in a software product SBOM for vulnerabilities and reports on the vulnerability status of each component, for a software product.
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-defects@... <spdx-defects@...> On Behalf Of Jeff Schutt (jefschut) via lists.spdx.org
Sent: Thursday, June 2, 2022 1:40 PM To: spdx@...; sandeep.patil@...; spdx-defects@... Subject: Re: [spdx-defects] [spdx] VEX integration in SPDX #spdx
Hi Sandeep,
To add to Rose’s comments…
For version 2.3, the new Advisory identifier (F.2.3) is a catch-all that will enable linking to any VEX information, e.g., as contained within OSV or CSAF file.
We’re currently working on further security vulnerability information integrations with version 3.0 of the SPDX spec and would welcome your contributions :) Meetings are Wednesdays at 11am PT.
Jeff
From: <spdx@...> on behalf of "Rose Judge via lists.spdx.org" <rjudge=vmware.com@...>
Hi Sandeep,
The SPDX Defects working group announced security enhancements to the ExternalReference section of the spec as well as an explanatory Annex about how to include security information in an SPDX document. These changes apply to spec version 2.3 which should be released by the end of the month.
In order to include security/vulnerability information in 2.3, you will want to use the SECURITY ExternalReference Type. When using this format, there’s several security identifiers available: cpe22type, cpe23type, advisory, fix, url or swid that you can use to reference a VEX document. You can see examples of how this might be done in the link to Annex G above.
I’m also adding the SPDX Defects workgroup to the CC in case you have any further questions.
Thanks, Rose
|
||||||||||
|
|
||||||||||
|
Re: [spdx-defects] [spdx] VEX integration in SPDX
#spdx
Rose Judge
Hi Sandeep,
The SPDX Defects working group announced security enhancements to the ExternalReference section of the spec as well as an explanatory Annex about how to include security information in an SPDX document. These changes apply to spec version 2.3 which should be released by the end of the month.
In order to include security/vulnerability information in 2.3, you will want to use the SECURITY ExternalReference Type. When using this format, there’s several security identifiers available: cpe22type, cpe23type, advisory, fix, url or swid that you can use to reference a VEX document. You can see examples of how this might be done in the link to Annex G above.
I’m also adding the SPDX Defects workgroup to the CC in case you have any further questions.
Thanks, Rose
|
||||||||||
|
|
||||||||||
|
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:
|
||||||||||
|
|
||||||||||
|
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
Join the meeting:
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
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:
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, |
||||||||||
|
|
||||||||||
|
Re: End Of Life Tag in spdx
#spdx
Kate Stewart
On Fri, May 20, 2022 at 2:32 AM Steve Kilbane <stephen.kilbane@...> wrote:
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
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:
“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
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
-- Armijn Hemel, MScTjaldur Software Governance Solutions |
||||||||||
|
|
||||||||||
|
Re: 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
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
-- Armijn Hemel, MSc Tjaldur Software Governance Solutions |
||||||||||
|
|
||||||||||
|
Re: End Of Life Tag in spdx
#spdx
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
-- 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
-- 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,
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, |
||||||||||
|
|
||||||||||
|
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
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,
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 , |
||||||||||
|
|
||||||||||
|
Re: SPDX and NTIA SBOM Minimum elements
#spdx
William Bartholomew (CELA)
This is how Microsoft has approached this:
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
Hi , |
||||||||||
|
|
||||||||||
|
Re: SPDX and NTIA SBOM Minimum elements
#spdx
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
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
Hi ,
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. |
||||||||||
|
|
