Feature: Allow one sbom to be the primary document in assemble action

[matglas]

What I notice is that its only possible to assemble while settings the primary tags or the config and this is a limitation.

What I am looking for is to provide the primary component and add all the other boms as dependencies. At this point you are required to use the config even if you would have a proper root component and want to add the extra components from the SBOMs.

If there would be a --primary-component-file flag that allows you to base your file on that and add the other boms.

Interested to hear what others things about this process.

[matglas]

Another way to phrase this is the ability to do SBOM append. And add B to A. Where B is a dependency of A.

[riteshnoronha]

I agree this also should be a mode of operation for the tool. Let me add this as a feature request, should not be that hard to implement.

[viveksahu26]

Adding discussion here for future reference:

• When two SBOMs(SBOM-1, SBOM-2) are assembled, the resulting SBOM(SBOM-3) will contain two main components. The first component represents the primary element of the first SBOM(i.. SBOM-1), while the second component represents the primary element of the second SBOM(i.e. SBOM-2). All components from the first SBOM(i.e. SBOM-1) are grouped under the first component in the final SBOM, and similarly, all components from the second SBOM(i.e. SBOM-2) are grouped under the second component.

• Now, focusing on this new feature where the primary SBOM is fixed: For example, consider three SBOMs: SBOM-1, SBOM-2, and SBOM-3. SBOM-1 is designated as the primary document. In this case, the assembly process involves SBOM-2 and SBOM-3 becoming new components within SBOM-1. Specifically, the primary components of SBOM-2 and SBOM-3 are added as new components in SBOM-1. Furthermore, all components of SBOM-2 and SBOM-3 are grouped under their respective primary components in SBOM-1. Additionally, all components of SBOM-1, prior to the assembly, will remain unchanged.

So, my question is regarding how the strucutre of assembled SBOM-1 components looks like ? So, I have 2 options in my minds:

1. First structure is like:
   SBOM-1 with primary comp P1 and it's components are C1, C11, C111
   SBOM-2 with primary comp P2, and it's components are C2, C22
   SBOM-3 with primary comp P3, and it's components are C3, C33
   Now final assemble structure of SBOM-1 components will look like this:
   It includes the original components of SBOM-1 (C1, C11, C111), with P2 and P3 added. The components of SBOM-2 (C2, C22) are nested under P2, and the components of SBOM-3 (C3, C33) are nested under P3.

2. Second Structure is like:
   SBOM-1 with primary comp P1 and it's components are C1, C11, C111
   SBOM-2 with primary comp P2, and it's components are C2, C22
   SBOM-3 with primary comp P3, and it's components are C3, C33
   Now final assemble structure of SBOM-1 components will look like this:
   It organizes the primary components (P1, P2, P3) directly under SBOM-1. Under P1, the components C1, C11, and C111 are grouped; under P2, the components C2 and C22 are grouped; and under P3, the components C3 and C33 are grouped.

[matglas]

I would say that the first structure is what I hope to get. The reason is that 'most' of the time you will have a file SBOM-1 that has its own primary component. And then SBOM-2 and SBOM-3 are dependencies that SBOM-1 should have but the build tool that generates SBOM-1 could not represent them as they are not native integrations to the language of the build tool. But they are 100% dependencies of the product of SBOM-1.

[viveksahu26]

I would say that the first structure is what I hope to get.

Yeah you can achieve this via one of the mode of assembling SBOM called flat, (kind of, not exactly because P1 and P2 won't be present. Directly their component will be present), using --flatMerge or -f flag. By default, Hierarchical merge is present.

See here to know more about different algorithm
The first structure is known as flatMerge and second structure is known as Hierarchical merge.

[viveksahu26]

The component structure would be like this: all components of SBOM-1, SBOM-2, and SBOM-3, would be present serially or in flat manner.
See this: https://gist.github.com/viveksahu26/16fa1c1b0fc0cf636088aa829585e41e

[viveksahu26]

Hey @matglas , hope this looks as per your approach i.e first method.

Now, check this,
$ go run main.go assemble --primaryCompFile sbomex-cdx.json sbomgr-cdx.json -o hierar-pc-merge-sbom.spdx.json

Where, sbomex-cdx.json with primary comp sbomex and

• contains components:
  • github.com/google/uuid,
  • github.com/inconshreveable/mousetrap
• with dependencies
  • github.com/google/uuid
  • github.com/inconshreveable/mousetrap

And sbomgr-cdx.json with primary comp sbomgr and

• contains components:
  • billiard
  • botocore
• with dependencies
  • billiard
  • botocore

And sbomqs-cdx.json with primary comp sbomqs and

• contains components:
  • ArgTools.jl
• with no dependencies

And the final o/p sbom hierar3-pc-final.cdx.json with sbomex as primary component and

• contains components:

  • github.com/google/uuid,
  • github.com/inconshreveable/mousetrap
  • sbomgr
    • billiard
    • botocore
  • sbomqs
    • ArgTools.jl

• with dependencies

  • sbomex
    • github.com/google/uuid,
    • github.com/inconshreveable/mousetrap
    • sbomgr
    • sbomqs
  • sbomgr
  • billiard
  • botocore

Files attached:
sbomqs-cdx.json
sbomgr-cdx.json
sbomex-cdx.json
hierar3-pc-final.cdx.json

[matglas]

Hi @viveksahu26 that is indeed what I was looking for. This is the way that I would want to represent it.

There is one nuance which is more of an internal requirement. In your example sbomgr is represented as an assembly. So the components are set on the components element. We have an internal requirement to make it a 'list' in the main root components element and use dependencies to reflect the relationship.

[viveksahu26]

Ohh, you mean the input SBOMs components to be present as a list in the final SBOM components section.

• Or you say flat or
• one by one
• or serially.

Something like this: https://gist.github.com/viveksahu26/51ea4129f216ba6a7726a90ee92cfaf8

[matglas]

I was already looking for the right wording indeed.

The example that you created looses the relationship that sbomgr has with billiard and botocore. But apart from that its correct indeed that this is what I mean. Here is a 'corrected' example.

https://gist.github.com/matglas/97aa2dcd7a79b8f0af9bff79cee3f757

[viveksahu26]

Yeah, but the example sbomgr-cdx.json itself doesn't contain any relationship. If it would contains, the final sbom will do map out that relationship in the final SBOM.