[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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
Attachment:
signature.asc
Description: PGP signature