How to Triage Vulnerabilities in Transitive Dependencies Without Drowning in Noise

A direct dependency is a package you explicitly imported: it is in your package.json, requirements.txt, pom.xml, or go.mod. A transitive dependency is any package that your direct dependencies import, plus any packages that those packages import -- the full dependency tree.

The vulnerability report noise problem is structural. When lodash has a vulnerability, every package that depends on lodash generates a finding in your scan -- even if your code only uses the five lodash functions that have nothing to do with the vulnerable code path. When a logging library's dependency has a vulnerability, every application using that logging library has the finding -- even if the vulnerable feature of the dependency is never invoked by the logging library's code paths that you call.

The scanner cannot see which specific functions your application calls. It sees what is installed. It reports vulnerabilities in everything installed. This is technically correct -- the vulnerable code is present in your dependency tree -- but operationally misleading because most of those code paths are dead code in your specific deployment.

The 2023 Log4Shell response illustrated this at scale: organizations spent enormous effort patching Log4j2 deployments where the JndiLookup class that enabled the exploit was present but JNDI lookups were never performed, while the same organizations had other Log4j2 deployments where JNDI lookups were active and the risk was genuinely critical. Reachability analysis is what distinguishes these two scenarios.

Reachability analysis determines whether the vulnerable code path in a dependency is actually called by your application. A vulnerability in a package is only exploitable if the code path containing the vulnerable function is reachable from your application's call graph.

Tools that perform reachability analysis or reachability filtering:

Snyk (with reachability analysis enabled for Java and Python): For Java (Maven and Gradle) and Python applications, Snyk performs static call graph analysis to determine whether the vulnerable function in a dependency is called by your application code. Findings where the vulnerable function is not reachable are surfaced with a "Not Reachable" label. This does not mean the vulnerability is false -- it means it is unexploitable in your specific deployment.

Google OSV-Scanner: The open-source OSV scanner queries the OSV database and can filter results by package-level reachability for Go modules. Less precise than full call graph analysis but useful for Go ecosystems without Snyk coverage.

Semgrep Supply Chain: Performs reachability analysis for Python and JavaScript by analyzing import paths and function call chains. Shows which findings are reachable from your application's code.

Endor Labs: Provides reachability analysis across multiple languages with dependency graph visualization showing exactly which call path connects your code to the vulnerable function.

For ecosystems where reachability analysis tooling is not available (some Ruby, PHP, or older Java configurations), apply the manual reachability heuristics: if the vulnerable function is in a package feature that your application explicitly disables or never configures, the risk is substantially lower than the CVSS score implies.

Categorize every transitive dependency finding into one of three tiers immediately after the scan:

Tier 1: Confirmed reachable and exploitable. The vulnerable function is called from your application's code path, confirmed by reachability analysis or manual code review. Treat these as you would any other critical vulnerability: assign an owner, set a remediation SLA based on severity, and track to closure. These are typically 5 to 20% of total findings for most applications with good reachability analysis tooling.

Tier 2: Confirmed not reachable in current deployment. The vulnerable function is not called from your application's code path, confirmed by reachability analysis. The vulnerability is present in the installed code but unexploitable given how you use the library. Action: document the finding with the reachability determination, note the next review date (when the application's code or the dependency's version changes), and deprioritize remediation until a reachability-changing event occurs. Do not suppress the finding -- mark it as "risk accepted pending upstream fix" with the reachability justification.

Tier 3: Reachability unknown. Your tooling cannot determine reachability for this finding (ecosystem not supported, call graph analysis failed, or the vulnerability is in shared library code with no clear function-level attribution). Use EPSS score as the secondary filter: EPSS above 0.3 (30% exploitation probability) means treat as Tier 1 and investigate reachability manually. EPSS below 0.1 means document as Tier 2 equivalent with the justification "low exploitation probability, reachability unconfirmed." EPSS between 0.1 and 0.3 means schedule a manual reachability check within 30 days.

Transitive dependency vulnerabilities often cannot be fixed by directly updating the vulnerable package because it is not in your direct dependency list. The update path depends on your package ecosystem and the dependency graph structure.

Resolution override (npm resolutions, pip constraints). In npm, the package.json resolutions field forces a specific version of a transitive dependency regardless of what version the parent package requests. This is a workable short-term fix for critical vulnerabilities where the parent package's maintainer has not yet released an updated version. Caution: resolution overrides can break the parent package if the forced version has incompatible API changes. Test thoroughly after applying a resolution override.

Parent package update. If the vulnerable transitive dependency is fixed in a newer version of your direct dependency, updating the direct dependency is the cleanest fix. Check the changelog and release notes of the direct dependency for security fix references.

Exclusion and replacement. For Maven, pom.xml exclusions remove a specific transitive dependency from the build entirely. Combined with a direct dependency declaration of the patched version, this produces the same result as a resolution override. For pip, constraints files serve the same function.

Waiting for upstream. When none of these options are available (the direct dependency does not yet have a release with the fixed transitive dependency version, and a resolution override would break functionality), document the finding as "pending upstream fix" with the CVSS score, EPSS score, the specific version required to resolve it, and the date you confirmed the upstream fix is not yet available. Review this category monthly and escalate if a Tier 1 equivalent finding remains pending upstream fix for more than 30 days.

An SBOM (Software Bill of Materials) is the complete inventory of every package -- direct and transitive -- in your application build. SBOM generation has moved from a compliance checkbox to an operational requirement as the volume of transitive dependency vulnerabilities has made undocumented dependency trees unmanageable.

Two SBOM formats are in common use: SPDX (maintained by the Linux Foundation) and CycloneDX (maintained by OWASP). Both are machine-readable JSON or XML formats that enumerate every package, version, and license in the dependency tree. Most major build tools have SBOM generation plugins: cdxgen for npm and Python, syft for container images, and the Maven CycloneDX plugin for Java.

The operational value of an SBOM in transitive dependency management is threefold: it enables you to query "which of our applications are affected by CVE-XXXX-XXXXX in package-name version X.X.X?" without scanning every repository independently, it provides the inventory for reachability analysis tools (SBOM as input rather than repository scan), and it serves as the compliance artifact for supply chain security requirements including Executive Order 14028 for US federal software vendors and emerging EU requirements.

Generate SBOMs at build time as part of your CI pipeline and store them with the build artifacts. This produces a point-in-time record of the dependency tree for each deployed version -- which is the artifact you need to answer "were we affected by this vulnerability at the time of this specific deployment?" when a new CVE is published against a package you may have used.

The reason most organizations have hundreds of open transitive dependency findings is that their SLA policy treats all SCA findings the same as direct dependency findings and first-party code vulnerabilities. A SLA that requires patching every transitive dependency within 30 days of discovery is operationally impossible given the volume -- so engineering ignores it entirely.

A SLA designed for transitive dependency reality distinguishes three scenarios:

Confirmed Tier 1 (reachable and exploitable): Treat as equivalent to a first-party vulnerability. SLA follows your standard severity-based schedule: critical within 7 days, high within 30 days, medium within 90 days.

Tier 3 (unknown reachability) with EPSS above 0.3: Perform reachability determination within 7 days. If confirmed reachable, apply Tier 1 SLA. If confirmed not reachable, reclassify to Tier 2.

Confirmed Tier 2 (not reachable): Review within 90 days or when any of the following occur: the affected version of the direct parent dependency is updated (which may change which version of the transitive dependency is installed), the application code that could create a reachable path is modified, or an upstream fix is available that can be applied without introducing breaking changes.

Present this tiered SLA to engineering leadership with the finding distribution from your last scan (what percentage of findings are in each tier). If 80% of your current findings are Tier 2, the tiered SLA reduces the active remediation burden by 80% while still ensuring Tier 1 findings are treated with appropriate urgency.