DT needs to handle package pedigree information in CDX components

[nigellh]

Current Behavior

At the moment DT only seems to handle components in an SBOM as defined in https://cyclonedx.org/docs/1.5/json/#components.

Proposed Behavior

Since CDX 1.4, it has been possible to add additional metadata to refine what a package might consist of particularly in the pedigree field of components - https://cyclonedx.org/docs/1.5/json/#components_items_pedigree.

The basics of a component/package seem to be handled well from an SBOM in DT. Unfortunately, packages in code are not that simple and a single package might have a number of different complexities. Here are some:

• Some companies will take the source code for a package and build it themselves. The build process can rename this to something that will not be recognised by DT. For example, org.apache.commons@commons-lang3 becomes org.company.name.commons-lang3.jar. It is exactly the same package, license, copyright and so on, but it cannot be correctly identified by tooling. The package name has to go into the SBOM as this and the purl will not be relevant if there.
• A file such as jquery.js is found. Is this the actual jquery.js or is it a file from the jQuery Node Module. If the second, then it needs to be correctly identified to that package.
• Many companies combine numerous open source packages into a single file. Node Modules commonly have single JS files taken from them and combined into a single uber JS. Often called chunk*.js, index*.js or some other variation. This package has to be listed in the SBOM and all the package that make it up have to be listed against it. The same can apply to Java, Python, Go and so on.
• A company might include part of an open source package in one of theirs or have forked one and renamed it. These need to by identified correctly

I come across these all of the time and I am sure there are many other examples. Technically, because we have the inability to do this, we are missing many vulnerabilities without some clever playing around and creating invalid SBOMs, even if temporarily.

The point is a single file can have a single or multiple open source parts to it and these need to be correctly identified.

I work with Matt Rutkowski (IBM) and his understanding is that this should go in the https://cyclonedx.org/docs/1.5/json/#components_items_pedigree_ancestors section of a package. This will allow analysts to correctly list the original package as a component but also list all the open source parts that are used within it in that section.

This field is an array and is the same content as the original component so the processing for the original component should be able to be reused here 🤞

I had a good look at the other entries and not sure I found a comparable one. My apologies if I missed it.

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this enhancement was already requested