If VEX is as easy as some people are saying, then why did Cassie Crossly make the statements she made about her experiences with VEX?
Was she doing it wrong, which led to her statements?
How is a vendor going to answer the justification and impact data requirements without conducting actual research into the reasons why a product is not affected by a vulnerability.
As Lars indicated VEX does not appear to be a requirement of the EU CRA, so this may be all moot.
But, there is an open question IMO, what information will a vendor need to provide proving they did indeed check a product for vulnerabilities and there were no expolitable vulnerabilities present before releasing a product to market, as the EU CRA requires?
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
From: open-regulatory-compliance <open-regulatory-compliance-bounces@xxxxxxxxxxx> On Behalf Of Daniel Thompson-Yvetot via open-regulatory-compliance
Sent: Tuesday, February 18, 2025 4:09 AM
To: Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx>
Cc: Daniel Thompson-Yvetot <denjell@xxxxxxxxxxxxxx>
Subject: Re: [open-regulatory-compliance] CRA Standardisation request
I absolutely agree with Lars.
Ignoring terminology of stewards and oss and manufacturers for a moment, it seems to me that being part of a community means having an SBOM and publishing CVEs and reporting VEXs. Just like signing commits, not a hard requirement of a community, but definitely a signal of craftspersonship.
Hi Jeremy,
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. Please tell me so if
that is the case and I'll try again.
I was only arguing Dick's point that VEX are hard to create. My point
is that they often are a trivial byproduct of a vulnerability
management process you have to do anyway as a manufacturer.
It sounds like you are speaking as an open source maintainer/steward?
That is different, you have no obligation to produce a SBOM under the
CRA.
That might be part of the confusion between me and Dick as well:
Manufacturer vs. steward/OS project and also CRA obligation vs. "nice
to have".
I do appreciate and understand that it's not entirely clear yet in all
cases whether a project could be classified as a "manufacturer" but
personally I'd assume this not to be the case for most OSS projects.
A not-affected VEX for me is a nice to have that is trivial to create
but it is not mandatory as per the CRA as far as I can tell.
That is to say: I do not expect to ship a VEX for every single
vulnerability, only for those that I investigated because why not. The
work is already done.
It's entirely possible that I'm wrong with everything I'm saying ;-)
Cheers,
Lars
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)?
> --
> Jeremy Stanley
> _______________________________________________
> open-regulatory-compliance mailing list
> open-regulatory-compliance@xxxxxxxxxxx
> To unsubscribe from this list, visit https://accounts.eclipse.org
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
