|
Re: Where to put issues for "getting started with SPDX" documentation?
Alexios Zavras
May I propose something like github.com/spdx/help since “docs” covers a lot more things (even the specification itself). +1 on being a new, separate location.
-- zvr
From: spdx@... <spdx@...> On Behalf Of
VM (Vicky) Brasseur via lists.spdx.org
Sent: Thursday, 23 June, 2022 20:46 To: spdx@... Subject: Re: [spdx] Where to put issues for "getting started with SPDX" documentation?
GitHub is a given, which is why we decided to start opening issues rather than just maintaining a file.
I’d prefer to have either a dedicated docs repo or a /docs folder in another appropriate repo, so we can do the docs in docusaurus or some other static site generator type thing.
Which leaves us back at my initial question: Which repo to put this stuff in? My vote is a new spdx/docs repo.
--V
-- VM (Vicky) Brasseur Director, Senior Strategy Advisor Open Source Program Office Wipro Limited ⏰ Time Zone: Pacific/West Coast US
From:
<spdx@...> on behalf of "Manbeck, Jack via lists.spdx.org" <j-manbeck2=ti.com@...>
CAUTION:This email is received from an external domain. Open the hyperlink(s) & attachment(s) with caution.
Yes! I think this is a great idea. We’ve tried in the past to do this but could never get people “focused” on it. I agree its needed.
I vote to put it the list in GitHub. The wiki doesn’t seem to be used much anymore. I would create a repo for “getting started” collateral. Besides the questions we could add examples and other documents over time. The someone can just grab it when they want to get started,
We do have a FAQ: https://spdx.dev/faq/ that may have some good info as well if you have not seen it.
Jack Manbeck
Howdy, team.
In last week’s Outreach call we discussed the lack of “getting started with SPDX” documentation, info that could take someone from Zero to SPDX. Currently it’s really hard for new people to show up and use/generate/understand SPDX, but we can (with time) fix that.
We decided that step one of this would be to start collecting ideas for newbie questions that’ll need answering, etc. We’ll do this in issues to make it easier to keep track of them.
The next question is…where should those issues go? The -spec repo isn’t a good fit for them, neither is outreach. Do we perhaps need a new -docs repo…? I don’t know, but it’s worth considering. Or is this premature optimization and we should just pick a repo to log the issues in and then move them later if needed?
So what do y’all think? Where should these issues go for now?
--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 '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 Intel Deutschland GmbH |
||||||||||
|
|
||||||||||
|
Re: Where to put issues for "getting started with SPDX" documentation?
VM (Vicky) Brasseur
GitHub is a given, which is why we decided to start opening issues rather than just maintaining a file.
I’d prefer to have either a dedicated docs repo or a /docs folder in another appropriate repo, so we can do the docs in docusaurus or some other static site generator type thing.
Which leaves us back at my initial question: Which repo to put this stuff in? My vote is a new spdx/docs repo.
--V
-- VM (Vicky) Brasseur Director, Senior Strategy Advisor Open Source Program Office Wipro Limited ⏰ Time Zone: Pacific/West Coast US
From:
<spdx@...> on behalf of "Manbeck, Jack via lists.spdx.org" <j-manbeck2=ti.com@...>
CAUTION:This email is received from an external domain. Open the hyperlink(s) & attachment(s) with caution.
Yes! I think this is a great idea. We’ve tried in the past to do this but could never get people “focused” on it. I agree its needed.
I vote to put it the list in GitHub. The wiki doesn’t seem to be used much anymore. I would create a repo for “getting started” collateral. Besides the questions we could add examples and other documents over time. The someone can just grab it when they want to get started,
We do have a FAQ: https://spdx.dev/faq/ that may have some good info as well if you have not seen it.
Jack Manbeck
From: spdx@... <spdx@...>
On Behalf Of VM (Vicky) Brasseur via lists.spdx.org
Sent: Tuesday, June 21, 2022 1:48 PM To: spdx@... Subject: [EXTERNAL] [spdx] Where to put issues for "getting started with SPDX" documentation?
Howdy, team.
In last week’s Outreach call we discussed the lack of “getting started with SPDX” documentation, info that could take someone from Zero to SPDX. Currently it’s really hard for new people to show up and use/generate/understand SPDX, but we can (with time) fix that.
We decided that step one of this would be to start collecting ideas for newbie questions that’ll need answering, etc. We’ll do this in issues to make it easier to keep track of them.
The next question is…where should those issues go? The -spec repo isn’t a good fit for them, neither is outreach. Do we perhaps need a new -docs repo…? I don’t know, but it’s worth considering. Or is this premature optimization and we should just pick a repo to log the issues in and then move them later if needed?
So what do y’all think? Where should these issues go for now?
--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
Internal to Wipro |
||||||||||
|
|
||||||||||
|
License Type for Commercial Components
#spdx
Patil, Sandeep
Hi ,
What is the license type that needs be used in spdx for 3rd parties with proprietary licenses (e.g., Microsoft)? |
||||||||||
|
|
||||||||||
|
Re: Where to put issues for "getting started with SPDX" documentation?
Manbeck, Jack
Yes! I think this is a great idea. We’ve tried in the past to do this but could never get people “focused” on it. I agree its needed.
I vote to put it the list in GitHub. The wiki doesn’t seem to be used much anymore. I would create a repo for “getting started” collateral. Besides the questions we could add examples and other documents over time. The someone can just grab it when they want to get started,
We do have a FAQ: https://spdx.dev/faq/ that may have some good info as well if you have not seen it.
Jack Manbeck
From: spdx@... <spdx@...> On Behalf Of
VM (Vicky) Brasseur via lists.spdx.org
Sent: Tuesday, June 21, 2022 1:48 PM To: spdx@... Subject: [EXTERNAL] [spdx] Where to put issues for "getting started with SPDX" documentation?
Howdy, team.
In last week’s Outreach call we discussed the lack of “getting started with SPDX” documentation, info that could take someone from Zero to SPDX. Currently it’s really hard for new people to show up and use/generate/understand SPDX, but we can (with time) fix that.
We decided that step one of this would be to start collecting ideas for newbie questions that’ll need answering, etc. We’ll do this in issues to make it easier to keep track of them.
The next question is…where should those issues go? The -spec repo isn’t a good fit for them, neither is outreach. Do we perhaps need a new -docs repo…? I don’t know, but it’s worth considering. Or is this premature optimization and we should just pick a repo to log the issues in and then move them later if needed?
So what do y’all think? Where should these issues go for now?
--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: Where to put issues for "getting started with SPDX" documentation?
William Bartholomew (CELA)
I would put them in the spdx-spec repository, and we can label them as docs. One of the reasons for this is it allows us to address issues holistically, for example, the right thing to do might be to clarify the spec, create samples, and write new docs.
I was experimenting with some new getting started documentation, you can see some examples here: https://iamwillbar.github.io/spdx-spec/v2.2.2/use-cases/sbom/ https://iamwillbar.github.io/spdx-spec/v2.2.2/use-cases/third-party/ https://iamwillbar.github.io/spdx-spec/v2.2.2/use-cases/vulnerability-management/
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
VM (Vicky) Brasseur via lists.spdx.org
Sent: Tuesday, June 21, 2022 10:48 AM To: spdx@... Subject: [EXTERNAL] [spdx] Where to put issues for "getting started with SPDX" documentation?
Howdy, team.
In last week’s Outreach call we discussed the lack of “getting started with SPDX” documentation, info that could take someone from Zero to SPDX. Currently it’s really hard for new people to show up and use/generate/understand SPDX, but we can (with time) fix that.
We decided that step one of this would be to start collecting ideas for newbie questions that’ll need answering, etc. We’ll do this in issues to make it easier to keep track of them.
The next question is…where should those issues go? The -spec repo isn’t a good fit for them, neither is outreach. Do we perhaps need a new -docs repo…? I don’t know, but it’s worth considering. Or is this premature optimization and we should just pick a repo to log the issues in and then move them later if needed?
So what do y’all think? Where should these issues go for now?
--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 |
||||||||||
|
|
||||||||||
|
Where to put issues for "getting started with SPDX" documentation?
VM (Vicky) Brasseur
Howdy, team.
In last week’s Outreach call we discussed the lack of “getting started with SPDX” documentation, info that could take someone from Zero to SPDX. Currently it’s really hard for new people to show up and use/generate/understand SPDX, but we can (with time) fix that.
We decided that step one of this would be to start collecting ideas for newbie questions that’ll need answering, etc. We’ll do this in issues to make it easier to keep track of them.
The next question is…where should those issues go? The -spec repo isn’t a good fit for them, neither is outreach. Do we perhaps need a new -docs repo…? I don’t know, but it’s worth considering. Or is this premature optimization and we should just pick a repo to log the issues in and then move them later if needed?
So what do y’all think? Where should these issues go for now?
--V
-- VM (Vicky) Brasseur Director, Senior Strategy Advisor Open Source Program Office Wipro Limited ⏰ Time Zone: Pacific/West Coast US
Internal to Wipro |
||||||||||
|
|
||||||||||
|
Re: [spdx-defects] [spdx] VEX integration in SPDX
#spdx
Sandeep,
A good example of a VEX advisory is provided by Siemens in their log4j advisory: https://cert-portal.siemens.com/productcert/csaf/ssa-661247.json
NOTE: VEX’s are vulnerability centric, where a vulnerability is reported and a vendor issues a VEX.
It’s important to note that a VEX is very different from a product centric vulnerability disclosure report (VDR) which NIST requires for Executive Order 14028.
If you plan to sell products to the US Government then you will need to follow NIST’s requirements for Executive Order 14028:
“Maintain vendor vulnerability disclosure reports at the SBOM component level “
Here is the difference between a VEX and a VDR (attestation). A VEX is an artifact showing the status of vulnerabilities within a product or products. Components with no vulnerabilities are not listed in a VEX, unless there is a "known not affected" status listed in the VEX. A VDR is an attestation by a software vendor that they have checked each component of a software product in an SBOM for vulnerabilities and reports on the vulnerability status of each component, for a software product. A VDR is dynamically updated and maintained by the software vendor in order to answer the consumer question "What is the vulnerability status of Product P, NOW?"
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 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
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 |
||||||||||
|
|
