flemminglau

For purposes of CycloneDX note that the format allows `"license": {"id": "SPDX ref"}` or alternatively if it cannot be matched: `"license": {"name": "any text you want"}` It would be great...

Looking at this again it seems that the cyclonedx-cli approach may not be useful. As we cannot assume that an SBOM contains dependency information it cannot be assumed that the...

Looking at the description of Assemblies in the CycloneDX specification I am wondering why the merge functionality in the cyclonedx-cli does not at least have an option to define one...

But while we are waiting for the "real" solution would it not be better to report unknown (unmapped) licenses as "whatever" than not reporting them at all?

As a first step if at least DT would avoid loosing the additional licenses. I.e. so that an SBOM imported into DT would preserve the license information when exporting as...

> @flemminglau is the hierarchical merge not what you're after? What's missing? You may be right. In that case what's missing is me understanding what a hierarchical merge is. It...

Maybe as an alternative somehow the internal components could be marked using the author, publisher or some other field. Just to ensure that the information that a module is internal...

Alternatively scanners should be enhanced (provided a mechanism is available in the cyclonedx format) to mark top level dependencies as direct and all others as transient. Still DT should understand...

This is still a challenge for merged SBOMs. The SBOM formats really need a way to indicate if a dependency is an (internal) component or an external either direct or...

Maybe I am missing something here but: Is it not true that the CycloneDX spec clearly distinguishes between "component containment" and "dependencies"? I have seen that tools like cyclonedx-cli and...