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

["Dick Brooks" <dick@xxxxxxxxxxxxxxxxxxxxxxxxx>]

One example of SBOM guidance is provided by the US CISA SCRM Software Acquisition Guide (SAG) for US Government Agencies:

https://www.cisa.gov/sites/default/files/2024-07/PDM24050%20Software%20Acquisition%20Guide%20for%20Government%20Enterprise%20ConsumersV2_508c.pdf 

" CONTROL.GOV.09 Does the supplier provide a machine-readable SBOM meeting minimum requirements defined by National Telecommunications Information Administration (NTIA) or successor guidance as published by CISA that covers all software components of the product being delivered to the customer organization?"

There are several points throughout the CISA SAG document referring to SBOM usage suggestions.

This is NOT a proposal for EU CRA - this is just to raise awareness about how SBOM is being applied in practice by others. Pythons approach to distributing SBOM's has worked well for our purposes at BCG. 

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 Jimmy Ahlberg via open-regulatory-compliance
Sent: Tuesday, February 18, 2025 11:49 AM
To: Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx>
Cc: Jimmy Ahlberg <jimmy.ahlberg@xxxxxxxxxxxx>
Subject: Re: [open-regulatory-compliance] CRA Standardisation request

Depending on what format/standard that SBOM is in, it may be very useful for everyone consuming that when building their own SBOM, where these single packages becomes just one among many. 😊

Purely my personal view below, feel free to disagree, but I do want to highlight that this is not necessarily the opinion of the company I work for.

I would not say that I as a corporate user of the open source component would require the existence of these SBOMs, but when they exist, in a format I can use, I will certainly apricate it, and it may be a advantage for projects that supply that compared to those that do not. Sorry, a somewhat crass view on this, but open source components that supply artifacts (Such as SBOMs, contact details, and verification that they have received proposed fixes to existing vulnerabilities in accordance with art 13(6)), are more likely to be used in commercial products as the "cost" of using them will be lower. If that is a goal for that project or not (to be as widely used as possible in a products eventually put on the EU market) is up to the project to determine.

 BR J

-----Original Message-----
From: open-regulatory-compliance <open-regulatory-compliance-bounces@xxxxxxxxxxx> On Behalf Of 'Jeremy Stanley' via open-regulatory-compliance
Sent: den 18 februari 2025 16:34
To: open-regulatory-compliance@xxxxxxxxxxx
Cc: 'Jeremy Stanley' <jeremy@xxxxxxxxxxxxx>
Subject: Re: [open-regulatory-compliance] CRA Standardisation request

On 2025-02-18 10:14:47 -0500 (-0500), Dick Brooks wrote:
[...]
> 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.

I'm starting to get the impression that one of us doesn't understand what an SBOM is for, and maybe that someone is me.

Let's say you, as a consumer, install a pure-Python open source project from PyPI, e.g. https://pypi.org/p/bindep which has no compiled extensions. Would you expect that package to contain an SBOM, and if so what would go in it? Should the package state that it contains only the program it packages and nothing else?

Let's say you, as a consumer, install the same project from its upstream Git repository at https://opendev.org/opendev/bindep rather than retrieving a package. Would you expect that Git repository to contain an SBOM, and if so what would go in it? Should the repository state that it contains only itself?

Should every open source project add (often empty or one-line) SBOMs to their revision control systems and source distributions?

I would posit that your "only the original software producer can answer the question authoritatively if a vulnerability affects their products" is incorrect, and you are conflating the original software producer with downstream distributors who supply compiled, integrated or aggregated versions of that software to their customers as part of some product. Only the manufacturer of the product that contains that software knows how it was compiled, patched or altered in order to incorporate it into their product, so only they can answer the question authoritatively if a vulnerability affects their products. As an upstream software maintainer I lack the visibility into their products, any relationship with their customers, and hence responsibility for that.
--
Jeremy Stanley
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org