Say that your inventory includes transitive dependencies, that findings in them are triaged by whether the vulnerable code is actually used, and that you have a way to force an upgrade when a direct dependency has not yet moved. Direct dependencies alone are an incomplete answer.
What "transitive" means
A direct dependency is a package your code names. A transitive dependency is one that your direct dependency needs, and so on down the tree. You did not choose it, but you ship it. Lockfiles record the full tree, and an SBOM lists it so that others can inspect it.
CISA's SBOM guidance describes a nested inventory, which is the right picture: components inside components.
What customers want to hear
- You can list the full tree for each release.
- New advisories are matched against the whole tree, not just top level packages.
- You can tell which findings matter, so engineers do not chase unreachable code.
- You can fix when the direct package is slow to update.
The practical options for a flagged transitive package
| Situation | Typical response |
|---|---|
| Newer direct dependency pulls a fixed version | Upgrade the direct dependency |
| Direct dependency is slow to update | Override the transitive version, then test |
| Vulnerable code is not called | Record as not exploitable, with the reasoning |
| No fix exists | Mitigate, isolate or replace the direct dependency |
Overrides are legitimate, but each one is a decision you now own. Keep a list and review it, because stale overrides become their own risk.
Reachability matters here more than anywhere
Transitive trees are large, so raw advisory counts can look alarming while the real exposure is small. Reachability analysis checks whether the vulnerable function is called from your code paths. It does not replace judgment, but it focuses it.
NIST SP 800-218 asks producers to analyze each vulnerability for risk (RV.2.1) and to automatically review composition data for new vulnerabilities (RV.1.1). Reachability is one way to do the analysis step at scale.
Reply template
Our inventory lists direct and transitive components for each release. Advisories are matched against the full tree. We prioritize by exposure, including whether the vulnerable code is reachable, and use version overrides when a direct dependency lags. Overrides are tracked and reviewed.
What to show
Offer a view of a real dependency tree for a component that was flagged, the path from your direct dependency to the vulnerable package and the decision that followed. One worked example demonstrates the process better than a general statement, and it shows that your team reads the tree instead of just the summary count.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare the finding count before and after the reachability view, and note which transitive findings drop out and why.
Safeguard includes reachability analysis alongside dependency scanning and SBOM generation.
Quick check
Can we ignore transitive findings that are not reachable?
You can deprioritize them with a recorded reason, then revisit when code or the advisory changes.
Is overriding a transitive version risky?
It can break compatibility, so test it. Track each override so it does not linger after the parent catches up.
Sources
Last reviewed: 19 October 2026.
