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

[Tobie Langel <tobie@xxxxxxxxxxxxxx>]

FWIW, the perspective of a number of open source communities is that SBOMs should be generated at the product level and don't belong in the individual projects themselves (unless those have CLI tools).

Here's the rationale for the _javascript_ community on this topic: https://github.com/openjs-foundation/security-collab-space/blob/main/OpenJS-SBOM-CSCRM-Challenges-Recommendations.md

--tobie

On Tue, Feb 18, 2025 at 4:14 PM Dick Brooks via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:

Jeremy,

I work almost exclusively on the consumer side, so my comments are
reflective of a consumers view.

Consumers need SBOM's in order to monitor for vulnerability risk in their
running ecosystems, so they can take mitigating action as needed.
An SBOM empowers consumers to monitor for vulnerabilities in products as new
vulnerabilities are reported. Only the original software producer can answer
the question authoritatively if a vulnerability affects their products and
that information is provided in a "Security Advisory" (i.e. CSAF profile 4)
and an online living Vulnerability Disclosure Report (VDR) that the software
producer maintains.

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! T
Risk always exists, but trust must be earned and awarded.T
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 10:01 AM
To: open-regulatory-compliance@xxxxxxxxxxx
Cc: 'Jeremy Stanley' <jeremy@xxxxxxxxxxxxx>
Subject: 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

_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org