| Re: [open-regulatory-compliance] CRA Standardisation request |
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> On Tue, Feb 18, 2025 at 6:04 PM Dick Brooks via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
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 |
