Re: [open-regulatory-compliance] CRA Standardisation request

["Dick Brooks" <dick@xxxxxxxxxxxxxxxxxxxxxxxxx>]

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 

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! ™
Risk always exists, but trust must be earned and awarded.™ 
https://businesscyberguardian.com/ 
Email: dick@xxxxxxxxxxxxxxxxxxxxxxxxx
Tel: +1 978-696-1788


-----Original Message-----
From: open-regulatory-compliance <open-regulatory-compliance-bounces@xxxxxxxxxxx> On Behalf Of Jeremy Stanley via open-regulatory-compliance
Sent: Tuesday, February 18, 2025 9:35 AM
To: open-regulatory-compliance@xxxxxxxxxxx
Cc: Jeremy Stanley <jeremy@xxxxxxxxxxxxx>
Subject: Re: [open-regulatory-compliance] CRA Standardisation request

On 2025-02-18 09:53:47 +0100 (+0100), Lars Francke wrote:
> On Mon, Feb 17, 2025 at 5:51 PM Jeremy Stanley via 
> open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx>
> wrote:
> >
> > On 2025-02-17 14:22:38 +0100 (+0100), Lars Francke via open-regulatory-compliance wrote:
> > [...]
> > > And for companies who do NOT provide an SBOM it might be nice to 
> > > issue not-affected VEX for everything they become aware of because 
> > > I have no insight as a user what might be hiding in their software.
> > [...]
> >
> > When coupled with other suggestions that the expectations should be 
> > the same for upstream open source projects, this becomes 
> > exceptionally problematic.
> >
> > The projects I'm involved in expressly avoid distributing 
> > compiled/binary artifacts or production-ready container images in 
> > order to not be liable for tracking and reporting on vulnerabilities 
> > in dependencies we don't produce, because (among other reasons) we 
> > lack the people and time to do a proper job of it. Instead we leave 
> > that to downstream organizations interested in commercially 
> > productizing the software our communities collaborate on creating.
> > My understanding was that projects who don't produce products 
> > containing other projects wouldn't need an SBOM, but the only way I 
> > can see to satisfy your expectation here is for such projects to all 
> > produce empty SBOMs (or an SBOM that states that the project 
> > contains only itself).
> >
> > How do you personally see rectifying the need for a nak about 
> > vulnerabilities in projects which don't distribute other projects'
> > software? Do you consider that to be a "special case" (from where I 
> > sit, it doesn't seem that uncommon at all)?
> 
> I am afraid I don't fully understand what you mean to be honest which 
> is why my answer might not make sense to you.
[...]

I'll try to restate. I was mainly responding to your (quoted) assertion that not providing an SBOM meant you would prefer a negative VEX "for everything they become aware of" (within what limits? there are rather a lot of CVEs issued every year, the vast majority of which don't affect my projects because they have nothing to do with my projects).

More to the point, there have been suggestions on the part of more than one thread participant now that upstream projects should try to do what's expected of manufacturers in order to reduce the burden on manufacturers, and also that there's something wrong with not supplying an SBOM. It's the combination of these opinions which worries me, and I want to do what I can to make sure that this mindset doesn't leak into the guidelines and draft standards we produce for open source stewards and, by extension, the community-run projects they may represent.
--
Jeremy Stanley