Component detail view doesn't show vulnerabilities of its own sub-dependencies

[acoradd]

Hi,

Noticed something about how vulnerabilities are aggregated across views, wanted to share it as an idea.

Setup:

• Project A depends on component B
• Component B depends on component C

Current behavior:

• Project A's Audit Vulnerabilities tab: shows everything, vulns from A, B and C.
• Component B's detail page → Vulnerabilities tab: only shows B's own direct vulnerabilities. Nothing from C.

Idea:

Apply the same aggregation logic at the component level. When opening B, we'd see B's own vulnerabilities plus everything from its sub-tree (C, and anything below it), the same way the project view already aggregates the whole tree.

Why it'd help:

When triaging risk component by component, this would make it much easier to answer:

• Is upgrading B enough to clean up everything under it?
• Or is the real problem actually in C, meaning B just needs to bump its own dependency?

Right now this means manually cross-checking the dependency graph every time, which doesn't scale well on projects with deep trees.

Curious if others have run into this too, or if there's already a workaround I'm missing.

Thanks!

[jimklimov]

I've hit what I think is the same issue, asked about it on Slack, and then found this (sadly so far neglected) discussion. So will post a copy of my question from Slack, detailing the use-case we have.

---

Cheers, got a question from team-mates who consume the DTrack server I've set up (currently at v4.14.4): we track development tip and a number of older releases of our product as separate "Projects", populated from a big merged SBOM of the end-user delivery bundle. In other words, "our" multiple programs and containers are presented as components in different levels of the single-document SBOM tree of such one DTrack project, and recursing into their dependencies which are components on deeper levels of same tree. Over time, individual third-party components are inevitably assigned known vulnerabilities.

If I click into the page for a vulnerable dependency component, I get the counts, tabs with a graph and list of vulnerabilities, etc. (see attachments below)

• Example third-party component pages that I meant:

  • 
  • 

• Example overall project overview reflecting the mess recursively:

  • 

However, when we click into pages for our own components, the counts are zero and the graph is flatlined, even for components tracked for years (old releases).

• 

MY GUESS is that the page is based on direct hits from vulnerability databases, and since our internal components are not announced worldwide, there are no hits. Is this assessment right?

Colleagues call this "sort of misleading" and ask if there is some page that would reflect indirect vulnerabilities which impact a given component by walking the graph recursing into its vulnerable dependencies? Something similar to what the overall project page shows as a summary of the mess inside?

It is understandable that not all usages are vulnerable, that's why there are pages to track analysis and verdicts for these basic alerts, and so gauge if our delivered software needs fixing or just does not step on somebody else's landmine... but for a team member that owns program X (one of dozens or hundreds in the bundle SBOM) it would be beneficial to see if this particular program needs at least attention for such analysis. (The project-wide list of hundreds of repetitive vulnerabilities referencing different usages/points in the graph is not helpful for them for this work).

[nscuro]

@acoradd Apply the same aggregation logic at the component level. When opening B, we'd see B's own vulnerabilities plus everything from its sub-tree (C, and anything below it), the same way the project view already aggregates the whole tree.

It's important to understand that dependencies are not a tree, but a graph. While C may be introduced through B, it may also introduced through other ways (e.g. A <- Z <- Y <- C).

Which version of transitive dependencies is being picked depends on the respective package manager's logic. Maven uses "nearest wins", Go uses a different approach, and so on. Dependency-Track cannot know these details from an SBOM alone, so "bump this component and all transitive issues go away, too" is not something we could reliably advertise.

Showing an aggregate of vulnerabilities for "B's own vulnerabilities plus everything from its sub-tree" will in most cases not suffice to answer "Is upgrading B enough to clean up everything under it?".

@jimklimov MY GUESS is that the page is based on direct hits from vulnerability databases, and since our internal components are not announced worldwide, there are no hits. Is this assessment right?

Yes. The vulnerabilities page on a given component only shows that specific component's vulns.

Colleagues call this "sort of misleading" and ask if there is some page that would reflect indirect vulnerabilities which impact a given component by walking the graph recursing into its vulnerable dependencies?

See my response above.

Something similar to what the overall project page shows as a summary of the mess inside?

Note that the project page operates on "contains these components" semantics, not strictly on "depends on these components". A project can contain components without having explicit dependencies to them. What you're asking for in the component view would be "depends on these components", which is a different concept.