RFC: merging multiple CycloneDX documents #320
Replies: 16 comments 34 replies
This comment has been minimized.
This comment has been minimized.
-
|
it is okay to leave this wall of text for context, but for discussion and focus purpose, PS: 🔍 the original request and its details are still there and can be expanded and read by clicking the "show comment" button above". |
Beta Was this translation helpful? Give feedback.
-
|
re: #320 (comment)
|
Beta Was this translation helpful? Give feedback.
-
|
XML's (enhanced) data model of "nested" dependencies can be flattened, so it would match the one of JSON - without data loss. |
Beta Was this translation helpful? Give feedback.
-
|
re: #320 (comment)
|
Beta Was this translation helpful? Give feedback.
-
|
if the dependency model was flattened, every "ref" in it MUST be unique. |
Beta Was this translation helpful? Give feedback.
-
|
re: #320 (comment)
|
Beta Was this translation helpful? Give feedback.
-
|
Components and services it is, for now (as of CycloneDX 1.5). |
Beta Was this translation helpful? Give feedback.
-
|
re: #320 (comment)
|
Beta Was this translation helpful? Give feedback.
-
Yes. That is the idea. Dependencies act on local references, not BOM-links. |
Beta Was this translation helpful? Give feedback.
-
|
re: #320 (comment)
Some precedents from experience in the field:
|
Beta Was this translation helpful? Give feedback.
-
yes. |
Beta Was this translation helpful? Give feedback.
-
Why not simply omit a |
Beta Was this translation helpful? Give feedback.
-
|
re: #320 (comment)
|
Beta Was this translation helpful? Give feedback.
-
|
this is a critical point, people could argue. I am far from giving a proper answer to this. I have an opinion on it: practical: if two component utilized different versions of libXML, they behave differently and are not the same, even though that the same code was used to compile those components. I could imagine that others would not understand why a dependency graph should matter when equality is described. So whatever solution one chose, please document it outside of the code, why you implemented it and what the benefits of that are. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, given the desire to not impose opinions, I guess this (consideration or not of back-refs from any dependency as part of a component/serice) will also become a toggle in While at it: do you know of any other element types that behave similarly (are external but potentially behave as intimately as properties of components etc.?) I probably will not cover everything in my PRs, but might try to lay some design foundations to help future evolution (e.g. single toggles or lists of types?) :) |
Beta Was this translation helpful? Give feedback.
-
Should this really be part of a merge operation? Sounds more like a consolidate or "fix data" operation, overcomplicating merge. |
Beta Was this translation helpful? Give feedback.
-
|
re: #320 (comment)
|
Beta Was this translation helpful? Give feedback.
-
|
yes, in general they are sets (unordered collection of unique items), not lists(ordered collection of items). ❗ I know people argue that |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
re: #320 (comment)
|
Beta Was this translation helpful? Give feedback.
-
|
Can you answer this, @CycloneDX/net-maintainers ? |
Beta Was this translation helpful? Give feedback.
-
|
I just discussed this with @jkowalleck. We are not completely sure what constraint you are referring to. We didn't see relevant constraints in the xsd. Might be possible that there is such a constraint in the dotnet library, then it's likely that it comes from a time, when the dependency type was used much less and was only relevant for components and services. In that case, it might be an idea for the future to remove the constraint from the dotnet library. Feel free to create an issue there. |
Beta Was this translation helpful? Give feedback.
-
|
AFAIK it is not specified as a constraint in the schemas. However, from the comments
it is clear that at least in this place, it is constrained to components and services. |
Beta Was this translation helpful? Give feedback.
-
|
if you find the documentation wrong or confusing, please open a report here https://github.com/CycloneDX/specification/issues/new |
Beta Was this translation helpful? Give feedback.
-
|
My humble request is that the specification be un-opinionated. Merging strategies require assumptions and positions, so best to leave it to the individual cli and tools for implementation. |
Beta Was this translation helpful? Give feedback.
-
|
I agree, so to the best extent possible (my first foray into C# and all that) I'm trying to make the merge strategies configurable. The already-proposed PR bits include a I hope this would prove extensible enough to add more toggles (and their handling) in the future as people would imagine more strategies and corner cases. And possibly CLI/YAML/whatever handling to pass the choice of toggles from tools and other consumers into these library calls. Eventually, I think, the current |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
-
|
Thanks for the suggestion. Looked at it as much as a mobile during commute allows, and https://github.com/interlynk-io/sbomasm/blob/main/pkg/assemble/spdx/merge.go says "flat merge not implemented", but the readme details one. Anyhow, a quick search in https://github.com/CycloneDX/cyclonedx-go does not seem that it would mention "merge" at all, so any contribution there would be helpful, I suppose. The tricky part I'm banging my head at for the past few months is the flat merge, as generic for the hordes of data types and their constraints as possible, and as un-opinionated as I can (or nowadays rather easy to fix into having codepaths configurable). And with many Boms explaining same components - either identically (so trivial to discard extras after checking constraints like different back-references from depenency-lists etc.), or appending info to squash into one entity (e.g. one tool reports the technical structure of a component, and another overlays the license used for intended audience), or some fully conflicting data (e.g. components can be marked required/excluded/optional and those are not just gradations to turn up the dial)... And I'm dealing closely with just components! Pile on the other dozens of types with their idiosyncracies, and go wonder about your choices in life ;) In cyclonedx-dotnet-library a For our use-case, building a "release bundle SBOM" for the end-user bundle comprised of about 600 input component BOMs (some referencing the same code as dependencies) a hierarchical merge ends up with some 26K components and thousands of copies of same alert when a vuln is found (assigned to each unique component ID) - this is unfeasible to manage and e.g. assign "we would fix this, ignore that"... I have seen the arguments in favour of in fact having the ultimate dependency tree with explicitly independent copies of same components, because in fact their place in the dependency tree makes them unique (e.g. using log4j in one component is a trouble to fix, but not in another because it is configured differently), and end up assigning different verdicts to same "log4j" component depending on its use-cases - so to each their own. |
Beta Was this translation helpful? Give feedback.
-
|
@riteshnoronha added ✔️ |
Beta Was this translation helpful? Give feedback.
-
|
In terms of use-cases, this is what I'm using BOM merges for: Hierarchical mergeI have BOMs for a couple of components which I'm aggregating, and thus, the new BOM describes the aggregate and has the other components as dependencies. Flat mergeI have a BOM for component A, but the BOM is incomplete, thus I want to expand it using information from other BOMs (i.e. BOM editing). Examples
In many cases, I used the flat merge, but then I actually had to modify the dependencies manually. (As written previously, for me the sematics for the hierarchical merge are quite clear, but for the flat merge this is not true.) What are your use cases? |
Beta Was this translation helpful? Give feedback.
-
|
Detailed a number of times earlier, but to keep birds of a feather in one cage - here goes: I am making a script for $dayjob which coordinates creation of a "release SBOM" for the bundle delivered to this or that user/market, so often customized. The product is comprised of a few dozen tools and daemons/containers, built on top of a hundred or so components made by us, and a few hundred third-party dependencies (often same or similar, like the Java String framework parts used dozens of times). This singular release SBOM can be delivered to customers per requirements, as well as used internally with a Dependency-Tracker server to watch out for appearance of newly-discovered vulnerabilities that may impact something that we have delivered in the past and still support. My script parses what is effectively a top-level manifest of a delivered bundle (the Kubernetes/Helm YAML which lists the components and their versions relevant for the particular bundle), collects a number of original Bom documents (e.g. some from build artifacts where they are placed by component-release publishing - currently for the PoC that's just cyclonedx-maven-plugin, but later there will be silos from C#, docker, etc. so potentially in different BOM formats originally and converted into CycloneDX somehow; some from other systems like the overlay with licensing relevant for certain contracts, etc.) and as one of many steps - it calls Production of these merges proved complicated because use of a single Bom document with 30-60K original components (e.g. after a hierarchical merge) is not practically feasible for us. When a vulnerability is reported, we get hundreds or thousands of notifications for different uses of the same component, often behind several layers of third-party dependencies (so we can only moderately impact this), and formally each should have been inspected and a verdict made - hundreds of times. With a smallish team, that would not be possible even to click through them all.
So the flat merge for us has several goals:
Maybe there was more to it, but it's late here and so much I did remember :) |
Beta Was this translation helpful? Give feedback.
-
|
I also have the same issue, the current specification works perfectly for single applications, but if for some reason we need to merge sboms like for a bundle (we used to describe a bundle of micro services) will lead to issues since the applications have different compile times that could lead to different dependency versions.. When merging if we put libB 1.0 and libB 1.1 as dependencies of libA will lead to I was wondering if its possible to add something to the structure of dependencies that would help us to implement it without adding false positives or without duplicating the complete graph in order to do a merge without losing data |
Beta Was this translation helpful? Give feedback.
-
|
re: #320 (reply in thread) |
Beta Was this translation helpful? Give feedback.
-
|
❗ ❗ ❗ ❗ ❗ The following is a (probably outdated) unfinished and unpublished pamphlet "Standardization of BOM merging algorithms" - is still work in progress; the original authors agreed to publish the snapshot here. ❗ ❗ ❗ ❗ ❗ Meta
SummaryThis is a proposal for a set of standardized merging algorithms for CycloneDX Bill of Materials. MotivationWhy should we do this?With SBOM adoption ramping up, a lot of use cases have surfaced that require merging multiple BOMs into one. While it's trivial to merge BOM objects on a technical level, it may introduce inconsistencies or cause ambiguities. We need one or more merging algorithms that we consider to be correct and accurate. Another factor is that we offer tooling for SBOM generation and transformation, as well as libraries for multiple ecosystems. When it comes to functionalities like merging, it's important that our offering behaves the same across our portfolio, and produces consitent results. What use cases does this support?Use case 1I have a web app. It has NPM packages for client side JavaScript, and NuGet When I'm generating the SBOM for it, I need to use the CycloneDX Node implementation Use case 2I have a web app. It has NPM packages for a SPA frontend, NPM packages for the I want to generate a single SBOM that retains the individual system components. Each of these components has a different threat model. The same vulnerability for Additionally, each of these components is managed by a different team. Use case 3I've gone all in on micro-services. I now have so many micro-services I don't I want a view of my entire product and the dependency relationships (services) Each micro-service team generates a new SBOM for each build. I want an SBOM that represents all the individual micro-services in our What is the expected outcome?
What it isThis RFC proposes three merging algorithms, each of which targets a different use case.
How it WorksOverviewIn general, merging only affects top-level collections, not the elements within them. Merge functions adhere to the following signature: def merge(subject: Optional[Component], boms: Sequence[BOM]) -> BOM
Further, the following constraints apply:
BOM reference namespacingNamespacing is done to indicate the origin of a component or service, as well as to prevent reference collisions. See #7 for the namespace format definition. <!-- Not namespaced -->
<component bom-ref="pkg:maven/com.acme/acme-lib@1.2.3" type="library">
<!-- Namespaced -->
<component bom-ref="urn:cyclonedx:a48a8f21-afe9-4cde-bb43-9c61c6409927/3#pkg%3Amaven%2Fcom.acme%2Facme-lib%401.2.3" type="library">The following constraints apply to namespacing:
AlgorithmsThe algorithms in this document are written in Python for readability's sake. ReproducabilityIn order to make results reproducible, merge algorithms are subject to the following additional constraints:
NamespacingTo accomodate for the namespacing requirements detailed above, merge algorithms make use def namespace(bom_ref: Optional[str], src: BOM) -> Optional[str]:
"""Namespace a BOM reference."""
pass
def namespace_component(component: Component, src: BOM) -> None:
"""Namespace a component's BOM reference (and that of its sub-components)."""
pass
def namespace_service(service: Service, src: BOM) -> None:
"""Namespace a component's BOM reference (and that of its sub-services)."""
pass
def namespace_dependency(dependency: Dependency, src: BOM) -> None:
"""Namespace a dependency's BOM reference (and that of its dependencies)."""
pass
def namespace_composition(composition: Composition, src: BOM) -> None:
"""Namespace a composition's BOM references."""
passFlat mergeDescriptionThe flat merge algorithm creates an aggregate of all elements within the provided BOMs. Merged elements
Codedef flat_merge(subject: Optional[Component], boms: Sequence[BOM]) -> BOM:
if len(boms) < 2:
raise MergeError("merging requires at least two boms")
for bom in boms:
if not bom:
raise MergeError("bom must not be None")
if not bom.serial_number:
raise MergeError("bom must have a serial number")
tools: List[Tool] = []
metadata_properties: List[Property] = []
components: List[Component] = []
services: List[Service] = []
external_references: List[ExternalReference] = []
dependencies: List[Dependency] = []
compositions: List[Composition] = []
properties: List[Property] = []
subject_dependencies: List[Dependency] = []
for bom in boms:
if bom.metadata:
if bom.metadata.tools:
tools.extend(bom.metadata.tools)
if bom.metadata.component:
component = bom.metadata.component
namespace_component(component, bom)
components.append(component)
if subject.bom_ref and component.bom_ref:
subject_dependencies.append(Dependency(ref=component.bom_ref))
if bom.metadata.properties:
metadata_properties.extend(bom.metadata.properties)
if bom.components:
for component in bom.components:
namespace_component(component, bom)
components.append(component)
if bom.services:
for service in bom.services:
namespace_service(service, bom)
services.append(service)
if bom.external_references:
external_references.extend(bom.external_references)
if bom.dependencies:
for dependency in bom.dependencies:
namespace_dependency(dependency, bom)
dependencies.append(dependency)
if bom.compositions:
for composition in bom.compositions:
namespace_composition(composition, bom)
compositions.append(composition)
if bom.properties:
properties.extend(bom.properties)
if subject and subject_dependencies:
dependencies.append(Dependency(
ref=subject.bom_ref,
dependencies=subject_dependencies
))
result = BOM()
result.metadata = Metadata(
tools=tools,
component=subject,
properties=metadata_properties
)
result.components = components
result.services = services
result.external_references = external_references
result.dependencies = dependencies
result.compositions = compositions
result.properties = properties
return resultHierarchical mergeDescriptionThe hierarchical merge algorithm mostly behaves just like the flat merge, with the exception of components: Merged elements
Codedef hierarchical_merge(subject: Optional[Component], boms: Sequence[BOM]) -> BOM:
if len(boms) < 2:
raise MergeError("merging requires at least two boms")
for bom in boms:
if not bom:
raise MergeError("bom must not be None")
if not bom.serial_number:
raise MergeError("bom must have a serial number")
if not bom.metadata or not bom.metadata.component:
raise MergeError("bom must have a top-level component")
tools: List[Tool] = []
metadata_properties: List[Property] = []
components: List[Component] = []
services: List[Service] = []
externalReferences: List[ExternalReference] = []
dependencies: List[Dependency] = []
compositions: List[Composition] = []
properties: List[Property] = []
subject_dependencies: List[Dependency] = []
for bom in boms:
if bom.metadata.tools:
tools.extend(bom.metadata.tools)
if bom.metadata.properties:
metadata_properties.extend(bom.metadata.properties)
main = bom.metadata.component
if bom.components:
main.components.extend(component)
namespace_component(main, bom)
components.append(main)
if subject.bom_ref and main.bom_ref:
subject_dependencies.append(Dependency(ref=main.bom_ref))
if bom.services:
for service in bom.services:
namespace_service(service, bom)
services.append(service)
if bom.external_references:
external_references.extend(bom.external_references)
if bom.dependencies:
for dependency in bom.dependencies:
namespace_dependency(dependency, bom)
dependencies.append(dependency)
if bom.compositions:
for composition in bom.compositions:
namespace_composition(composition, bom)
compositions.append(composition)
if bom.properties:
properties.extend(bom.properties)
if subject and subject_dependencies:
dependencies.append(Dependency(
ref=subject.bom_ref,
dependencies=subject_dependencies
))
result = BOM()
result.metadata = Metadata(
tools=tools,
component=subject,
properties=metadata_properties
)
result.components = components
result.services = services
result.external_references = external_references
result.dependencies = dependencies
result.compositions = compositions
result.properties = properties
return resultReference mergeDescriptionThe reference merge extracts the top-level component of each provided BOM, An Fields of the components that are not essential to identifying them are stripped.
This is done to reduce redundancies, as well as ensuring consiceness of the resulting BOM. TODO: Should external references have BOM versions and hashes? Merged elements
Codedef reference_merge(subject: Optional[Component], boms: Sequence[BOM]) -> BOM:
if len(boms) < 2:
raise MergeError("merging requires at least two boms")
for bom in boms:
if not bom:
raise MergeError("bom must not be None")
if not bom.serial_number:
raise MergeError("bom must have a serial number")
if not bom.metadata or not bom.metadata.component:
raise MergeError("bom must have a top-level component")
components: List[Component] = []
subject_dependencies: List[Dependency] = []
for bom in boms:
component = Component(
bom_ref=namespace(bom.metadata.component.bom_ref, bom),
type=bom.metadata.component.type,
group=bom.metadata.component.group,
name=bom.metadata.component.name,
version=bom.metadata.component.version,
external_references = [
ExternalReference(type="bom", url=bom.serial_number)
]
)
components.append(component)
if subject.bom_ref and component.bom_ref:
subject_dependencies.append(Dependency(ref=component.bom_ref))
if subject and subject_dependencies:
dependencies.append(Dependency(
ref=subject.bom_ref,
dependencies=subject_dependencies
))
dependencies.extend(subject_dependencies)
result = BOM()
result.metadata = Metadata(component=subject)
result.components = components
result.dependencies = dependencies
return resultExamplesInputsTo keep this document manageable, we're assuming a fixed set of inputs for all merge operations. BOM AThis BOM describes the Java application <?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.3" serialNumber="urn:uuid:c337a0f7-82b6-49bf-abd2-95e37c7476c8" version="1">
<metadata>
<tools>
<tool>
<name>cyclonedx-maven-plugin</name>
<version>2.5.3</version>
</tool>
</tools>
<component bom-ref="pkg:maven/com.acme/acme-backend@1.0.0" type="application">
<group>com.acme</group>
<name>acme-backend</name>
<version>1.0.0</version>
</component>
</metadata>
<components>
<component bom-ref="pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.12.4" type="library">
<group>com.fasterxml.jackson.core</group>
<name>jackson-databind</name>
<version>2.12.4</version>
</component>
</components>
<dependencies>
<dependency ref="pkg:maven/com.acme/acme-backend@1.0.0">
<dependency ref="pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.12.4"/>
</dependency>
<dependency ref="pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.12.4"/>
</dependencies>
</bom>BOM BThis BOM describes the JavaScript application <?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.3" serialNumber="urn:uuid:12151f5b-4001-4835-a734-42fafde0a852" version="1">
<metadata>
<tools>
<tool>
<group>@cyclonedx</group>
<name>bom</name>
<version>v3.1.1</version>
</tool>
</tools>
<component bom-ref="pkg:npm/%40acme/acme-frontend@1.0.0" type="application">
<group>@acme</group>
<name>acme-frontend</name>
<version>1.0.0</version>
</component>
</metadata>
<components>
<component bom-ref="pkg:npm/vue@2.6.12" type="library">
<name>vue</name>
<version>2.6.12</version>
</component>
</components>
<dependencies>
<dependency ref="pkg:npm/%40acme/acme-frontend@1.0.0">
<dependency ref="pkg:npm/vue@2.6.12"/>
</dependency>
<dependency ref="pkg:npm/vue@2.6.12"/>
</dependencies>
</bom>SubjectThis component describes the top-level component <component bom-ref="com.acme/acme-app@1.0.0" type="application">
<group>com.acme</group>
<name>acme-app</name>
<version>1.0.0</version>
</component>Flat merge<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.3" serialNumber="urn:uuid:f120a825-fb11-4fe6-a6cd-f8a6a3874756" version="1">
<metadata>
<tools>
<tool>
<name>cyclonedx-maven-plugin</name>
<version>2.5.3</version>
</tool>
<tool>
<group>@cyclonedx</group>
<name>bom</name>
<version>v3.1.1</version>
</tool>
</tools>
<component bom-ref="com.acme/acme-app@1.0.0" type="application">
<group>com.acme</group>
<name>acme-app</name>
<version>1.0.0</version>
</component>
</metadata>
<components>
<component bom-ref="urn:cyclonedx:c337a0f7-82b6-49bf-abd2-95e37c7476c8#pkg:maven%2Fcom.acme%2Facme-backend%401.0.0" type="application">
<group>com.acme</group>
<name>acme-backend</name>
<version>1.0.0</version>
</component>
<component bom-ref="urn:cyclonedx:c337a0f7-82b6-49bf-abd2-95e37c7476c8#pkg:maven%2Fcom.fasterxml.jackson.core%2Fjackson-databind%402.12.4" type="library">
<group>com.fasterxml.jackson.core</group>
<name>jackson-databind</name>
<version>2.12.4</version>
</component>
<component bom-ref="urn:cyclonedx:12151f5b-4001-4835-a734-42fafde0a852#pkg:npm%2F%40acme%2Facme-frontend%401.0.0" type="application">
<group>@acme</group>
<name>acme-frontend</name>
<version>1.0.0</version>
</component>
<component bom-ref="urn:cyclonedx:12151f5b-4001-4835-a734-42fafde0a852#pkg:npm%2Fvue%402.6.12" type="library">
<name>vue</name>
<version>2.6.12</version>
</component>
</components>
<dependencies>
<dependency ref="com.acme/acme-app@1.0.0">
<dependency ref="urn:cyclonedx:c337a0f7-82b6-49bf-abd2-95e37c7476c8#pkg:maven%2Fcom.acme%2Facme-backend%401.0.0"/>
<dependency ref="urn:cyclonedx:12151f5b-4001-4835-a734-42fafde0a852#pkg:npm%2F%40acme%2Facme-frontend%401.0.0"/>
</dependency>
<dependency ref="urn:cyclonedx:c337a0f7-82b6-49bf-abd2-95e37c7476c8#pkg:maven%2Fcom.acme%2Facme-backend%401.0.0">
<dependency ref="urn:cyclonedx:c337a0f7-82b6-49bf-abd2-95e37c7476c8#pkg:maven%2Fcom.fasterxml.jackson.core%2Fjackson-databind%402.12.4"/>
</dependency>
<dependency ref="urn:cyclonedx:c337a0f7-82b6-49bf-abd2-95e37c7476c8#pkg:maven%2Fcom.fasterxml.jackson.core%2Fjackson-databind%402.12.4"/>
<dependency ref="urn:cyclonedx:12151f5b-4001-4835-a734-42fafde0a852#pkg:npm%2F%40acme%2Facme-frontend%401.0.0">
<dependency ref="urn:cyclonedx:12151f5b-4001-4835-a734-42fafde0a852#pkg:npm%2Fvue%402.6.12"/>
</dependency>
<dependency ref="urn:cyclonedx:12151f5b-4001-4835-a734-42fafde0a852#pkg:npm%2Fvue%402.6.12"/>
</dependencies>
</bom>Hierarchical merge<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.3" serialNumber="urn:uuid:f120a825-fb11-4fe6-a6cd-f8a6a3874756" version="1">
<metadata>
<tools>
<tool>
<name>cyclonedx-maven-plugin</name>
<version>2.5.3</version>
</tool>
<tool>
<group>@cyclonedx</group>
<name>bom</name>
<version>v3.1.1</version>
</tool>
</tools>
<component bom-ref="com.acme/acme-app@1.0.0" type="application">
<group>com.acme</group>
<name>acme-app</name>
<version>1.0.0</version>
</component>
</metadata>
<components>
<component bom-ref="urn:cyclonedx:c337a0f7-82b6-49bf-abd2-95e37c7476c8#pkg:maven%2Fcom.acme%2Facme-backend%401.0.0" type="application">
<group>com.acme</group>
<name>acme-backend</name>
<version>1.0.0</version>
<components>
<component bom-ref="urn:cyclonedx:c337a0f7-82b6-49bf-abd2-95e37c7476c8#pkg:maven%2Fcom.fasterxml.jackson.core%2Fjackson-databind%402.12.4" type="library">
<group>com.fasterxml.jackson.core</group>
<name>jackson-databind</name>
<version>2.12.4</version>
</component>
</components>
</component>
<component bom-ref="urn:cyclonedx:12151f5b-4001-4835-a734-42fafde0a852#pkg:npm%2F%40acme%2Facme-frontend%401.0.0" type="application">
<group>@acme</group>
<name>acme-frontend</name>
<version>1.0.0</version>
<components>
<component bom-ref="urn:cyclonedx:12151f5b-4001-4835-a734-42fafde0a852#pkg:npm%2Fvue%402.6.12" type="library">
<name>vue</name>
<version>2.6.12</version>
</component>
</components>
</component>
</components>
<dependencies>
<dependency ref="com.acme/acme-app@1.0.0">
<dependency ref="urn:cyclonedx:c337a0f7-82b6-49bf-abd2-95e37c7476c8#pkg:maven%2Fcom.acme%2Facme-backend%401.0.0"/>
<dependency ref="urn:cyclonedx:12151f5b-4001-4835-a734-42fafde0a852#pkg:npm%2F%40acme%2Facme-frontend%401.0.0"/>
</dependency>
<dependency ref="urn:cyclonedx:c337a0f7-82b6-49bf-abd2-95e37c7476c8#pkg:maven%2Fcom.acme%2Facme-backend%401.0.0">
<dependency ref="urn:cyclonedx:c337a0f7-82b6-49bf-abd2-95e37c7476c8#pkg:maven%2Fcom.fasterxml.jackson.core%2Fjackson-databind%402.12.4"/>
</dependency>
<dependency ref="urn:cyclonedx:c337a0f7-82b6-49bf-abd2-95e37c7476c8#pkg:maven%2Fcom.fasterxml.jackson.core%2Fjackson-databind%402.12.4"/>
<dependency ref="urn:cyclonedx:12151f5b-4001-4835-a734-42fafde0a852#pkg:npm%2F%40acme%2Facme-frontend%401.0.0">
<dependency ref="urn:cyclonedx:12151f5b-4001-4835-a734-42fafde0a852#pkg:npm%2Fvue%402.6.12"/>
</dependency>
<dependency ref="urn:cyclonedx:12151f5b-4001-4835-a734-42fafde0a852#pkg:npm%2Fvue%402.6.12"/>
</dependencies>
</bom>Reference merge<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.3" serialNumber="urn:uuid:f120a825-fb11-4fe6-a6cd-f8a6a3874756" version="1">
<metadata>
<component bom-ref="com.acme/acme-app@1.0.0" type="application">
<group>com.acme</group>
<name>acme-app</name>
<version>1.0.0</version>
</component>
</metadata>
<components>
<component bom-ref="urn:cyclonedx:c337a0f7-82b6-49bf-abd2-95e37c7476c8#pkg:maven%2Fcom.acme%2Facme-backend%401.0.0" type="application">
<group>com.acme</group>
<name>acme-backend</name>
<version>1.0.0</version>
<externalReferences>
<reference type="bom">
<url>urn:uuid:c337a0f7-82b6-49bf-abd2-95e37c7476c8</url>
</reference>
</externalReferences>
</component>
<component bom-ref="urn:cyclonedx:12151f5b-4001-4835-a734-42fafde0a852#pkg:npm%2F%40acme%2Facme-frontend%401.0.0" type="application">
<group>@acme</group>
<name>acme-frontend</name>
<version>1.0.0</version>
<externalReferences>
<reference type="bom">
<url>urn:uuid:12151f5b-4001-4835-a734-42fafde0a852</url>
</reference>
</externalReferences>
</component>
</components>
<dependencies>
<dependency ref="com.acme/acme-app@1.0.0">
<dependency ref="urn:cyclonedx:c337a0f7-82b6-49bf-abd2-95e37c7476c8#pkg:maven%2Fcom.acme%2Facme-backend%401.0.0"/>
<dependency ref="urn:cyclonedx:12151f5b-4001-4835-a734-42fafde0a852#pkg:npm%2F%40acme%2Facme-frontend%401.0.0"/>
</dependency>
<dependency ref="urn:cyclonedx:c337a0f7-82b6-49bf-abd2-95e37c7476c8#pkg:maven%2Fcom.acme%2Facme-backend%401.0.0"/>
<dependency ref="urn:cyclonedx:12151f5b-4001-4835-a734-42fafde0a852#pkg:npm%2F%40acme%2Facme-frontend%401.0.0"/>
</dependencies>
</bom>Prior Art
|
Beta Was this translation helpful? Give feedback.
-
|
A couple of comments from my side (for the moment):
|
Beta Was this translation helpful? Give feedback.
-
|
In addition,
|
Beta Was this translation helpful? Give feedback.
-
|
Last but not least one should also constraint that the input BOMs (or their serialNumbers) are different. This is a rather theoretical constraint though. In practice, it will be very uncommon to merge the same BOM twice. But it is needed to formally guarantee uniqueness. |
Beta Was this translation helpful? Give feedback.
-
|
@jkowalleck it seems that the examples don't show scenario where you have different versions of same dependency in different BOMs, to me this is the biggest issue and I don't think any of the solutions will work without losing data or duplicating the information |
Beta Was this translation helpful? Give feedback.
-
what are you referring to? Spec is all here: https://github.com/CycloneDX/specification/
I do not see this. What data are you loosing? Please provide the resulting merge from your given example and point to the data loss. |
Beta Was this translation helpful? Give feedback.
-
Yes, thats what I was trying to say... maybe it would also be better if we could improve the specification to avoid having to duplicate everything
You lose the relations between the dependencies since you put all the dependencies under the top level |
Beta Was this translation helpful? Give feedback.
-
I do not see this. Please provide the resulting merge from your given example and point to the data loss. |
Beta Was this translation helpful? Give feedback.
-
|
from the 2 boms I posted before you will have something like this, losing the relationship after level 2 <?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.3" serialNumber="urn:uuid:c337a0f7-82b6-49bf-abd2-95e37c7476c8" version="1">
<metadata>
<tools>
<tool>
<name>cyclonedx-maven-plugin</name>
<version>2.5.3</version>
</tool>
</tools>
<component bom-ref="pkg:maven/com.acme/acme-app@1.0.0" type="application">
<group>com.acme</group>
<name>acme-app</name>
<version>1.0.0</version>
</component>
</metadata>
<components>
<component bom-ref="pkg:maven/com.acme/acme-backend@1.0.0" type="application">
<group>com.acme</group>
<name>acme-backend</name>
<version>1.0.0</version>
</component>
<component bom-ref="pkg:maven/com.acme/acme-backend2@1.0.0" type="application">
<group>com.acme</group>
<name>acme-backend2</name>
<version>1.0.0</version>
</component>
<component bom-ref="pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.12.4" type="library">
<group>com.fasterxml.jackson.core</group>
<name>jackson-databind</name>
<version>2.12.4</version>
</component>
<component bom-ref="pkg:maven/com.fasterxml.jackson.core/jackson-annotations@2.12.4" type="library">
<group>com.fasterxml.jackson.core</group>
<name>jackson-annotations</name>
<version>2.12.4</version>
</component>
<component bom-ref="pkg:maven/com.fasterxml.jackson.core/jackson-annotations@2.12.5" type="library">
<group>com.fasterxml.jackson.core</group>
<name>jackson-annotations</name>
<version>2.12.5</version>
</component>
</components>
<dependencies>
<dependency ref="pkg:maven/com.acme/acme-app@1.0.0">
<dependency ref="pkg:maven/com.acme/acme-backend@1.0.0"/>
<dependency ref="pkg:maven/com.acme/acme-backend2@1.0.0"/>
</dependency>
<dependency ref="pkg:maven/com.acme/acme-backend@1.0.0">
<dependency ref="pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.12.4"/>
<dependency ref="pkg:maven/com.fasterxml.jackson.core/jackson-annotations@2.12.4"/>
</dependency>
<dependency ref="pkg:maven/com.acme/acme-backend2@1.0.0">
<dependency ref="pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.12.4"/>
<dependency ref="pkg:maven/com.fasterxml.jackson.core/jackson-annotations@2.12.5"/>
</dependency>
</dependencies>
</bom> |
Beta Was this translation helpful? Give feedback.
-
|
you lost the information because you decided to leave it out. <?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.3" serialNumber="urn:uuid:c337a0f7-82b6-49bf-abd2-95e37c7476c8" version="1">
<metadata>
<component bom-ref="merged" type="application">
<name>merged</name>
</component>
</metadata>
<components>
<!-- region: from A -->
<component bom-ref="A_pkg:maven/com.acme/acme-backend@1.0.0" type="application">
<group>com.acme</group>
<name>acme-backend</name>
<version>1.0.0</version>
</component>
<component bom-ref="A_pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.12.4" type="library">
<group>com.fasterxml.jackson.core</group>
<name>jackson-databind</name>
<version>2.12.4</version>
</component>
<component bom-ref="A_pkg:maven/com.fasterxml.jackson.core/jackson-annotations@2.12.4" type="library">
<group>com.fasterxml.jackson.core</group>
<name>jackson-annotations</name>
<version>2.12.4</version>
</component>
<!-- endregion: from A -->
<!-- region: from B -->
<component bom-ref="B_pkg:maven/com.acme/acme-backend2@1.0.0" type="application">
<group>com.acme</group>
<name>acme-backend2</name>
<version>1.0.0</version>
</component>
<component bom-ref="B_pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.12.4" type="library">
<group>com.fasterxml.jackson.core</group>
<name>jackson-databind</name>
<version>2.12.4</version>
</component>
<component bom-ref="B_pkg:maven/com.fasterxml.jackson.core/jackson-annotations@2.12.5" type="library">
<group>com.fasterxml.jackson.core</group>
<name>jackson-annotations</name>
<version>2.12.5</version>
</component>
<!-- endregion: from B -->
</components>
<dependencies>
<!-- no depedenncy is tied to the root component, because this would be pure speculation -->
<!-- region: from A -->
<dependency ref="A_pkg:maven/com.acme/acme-backend@1.0.0">
<dependency ref="A_pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.12.4"/>
</dependency>
<dependency ref="A_pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.12.4">
<dependency ref="A_pkg:maven/com.fasterxml.jackson.core/jackson-annotations@2.12.4"/>
</dependency>
<dependency ref="A_pkg:maven/com.fasterxml.jackson.core/jackson-annotations@2.12.4"/>
<!-- endregion: from A -->
<!-- region: from B -->
<dependency ref="B_pkg:maven/com.acme/acme-backend2@1.0.0">
<dependency ref="B_pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.12.4"/>
</dependency>
<dependency ref="B_pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.12.4">
<dependency ref="B_pkg:maven/com.fasterxml.jackson.core/jackson-annotations@2.12.5"/>
</dependency>
<dependency ref="B_pkg:maven/com.fasterxml.jackson.core/jackson-annotations@2.12.5"/>
<!-- endregion: from B -->
</dependencies>
</bom> |
Beta Was this translation helpful? Give feedback.
-
|
Regarding the bit on dynamic data addition, in my PRs I've explored logic
(in helper methods so potentially optional) which:
* updates document timestamp - it is neither of the originals' but one of
the product;
* generates doc uuid (ditto);
* adds cyclonedx-cli and lib as tools which generated the merged document.
At least, these theses can be defended :)
|
Beta Was this translation helpful? Give feedback.
-
|
Regarding parallelism and ordering - it depends. One of described use-cases
is to plaster licensing info based on the audience of the sold product. If
the merge strategy option is to replace these (not to have both possibly
present original licenses in the result), surely only a specific one of two
should remain.
|
Beta Was this translation helpful? Give feedback.
-
This is an OPEN DISCUSSION on how to merge two CycloneDX documents.
This should help understand edge cases, expectations and constraints.
General and specific questions are welcome. Please refrain from discussing (language/framework) specific implementation details or runtime goals.
Previous work and existing art
documents
You want to add one? request @CycloneDX/core-team to to so
implementations
CycloneDX/cyclonedx-climerge-commandCycloneDX.Utils/Merge.csSBOMMergetoolCycloneDX/cyclonedx-core-javasbomasmYou want to add one? request @CycloneDX/core-team to to so
Beta Was this translation helpful? Give feedback.
All reactions