bsi v2

[riteshnoronha]

Add compliance doc for bsi - v2.0 for review.

[riteshnoronha]

@fvsamson @surendrapathak I have read & re-read the BSI v2.0 spec multiple times and i have come up with the compliance doc, before i start the implementations. Wanted to call out a couple of things

• CDX minimum version requirement from 1.4 to 1.5 was called out, but SPDX 2.3 -> 2.2.1 was not.
• Added column for SPDX 3.0, will fill that out later once i complete the golang library for SPDX 3.0 parsing.
• Need help with Executable/Archive and structured properties, not sure how these translate.
• BSI has reserved namespace for CDX properties, can they be leveraged for custom data?
• Associated Licenses: Seems like a new concept, but my interpretation is more on the lines of License Expression should be present, not list of licenses for concluded licenses.
• Feels like "Additional SBOM & Component Fields" are almost mandatory now, in v1.1 it was optional ?
• SBOM's should not contain vulns (Love it)

[viveksahu26]

Yeah, the compliance doc looks good. https://github.com/interlynk-io/sbomqs/blob/feature/bsi-v2/Compliance.md .
Some of the fields as mentioned above like Archive/executable and structured looks new in the sboms.

[fvsamson]

Wow, you are quick. I am currently travelling, so my time is a bit limited and hence at BSI our weekly TR-03183-2 writers team teleconference was cancelled. What I can provide the next days are some replies to @riteshnoronha's points above, hopefully a first proper review of your compliance document sometime this week (just glanced over it now), and I will discuss both (questions and document) with my colleagues at our teleconference next week.

Side note: We plan to publish our thinking of mapping TR-03183-2's requirements to CDX and SPDX tags in v2.1.0 of TR-03183-2 (please do not ask when: whenever we and reviewers deem it to be ready, but surely not this year). We are aware, that for a few requirements there are no appropriate tags, but there are a couple of generic ones one can use as name:value fields. Likely we will also require at least SPDX 3.0 (and presumably CDX 1.6), because some new tags make this mapping easier.

This mapping task is primarily performed by a colleague who also has become the one most savvy of us in the CDX and SPDX specifications proper. I will ask him to chime in here next week.

[lpanni]

There seems to be a slight difference in the meaning between associated license and concluded license. But in a multi-licensing example as listed in Annex 8.1.9, I'd consider the choice for the associated license also to be the concluded license.
Who makes the decision seems to be the difference: the SBOM creator (associated) or the component licensee (concluded), which will be the SBOM creator for any direct dependencies.

Example:

• Direct dependency to a component A that declares MIT OR GPL-2.0-only => SBOM creator can decide to use MIT and list that as concluded
• Transitive dependency to the same component A via a directy dependency component B declaring only MIT => creator of component B already made the decision to use MIT, so the SBOM creator has to list MIT as associated license instead of concluded.

Am I right on this one or does it even make a difference in practice?

[lpanni]

the guideline specified SHA-512 for "hash value of the deployable component"

[surendrapathak]

Notes:

• 3.1 Definition of SBOM - specifically points out An SBOM MUST NOT contain vulnerability information. Therefore, I recommend removing that row.
  4 SBOM Formats—limits both specifications and specification versions BUT ALSO file formats to JSON/XML (removing RDF and TV). sbomqs should add a row for that.
• Typo in 5.2.2 originatior
• On associated license, I agree with @lpanni 's point above and also from the description itself : Associated licence(s) of the component from the perspective of the SBOM creator. For specifics, see sections 6.1 and 8.1.9.. Specifically, the phrase indicates a choice made by the SBOM creator (concluded) rather than just the listed (associated). However, if the choice has not been made (concluded license not present), then it seems safe to fall back to associated as per section 8.1.9 Associated licences are all licences under which a component can be used by the licensee.
• 5.2.2 hashes - Since the requirements limits to deployed/deployable component, we should limit this check to the specific component types (not applicable to say ARCHIVE , TEXT, VIDEO etc)

Rest looks good to me.

[riteshnoronha]

@fvsamson i am going to start development based on my initial take, we can refine it once you have bandwidth to review it.