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