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

[Daniel Thompson-Yvetot <denjell@xxxxxxxxxxxxxx>]

@Tobie - if you think the lack of idempotency for libraries is troubling, wait til you hear about the new techniques around module federation. ;)

But seriously I think the text is a copout from the JS sec team. I agree with Dick, some knowledge is better than none, e.g. in practice, I don’t care what version of jquery is used, if it is in your package.json / lockfile / reposource I will deep dive.

I feel that their analysis is missing the fact that a library’s entire dependency tree can be inferred from the package.JSON - and that information IS valuable.

The guarantee of a library is that it will never have dependencies other than direct, indirect, or transitive. Maybe the lesson here is that a library should “presolve” for a known range of upstream library versions that are expected to be viable.

Thanks for sharing the doc!

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

Tobie,

 

The rule of thumb we follow with regard to what goes into an SBOM that is delivered to consumers is to list any component that could potentially have a vulnerability reported via a vulnerability repository or privately.

 

For example, many vulnerabilities are not reported at the “source code level”, i.e. foo.h has a vulnerability. However the distributed component called FOO that contains foo.h should be listed in an SBOM.The “application” AllFOO, which contains the FOO component should also be listed as it may have reportable vulnerabilities.

 

In summary, based on my experiences:

 

IMO, A software producer should list all components contained in a “distributed package” (application, container, etc) within the SBOM that is used/installed by customers which could be listed in a vulnerability repository, i.e. NIST NVD, as containing a vulnerability.

 

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

 

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

Pythons approach to distributing SBOM's has worked well for our purposes at BCG.

 

Dick, I'm curious if you have any thoughts as to how the _javascript_ community should address the issues it raised in the document I linked earlier, in particular the problem that dependency resolution isn't idempotent.

 

I understand that distributing SBOMs works well in certain contexts, but we also have to understand and address the cases where it doesn't work or creates bad outcomes.

 

--tobie

 

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