Add tight scoping to nodes in the dependency graph

[stevespringett]

Based on issues identified in CycloneDX/cyclonedx-maven-plugin#310 and which has been discussed at guacsec/guac#594 along with a Slack discussion. on the topic, this enhancement will introduce tight scoping for nodes in the dependency graph. In doing so, CycloneDX will be able to represent components with differing dependency trees across different modules in the same BOM.

Credit to @knrc for discovering this issue and writing about it (blog post being published soon) and to @hboutemy for helping work through the issue with the Maven Plugin.

[jkowalleck]

looking forward to @knrc's blog post.
Need to understand the topic, did not get it from the mentioned discussions.

[knrc]

@jkowalleck I've finally published the blog, it contains a few common examples of when this can happen and the tests within my PR contain two more.

[stevespringett]

The two recommended approaches in CycloneDX both involve component isolation.

1. Use component assemblies to specify all the components that are includes in each Maven model, establishing a hierarchy within the BOM. Components with the same PURL (but different BOM refs) could be represented independently under each structure and the corresponding dependency tree could accurately reflect that.
2. Use BOM-Link to externalize and link to each BOM. This accomplishes the same thing as option 1, but uses multiple BOM files.

This ticket is to potentially provide a third way of representing this without the use of component isolation.

[stevespringett]

One way to solve this in the spec is to implement the recommendation provided in https://trustification.io/2023/03/20/cyclonedx-maven-aggregate-bom-why-not-to-trust.html which uses something similar to a Merkel tree. The recommendation states:

In order to achieve this we need to have some way of enriching the ref attribute value so it represents not only the specific component but also the direct dependencies in its particular location within the dependency graph, for example including a hash which would be derived from each set of dependencies. This hash would need to be calculated from the leaves back to the root, with every deviation in the dependency tree propagating its way up to the root.

While this would work, it also introduces a number of other challenges. Looking for alternative approaches that:

• Have a low impact on existing implementations
• Have a low impact on existing consumption tools
• Is backward compatible with previous CDX versions

[hboutemy]

Use component assemblies

now I think I understand this statement: you mean that having multiple components with the same purl in an assembly is ok for you, because there is the assembly (components in components), while having the same without the assembly additional components level is not ok?

[stevespringett]

having multiple components with the same purl in an assembly is ok for you, because there is the assembly (components in components), while having the same without the assembly additional components level is not ok?

That is correct.

Its a similar concept to LDAP or any other directory service such as:

cn=John Doe, ou=Sales, dc=example.com
cn=John Doe, ou=Legal, dc=example.com

is perfectly fine, but:

cn=John Doe, ou=Sales, dc=example.com
cn=John Doe, ou=Sales, dc=example.com

would result in deduplication because they are the same.

Similar concepts occur in CycloneDX where:

bom / components / component-1 / components / component-A
bom / components / component-2 / components / component-A

is perfectly fine, but

bom / components / component-A
bom / components / component-A

is not.

[jkowalleck]

related:

• https://github.com/CycloneDX/cyclonedx-node-npm/blob/main/docs/result.md
• https://github.com/CycloneDX/cyclonedx-node-npm/blob/main/docs/component_deduplication.md
• and the discussions linked in these two documents

[jkowalleck]

@stevespringett If I understand the topic correct, then it is similar to the one with Node-JS, where every module is encapsulated and has an own unique modeule-resolution-tree.

Already solved it without any need for changes in CDX spec.
My practical solution – bare & flattened: https://github.com/CycloneDX/cyclonedx-node-npm/tree/main/demo/juice-shop/example-results

[knrc]

@jkowalleck It looks as if your flat version is the same as the what I've implemented in my PR for the cyclonedx maven plugin, you also have the same component being duplicated at the top level but with different bom-refs.

[jkowalleck]

[...] have the same component being duplicated at the top level but with different s bom-ref.

@knrc yes. because in my case the components are actually duplicated in the file system. they actually exist multiple times in the build artifact. I do not track runtime-resolution but actual components, which affect runtime-resolution.

read about the background:

• https://github.com/CycloneDX/cyclonedx-node-npm/blob/main/docs/result.md
• https://github.com/CycloneDX/cyclonedx-node-npm/blob/main/docs/component_deduplication.md
• and the discussions linked in these two documents