Dave,
I can easily imagine an SPDX SBOM with an SBOM level data element to handle this scenario: VulnerabilityReport: https://github.com/rjb4standards/REA-Products/blob/master/SAGVulnDisclosureSAMPLE.xml VulnerabilityReportDigitalSignature: https://github.com/rjb4standards/REA-Products/blob/master/SAGVulnDisclosureSAMPLE.xml.sig This would allow an SPDX SBOM to remain static, while the content at the VulnerabilityReport link updates as needed along with the digital signature file whenever new vulnerabilities are reported by CISA, a vendor and others. A consumer could implement an automated process to check, daily, for changes to all of the VulnerabilityReports for products installed in their ecosystem, as part of a risk management strategy. I think this is what Chris Gates was eluding to with 3rd party databases that distribute SBOM’s and their associated Vulnerability Reports. Thanks, Dick Brooks <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™ <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com Email: <mailto:d...@reliableenergyanalytics.com> d...@reliableenergyanalytics.com Tel: +1 978-696-1788 From: Spdx-tech@lists.spdx.org <Spdx-tech@lists.spdx.org> On Behalf Of David Kemp Sent: Saturday, February 12, 2022 7:55 AM To: SPDX-list <Spdx-tech@lists.spdx.org> Subject: [spdx-tech] FYI: Insights from an NTIA colleague, Chris Gates, re: vulnerability reporting That depends on what one means by "bundling". If SBOMs are mostly static and VEXs are updated rapidly, then one can define a bundle structure holding them both, But it must be possible to update the bundle WITHOUT being forced to update the SBOM. If you call the outer structure SPDX instead of SPDX-Bundle, then it must have what CMS (https://datatracker.ietf.org/doc/html/rfc5652) calls "authenticated attributes" (the SBOM bits with a persistent identifier covered by an integrity mechanism) and "unauthenticated attributes" (the VEX bits that can be updated every minute without breaking integrity of the SBOM). Regards, Dave On Sat, Feb 12, 2022 at 7:31 AM Dick Brooks <d...@reliableenergyanalytics.com <mailto:d...@reliableenergyanalytics.com> > wrote: I just want you to know that your work on defects for V 2.3 is indeed important and useful. Here is what Chris had to say about vulnerability reporting in a recent email exchange: SBOMs are mostly static for a given build (yeah I know there are edge conditions here, but lets just go with this idea) VEXs are highly dynamic. QED SBOMs and VEXs cannot occupy the same artifact as they have two different time domains! WRONG! We were so wrapped up in the 'device delivers the SBOM' model, that we never thought far enough to realize, that 'NO' there are going to be online databases that can distribute SBOMs with VEXs that can change every minute. So while I was a huge proponent of CSAF, I have come to believe that the real answer is bundling them together such as CycloneDX v1.4 has done. Thanks, Dick Brooks Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: d...@reliableenergyanalytics.com <mailto:d...@reliableenergyanalytics.com> Tel: +1 978-696-1788 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4377): https://lists.spdx.org/g/Spdx-tech/message/4377 Mute This Topic: https://lists.spdx.org/mt/89092050/21656 Group Owner: spdx-tech+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
