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

["Dick Brooks" <dick@xxxxxxxxxxxxxxxxxxxxxxxxx>]

Tobie,

 

That is consistent with my observations also; embedded components within a distributed product frequently do not provide SBOM’s.

 

Here is the SBOM for the open source product that my Company supports and maintains. Note the SBOM lists the “primary component”, which is the product and the embedded open source components that are contained in the product:

https://raw.githubusercontent.com/rjb4standards/CISASAGReader/refs/heads/main/CISASAGReader-V1_0_4-SBOM.json

 

Also notice, the SBOM “primary component”, sag-reader, contains a link to the associated Vulnerability Disclosure Report (VDR), identified as an external reference, security advisory URL

"name": "sag-reader",

"versionInfo": "1.0.4",

"primaryPackagePurpose": "APPLICATION",

"supplier": "Organization: BUSINESS CYBER GUARDIAN (Reliable Energy Analytics LLC)"

"referenceCategory": "SECURITY",

"referenceType": "advisory",

"referenceLocator": "https://raw.githubusercontent.com/rjb4standards/CISASAGReader/refs/heads/main/CISASAGReader-V1_0_4-VDR.json"

 

 

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 Tobie Langel via open-regulatory-compliance
Sent: Tuesday, February 18, 2025 3:52 PM
To: Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx>
Cc: Tobie Langel <tobie@xxxxxxxxxxxxxx>
Subject: Re: [open-regulatory-compliance] CRA Standardisation request

 

On Tue, Feb 18, 2025 at 9:37 PM Jeremy Stanley via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:

On 2025-02-18 12:00:53 -0800 (-0800), Scott Lewis via open-regulatory-compliance wrote:
[...]
> Admittedly it's valuable...but it's also *static*.  Just the fact that in
> osgi/p2 acceptable version *ranges* constraints are given for dependencies
> means that the target environment (i.e. what else is present at install time
> as well as what repos are know/available) will determine the dependency
> resolution....i.e. what version of a dependency is resolved dynamically at
> install time.
[...]
So for the most part, from where I sit, upstream open source
projects shouldn't need to mess with explicitly creating, tracking
and publishing SBOMs. If consumers want an SBOM or similar record of
what's in installable artifacts like container images or packages,
then the build tools and installers are where that sort of
functionality should be added. It should be basically transparent
upstream. When it comes to being aware of vulnerabilities in
components shipped in these artifacts and tracked in those
auto-generated SBOMs, such scans can be performed on the artifacts
post-build or in build dry-run processes, where the actual versions
of included components are known and don't have to be predicted.

 

This is very much aligned with my understanding too. However, given multiple discussions I have had on this topic and the conversation we had here, it is clear that this needs more research to arrive at a common understanding even before considering building consensus.

 

As discussed during the workshop, a good step forward here would be to create a whitepaper that helps clarify what problems SBOMs are solving and how they should be implemented to do so.

 

--tobie