| Re: [open-regulatory-compliance] CRA Standardisation request |
On 2025-02-18 09:44:02 -0500 (-0500), Dick Brooks wrote: > In my experience, it is not difficult to produce an SBOM and Vulnerability Disclosure Report (VDR), now called Vulnerability Advisory Report (VAR) by NIST SP 800-161-r1-upd1. > > I provide SBOM and VDR artifacts for an open source project I support, along with level of effort, in time, to produce each artifact within the README.md to serve as one example: > https://github.com/rjb4standards/CISASAGReader [I've given up trying to repair everyone's top-posting, see the list archive instead for prior context.] Maybe you didn't read my earlier posts you quoted, but why (and how) should a project that doesn't ship any compiled or aggregated artifacts embedding third-party software incorporate an SBOM? Is there something inherently wrong with not having an SBOM in the (rather common) case that an open source project distributes nothing other than its own code? I'm not sure if it's because there's a lot of companies who see a profit opportunity in supplying SBOM creation and auditing tools, but there's an inordinate focus on SBOMs in these discussions when, at least from my traditional upstream community open source and steward organization perspective, it seems like something for commercial manufacturers downstream to concern themselves with. I just want to make sure 1. I'm not missing something that's obvious to others which open source communities and stewards need to be doing in regard to SBOMs, and 2. we don't produce guidelines or draft standards that shift the perceived burden for SBOM-oriented activities upstream from the manufacturers to the stewards. -- Jeremy Stanley
Attachment:
signature.asc
Description: PGP signature