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

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.

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.

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.

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.

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

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

And sbomgr-cdx.json with primary comp sbomgr and contains components:

• billiard
• botocore

And the final o/p sbom hierar-pc-merge-sbom.spdx.json with sbomex and contains components:

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

And sbomex contains sbomgr primary component as it's dependency.

See the final sbom: hierar-pc-merge-sbom.spdx.json, here.