[JFYI] BSI TR-03183-2 v2.0.0 was published

[fvsamson]

It might be of interest for you that BSI TR-03183-2 "SBOM" v2.0.0 was published along with community drafts of part 1 ("General Requirements") and part 3 ("Vulnerability Reports and Notifications"): https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03183/TR-03183_node.html
Short link URL: https://www.bsi.bund.de/dok/TR-03183-en

_{Side note: The corresponding links with German web page text; the documents are all in English (i.e., all the same).
https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03183/TR-03183_node.html
Short link URL: https://www.bsi.bund.de/dok/TR-03183}

P.S.: Only loosely related, but maybe also worth reading is BSI's generic web page on CSAF and the BSI TR-03191 "CSAF".

1. Generic web page on CSAF: https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Industrielle-Steuerungs-und-Automatisierungssysteme/CSAF/CSAF_node.html
   Short link URL: https://www.bsi.bund.de/dok/en_csaf
2. TR-03191: https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03191/TR-03191_node.html
   Short link URL: https://www.bsi.bund.de/dok/TR-03191-en
   <sub>With German landing pages:
   1. Generic web page on CSAF: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Industrielle-Steuerungs-und-Automatisierungssysteme/CSAF/CSAF_node.html
   2. TR-03191: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03191/TR-03191_node.html
   Short link URL: https://www.bsi.bund.de/dok/TR-03191</sub>

HTH.

[riteshnoronha]

@fvsamson awesome will readup and update the tool accordingly

[surendrapathak]

@fvsamson Thanks for sharing!

[riteshnoronha]

@fvsamson #331 this is my initial understanding of the V2.0 guideline. I have created the Compliance Doc, Once we finalize a few points, i can get this implemented.

[viveksahu26]

In the Issue:

• It describe the entire scope of the feature (BSI v2 implementation) and its breakdown into smaller tasks.
• Checklist of tasks such as:
  • Add command for BSI V2.
  • Update existing SBOM fields (e.g., all which were in bsi:1.1.).
  • Update existing component fields (e.g., all which were in bsi:1.1.).
  • Implement new SBOM fields (e.g., e.g., vuln, signature, bomlinks.).
  • Implement new components fields (e.g., e.g., filename, executable, structured, etc.).
  • Add tests for the new features.
  • Update documentation for BSI v2 compliance.

[viveksahu26]

Reopening this issue. The PRs addressed a small part of this issue, but 2-3 sub-tasks remain to fully resolve it.

[riteshnoronha]

@fvsamson we just release v1.0 of sbomqs with support for BSI v2.0. There are still a bunch of open questions about v2.0, but this is the first release.

[fvsamson]

I tried to answer the detailed questions in PR #331, hence I would like to keep the technical discussion there while this issue is well suited to track your various activities WRT BSI TR-03183-2 v2.0.0.

[riteshnoronha]

@fvsamson One aspect of the BSI specification that I find unclear is the guidance on when to merge SBOMs versus when to link them. While the documents acknowledge that merging SBOMs is possible, the Technical Guideline leans toward linking the SBOMs of used components rather than integrating them into the SBOM of the primary component. In the linking approach, the provider of the primary component assumes responsibility for managing and ensuring the availability of all linked SBOMs — which can significantly increase the complexity of SBOM management. An alternative approach, such as a hierarchical or assembly-style merge, might simplify this process. I’d be interested to hear your thoughts on this.

[fvsamson]

Sorry, that topic was pushed back for another week to next Wednesday. But as I had a little time now to think about your question to be prepared for next Wednesday's discussion, I believe to faintly remember that this or something similar was brought forth before (IIRC by a software rsp. systems vendor).

AFAIR my line of thinking was two-pronged:

1. When I see the SBOM-related regulations in EU's CRA (Cyber Resilience Act) in the context of the accompanying regulations for (Software) Supply Chains and Software- rsp. "Product with digital elements"-Lifecycles in the CRA, I have the impression that the primary intent was to force software producers to be able to deliver an SBOM together with the software they sell or publish.
   _{Another perspective, same thing: This is only the basis for a thriving SBOM-"ecosystem". But OTOH I believe it does not take much more to establish and foster such an SBOM-"ecosystem", which allows every software consumer to fill their database of software assets they employ with the content of the SBOMs they receive together with the software proper (i.e. replacing a mostly manual process today with a mostly automated one).}

   One a practical level I summarised this thinking as: "I expect an SBOM(s) for a product to be delivered together with it, because they always have to be in sync. Ultimately, the SBOM(s) are just additional file(s) of a specific software release version. For all electronic distribution channels, especially the internet as the dominating one, I do not see a major issue with that model. Can you point out one?"
   The replies were thin up to now, usually resorting to nitty-gritty details as "our software distribution platform does not explicitly support distributing SBOMs this way [, currently]". While I do not like to be proven wrong, I am much more eager to assess whether my line of arguments is flawed or not, and how it might be improved. If you can reason why you think this line of thinking is too simplistic or has other flaws, please do!

2. Scope / coverage of an SBOM (or: set of SBOMs)
   In the spirit of the CRA to make manufacturers more easily accountable for their products, we quite quickly settled on "delivery item SBOM, while referencing the first level of components (on each path through the component tree) outside the scope of delivery" long ago. I was actually convinced that this is basically a no-brainer, but was soon proven wrong when we had exchanges with software manufacturers who seriously tried to convince us that it should be the software consumer's duty to collect SBOMs from various sources, they would only generate an SBOM documenting the components they create, not all the ones they deliver to their customers, and they (naturally, logically and understandably) cannot assure that the BOM-links in their own SBOMs are working all the time. The two counter arguments are:

   • I makes no sense for thousands of customers trying to collect SBOMs from sources they have no (contractual) relation to. This clearly is something only the one who receives and distributes these components can do properly, i.e. each acting element ("subject") in a supply chain. In consequence, each of these subjects should receive SBOM(s) covering all software they obtain from subjects "upstream" in the supply chain; and, in turn, do the same when in the provider ("upstream") role.
   • Because that trivial argument "no one can guarantee that a «third party»-target of link one propagated is alive, reachable etc." is true, SBOM(s) covering the delivery item(s) should to be provided together / alongside / via the same route of distribution etc. (still following the mantra: "as files accompanying the files of the software proper").

As I sure have missed to remember some aspects of these discussions many months ago, I will still bring this up next Wednesday and ask the other TR-03183 authors to contribute their memories.

Still I am really keen on your critical review of this modelling, because there are only few people around one can discuss the various, partially quite different factors contributing to a lively SBOM-ecosystem from a holistic perspective: Positively charged pressure (e.g. customer demand), which requires tooling to process, distribute and analyse SBOMs for them to be useful (e.g. Interlynk's SBOM-related projects), assisted by negatively charged pressure (e.g. regulations like the CRA), etc.

[fvsamson]

@riteshnoronha, thank you for your feedback: I put it on the schedule for our next internal meeting next Monday, but that schedule is definitely overbooked, so it may be pushed to our meeting a week later (2025-06-30).
_{I will also try to get out of this "messenger" role and have the others chime in here; I have the impression they primarily perceive GitHub as a platform for source code repositories with an optional issue tracker, not as a collaboration platform with many features supporting this purpose. I will try to change that by a hands-on approach. 😃}

BTW, we added "change SPDX minimum version requirement from 2.3 to 2.2.1;" to the changelog for v2.0.0 in our current draft of v2.1.0: Thank you for pointing out that this relevant change was undocumented.

[riteshnoronha]

@fvsamson awesome to see you are bringing up in your meeting thanks. I have converted this issue to a discussions, which should hopefully help.

[riteshnoronha]

@fvsamson sbomqs now supports scoring for v1.1 and v2.0. Please see our blog post https://www.linkedin.com/pulse/sbomqs-scoring-support-bsi-11-bsi-20-summarized-way-vivek-kumar-sahu-apc8c/?trackingId=nto7tlg5TkKLAYffuyYjCA%3D%3D

Would love yours or our teams feedback and how we can improve on it.

thanks @viveksahu26

[fvsamson]

@viveksahu26, pardon my nitpicks, I would like to suggest a few adaptions in the final section "External Resources:" of your aforementioned blog post:

1. Current state (in Markdown syntax):
   [BSI-V1.1](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-1-0_9_0.pdf?__blob=publicationFile&v=4) compliance

   • Web-link to wrong document (part 1 instead of part 2)!
   • Web-link rather to landing page instead of to a specific version of the PDF proper.
   • Rather use as small "v" for "version".

   Proposal (in Markdown syntax):
   [BSI-v1.1](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-2.pdf) compliance

2. Current state (in Markdown syntax):
   [BSI-v2.0 compliance](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-2-2_0_0.pdf?__blob=publicationFile&v=3)

   • Put "compliance" outside of the web-link, following the pattern of the line one prior.
   • Web-link rather to landing page instead of to a specific version of the PDF proper.

   Proposal (in Markdown syntax):
   [BSI-v2.0](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-2-2_0_0.pdf) compliance

3. Current state (in Markdown syntax):
   [Interlynk Plaform](https://github.com/snyk/parlay) for community

   • Is "Plaform" correct, or should it rather read "Platform"?
   • Is the link to snyk/parlay correct? It seems to be a copy&paste of the URL used in the line one prior.

--
HTH
Florian

[viveksahu26]

Thanks @fvsamson for review. I have updated it accordingly.