VDR "affects" information incorrect after hierachical merge

[sithmein]

I have VDR files for two components (Docker images), each with subcomponents (libs, OS packages, etc). Each VDR file correctly links a vulnerability to the corresponding subcomponent. However, if I perform a hierarchical merge of the two VDR files then the affected component is always the newly created top-level component. Therefore the link to the sub-component (lib, ...) and even to the component (Docker image) is lost. This feels wrong, especially if a vulnerability contains analysis information which may only be applicable in the context of component A but not component B.

cdx merge --input-files foo.json artemis.json --output-file product.json --hierarchical --name "Final product" --version 1.2.3

merges foo.json and artemis.json. As you can see in product.json affects is always Final product@1.2.3.
The merge was done with version 0.29.1+e7b6ea2ec2a95e705e8fa7a88ad5ac9dbfa7912d of the CycloneDX CLI.

See also https://cyclonedx.slack.com/archives/C01DRP0543Y/p1762856918912369.

[andreas-hilti]

I tend to agree.
These are the relevant lines:
https://github.com/CycloneDX/cyclonedx-dotnet-library/blob/6bffc9a516256459d40739072301d207c0758b68/src/CycloneDX.Utils/Merge.cs#L397-L402
as well as
https://github.com/CycloneDX/cyclonedx-dotnet-library/blob/6bffc9a516256459d40739072301d207c0758b68/src/CycloneDX.Utils/Merge.cs#L628

Note in particular that it uses
ComponentBomRefNamespace(result.Metadata.Component), bom.Vulnerabilities)
rather than
ComponentBomRefNamespace(bom.Metadata.Component), bom.Vulnerabilities)

[riteshnoronha]

I can confirm this is a real issue - preserving the affects relationships during hierarchical merging is quite tricky, especially when dealing with complex component trees and vulnerability analysis contexts. While the CycloneDX CLI team works on a fix for this, I wanted to mention that I've been working on similar VDR assembly challenges in sbomasm. I implemented logic to preserve the original affected component references during hierarchical assembly, which might serve as a temporary workaround if you need to unblock your workflow.

To visualize the issue, the original output, as you can see the vulns are attached to the new primary component.

After the merge with sbomasm it would look something like this.

[andreas-hilti]

@sithmein @riteshnoronha Please check whether CycloneDX/cyclonedx-dotnet-library#415 would address your issue (see for instance the updated test).