You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When writing the integration tests, I noticed a surprising behavior of the merge command. I'm not sure whether that's a bug or by design.
When merging two SBOMs, where the first SBOM contains the meta-component of the second SBOM as one of its sub-components, the components of the second SBOM are added to the first at the top level. They are not grouped under the sub-component.
For reference, the official CycloneDX CLI tool has the same behavior but it provides a command-line switch named --hierarchical to change that.
This was a design decision as the expected result does not reflect the dependency tree. According to the specification the components within a component is not for dependencies but for subsystems within systems.
But your point remains, as some tools include this components within components, so having a flag hierarchical could be a good compromise we can agree on, your opinion @CBeck-96?
When writing the integration tests, I noticed a surprising behavior of the merge command. I'm not sure whether that's a bug or by design.
When merging two SBOMs, where the first SBOM contains the meta-component of the second SBOM as one of its sub-components, the components of the second SBOM are added to the first at the top level. They are not grouped under the sub-component.
For reference, the official CycloneDX CLI tool has the same behavior but it provides a command-line switch named
--hierarchical
to change that.SBOM 1
SBOM 2
Actual result
Expected result
The text was updated successfully, but these errors were encountered: