+1 “as long as the difference between SBOM-artifact and Bundle-artifact is clear”
I defer to the people doing this work for V 2.3 to provide this distinction. A satisfactory Executive Order 14028 solution following NIST SP 800-161 R2 Appendix F and NIST SSDF guidance from 2/4/2022 makes clear the need for software vendors to provide an NTIA compliant SBOM with minimum elements present per SBOM component, and some form of vulnerability reporting in order to meet EO 14028 requirements. I anticipate SPDX V 2.3 will address these items. Thanks, Dick Brooks <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™ <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com Email: <mailto:[email protected]> [email protected] Tel: +1 978-696-1788 From: David Kemp <[email protected]> Sent: Saturday, February 12, 2022 8:54 AM To: [email protected] Cc: SPDX-list <[email protected]> Subject: Re: [spdx-tech] FYI: Insights from an NTIA colleague, Chris Gates, re: vulnerability reporting Yes, a static pointer to a VEX server sounds great. I was concerned by "SBOMs and VEXs cannot occupy the same artifact". It doesn't seem like a defect in v1.3 if v1.4 creates a new container Bundle-artifact = [v1.3-artifact, VEX-content], as long as the difference between SBOM-artifact and Bundle-artifact is clear. ("same artifact" and "bundling them together" makes it sound as if v1.4 is not using a content server URL.) Dave On Sat, Feb 12, 2022 at 8:03 AM Dick Brooks <[email protected] <mailto:[email protected]> > wrote: 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:[email protected]> [email protected] Tel: +1 978-696-1788 From: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > On Behalf Of David Kemp Sent: Saturday, February 12, 2022 7:55 AM To: SPDX-list <[email protected] <mailto:[email protected]> > 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 <[email protected] <mailto:[email protected]> > 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: [email protected] <mailto:[email protected]> Tel: +1 978-696-1788 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4379): https://lists.spdx.org/g/Spdx-tech/message/4379 Mute This Topic: https://lists.spdx.org/mt/89092050/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
