Clear Distinction between Direct and Transient Dependencies in UI and in Generated SBOMs

[flemminglau]

Current Behavior

Currently DT handles direct and indirect dependencies much the same. In case the loaded BOM has the information DT can show a hierarchy of interdependencies.

However even with this information there is no simple way to identify which dependencies are direct and which are transitive. The only way I can imagine one would distinguish would be to single out all components for which no other component depends. Not possible in the UI and not a trivial task via the API either.

PS: The reason this is important is since organizations may impose very different policies for addressing vulnerabilities raised on direct versus indirect dependencies. Not being able to indicate which dependencies are transient requires teams to treat all as direct until it can be determined that they are not.

Proposed Behavior

I suggest that DT performs the analysis of the Dependency Tree and marks the direct dependents with a flag.

The CycloneDX format could/should be improved as well to directly include this piece of information. DT could then include this information in generated SBOM.

The information would be redundant if the dependency tree is included but very helpful and could potentially be provided by the scanner in case it was capable even if it cannot generate the full dependency tree.

Checklist

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

[rkg-mm]

I agree, I would also need this. Could be shown as a flag in the table maybe? Also policies should maybe be allowed to be set to only affect "direct dependencies" - especially component age policy I could think of here.

[flemminglau]

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 distinction and allow filtering on it. And as mentioned above potentially allow different policies to apply for direct and transient dependencies.

[nscuro]

Note: We can analyze the BOM at ingest-time to easily determine which component is a direct dependency, and then store this info in a new column of the COMPONENT table.

Only caveat with the notion of direct dependencies is that it gets kinda blurry for merged SBOMs.

If the SBOM of project A is the result of merging the SBOMs from project B and C, then the dependency tree may look like this:

    --- B
  /
A
  \
    --- C

With the projects B and C now being the direct dependencies. But this may still be a "good enough" solution, because there is no straightforward way of figuring out the "real" direct dependencies in this scenario anyway, by just looking at the graph.

[rkg-mm]

Unless instead of storing the info "first level" we just store the "depth" from root, and allow a setting within the project like "external top level depth", which defaults to 1 but can be adjusted per project.

Alternatively: Improve how internal components can be marked* and check top level components against that, if its an internal component, check the next level - repeat until you find a non-internal component

*why improve: because the current regex solution is not very handy when working with a lot of different customers, all providing their own internal components, often with more than 1 way to identify them, so the regex would get very complex trying to do it all in one...

[flemminglau]

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 transient dependency.

In that case the 3 types of dependencies could be distinguished and different business rules applied to each o them.

[flemminglau]

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 sbomasm when performing hierarchical merges seem to assume that the sboms being merged are new second level nodes in the dependency hierarchy.

Provided that a SBOM merge typically will be performed on objects that are completely unrelated until they are "merged" into a common product delivery this seems like a strange convention.

I would have expected that the new sbom would simply merge the component containment hierarchies and leave (at least by default) the dependencies untouched.

Tools like DT would then look at the components and the dependency tree and realize that the SBOM contains a number of dependency trees (I assume that is why the tab can show a number. The number of trees.).

In this way it would also be able also for hierarchically merged sboms still to rely on the fact that the first level of dependencies in the dependency tree are the direct dependencies.

Am I completely off?