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

[Lars Francke <lars.francke@xxxxxxxxx>]

Ah! Understood, thank you for the clarification.

Just to be clear: I'm in favor of basically zero responsibilities for
the open source projects itself.
Everything they do should be voluntarily and no one should be liable
for any errors they make in voluntary disclosures etc. (simplifying a
tiny bit).

And my "I'd like a VEX for every CVE" is of course wishful thinking.
That'll never happen.
But if manufactures would give that to me that'd be great.
It should be easy for them with the requirements they have to follow anyway.
They need a SBOM for every product they have.
They can then automatically create a not-affected VEX for every
vulnerability that is in a component which is not in their SBOM giving
me a piece of mind.

Cheers,
Lars

On Tue, Feb 18, 2025 at 3:51 PM Jeremy Stanley via
open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx>
wrote:
>
> 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
> _______________________________________________
> open-regulatory-compliance mailing list
> open-regulatory-compliance@xxxxxxxxxxx
> To unsubscribe from this list, visit https://accounts.eclipse.org