SBOM representation for various usecases

[Vishnu-2810]

1. Same component in multiple locations:
   If the same component occurs in multiple locations within an application/package, should we define the component only once in the components section and represent all its occurrences/locations within that component (for example, using multiple locations), or should we create a separate component entry for each occurrence?
2. I have a production build ZIP for a product. The product bundles HBase, and HBase itself contains a.jar. The same a.jar is also present at another location within the production build.
   In the SBOM, HBase is represented as a separate component. In this scenario, should a.jar also be represented as a separate component with its own bom-ref, and should we specify a.jar as a dependency of HBase in the dependencies section?
   Or, since a.jar is physically bundled inside HBase, should a.jar be represented as a nested component under HBase instead?
   Also, if the same a.jar occurs at another location in the product, should both occurrences reference the same component definition, with the locations captured separately?

What is the recommended CycloneDX representation for this scenario?

[jkowalleck]

Maybe the Java/Maven/Gradle community can help?

• @stevespringett @DarthHater @nscuro @mr-zepol @hboutemy @skhokhlov @glefloch @MalickBurger

[skhokhlov]

In Gradle plugin we keep one component in components and use the dependency graph to represent the relation to other components. For components that present in test scopes only we set the cdx:maven:package:test property to true. It helps to reduce the size of the BOM while preserving most of the details.

I am not claiming that it is the correct thing for all scenarios, but so far we received no complaints from users so far.

[ahmedhany-cys]

Answering both from the 1.7 schema text, since that's what tools validate against.

1. Same component, multiple locations. If the copies are really the same thing (same purl, same hashes), define it once and list the paths in evidence.occurrences. That field exists for exactly this: "Evidence of individual instances of a component spread across multiple locations" (schema, available since 1.5). Each occurrence needs a location and can carry its own bom-ref. If the hashes differ (repackaged, shaded, patched), they are different components and should be separate entries.

2. a.jar inside HBase and elsewhere. Nesting and dependencies answer different questions:

• components[].components is containment. The schema says it explicitly: "This is not a dependency tree" (L1127).
• dependencies / dependsOn says what relies on what.

The catch is that bom-ref must be unique in the BOM. If you nest a.jar under HBase, that one object can't also sit at the top level. I'd keep it flat and let occurrences carry the physical locations:

"components": [
  { "bom-ref": "hbase", "name": "hbase", "version": "2.x", "purl": "pkg:maven/..." },
  { "bom-ref": "a-1.0", "name": "a", "version": "1.0", "purl": "pkg:maven/.../a@1.0",
    "hashes": [{ "alg": "SHA-256", "content": "..." }],
    "evidence": { "occurrences": [
      { "location": "hbase/lib/a.jar" },
      { "location": "lib/a.jar" }
    ]}
  }
],
"dependencies": [
  { "ref": "product", "dependsOn": ["hbase", "a-1.0"] },
  { "ref": "hbase", "dependsOn": ["a-1.0"] }
]

(product is the bom-ref of metadata.component.) That gives one vulnerability hit per real artifact and still records both paths. Only list the product depending on a.jar directly if the product's own code uses it.

If you need the assembly view (for example, to show that HBase ships a.jar), you can nest a copy under HBase. It then needs a different bom-ref from the top-level entry, with identical purl and hashes, so consumers that dedupe by purl still see one component. The schema allows either shape. Neither the spec nor the schema mandates a path syntax for files inside archives, so pick one convention and use it consistently.