How should security teams prioritise dependency vulnerabilities when reachability analysis is available in multi-language codebases?

Security teams should prioritise findings by whether vulnerable functions are actually called in reachable code paths, not by package presence alone. That approach cuts alert noise, focuses remediation on exploitable issues, and helps developers spend time on defects that matter. In mixed Java and Kotlin environments, dataflow analysis is especially useful because it shows how dependencies are used across application logic, not just whether they exist.

Why reachability beats package counts in dependency triage

reachability analysis changes the unit of prioritisation from “a vulnerable library exists somewhere in the build” to “this vulnerable code can actually be invoked by the application.” That matters because package inventories overstate exposure in multi-language codebases, where transitive dependencies, shaded artifacts, and platform-specific modules can inflate findings without increasing exploitability. Teams get a smaller, more defensible queue when they focus on reachable call paths.

That shift is especially important in mixed-language systems because the same dependency may be present in Java, Kotlin, or other runtime-adjacent layers but only become relevant when a concrete dataflow connects user input, framework code, and the vulnerable function. Reachability also helps separate true remediation work from dependency hygiene work, so teams can reserve urgent response for issues that sit on an actual execution path.

For open source supply chain context, OpenSSF is useful background on securing and evaluating software dependencies, while the CISA Known Exploited Vulnerabilities Catalog helps teams separate theoretically vulnerable packages from issues already being exploited in the wild.

How to interpret reachability signals across Java and Kotlin code

In Java and Kotlin environments, the most useful question is not whether the dependency appears in a manifest, but whether application logic can flow into the vulnerable method under realistic execution conditions. Static analysis, call graph construction, and dataflow tracing can show whether the risky API is gated behind dead code, test-only paths, feature flags, or error handling branches that never execute in production.

Kotlin adds some practical wrinkles: higher-order functions, null-safety, extension functions, and coroutine-based flows can make the vulnerable path less obvious than in straight-line Java code. A good triage workflow therefore combines package intelligence with code-level evidence, then ranks findings by whether the reachable path is production-relevant, externally influenced, and reachable without unrealistic preconditions.

For teams building a repeatable process, CIS Controls v8 provides a practical control backdrop for vulnerability management, and NIST Cybersecurity Framework 2.0 is a useful high-level way to connect dependency triage with identify, protect, detect, respond, and recover activities.

What should move to the top of the queue

The highest-priority findings are the ones where reachability is proven and the vulnerable function sits on a path that can be influenced by untrusted input, used in production, or exposed through common request handling. Those are the findings most likely to translate into practical exploitability, especially when the vulnerable package also appears in multiple services or is used at high scale across a build graph.

Lower priority usually belongs to dormant paths, test scaffolding, documentation examples, or libraries that are present only as transitive baggage and never executed in the shipped artifact. Current guidance suggests that remediation teams should treat reachability as a risk filter, not as a complete verdict: a reachable issue is not automatically exploitable, but an unreachable one should rarely displace work on a proven call path.

When the dependency risk is real, the most relevant references are the EU Cyber Resilience Act for product security and vulnerability handling expectations, and CIS Controls v8 for operationalising vulnerability prioritisation and remediation.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	7 — Continuous Vulnerability Management	Prioritises remediation based on validated exposure and exploitable conditions.
Recommendation — Use continuous vulnerability management to rank reachable findings ahead of inert package alerts.
NIST CSF 2.0	ID.RA-05 — Threats, vulnerabilities, likelihoods, and impacts are used to determine risk	Reachability is a vulnerability signal that materially changes risk prioritisation.
	PR.IP-12 — A vulnerability management plan is developed and implemented	Reachability analysis improves how teams implement and sequence remediation.
	DE.CM-08 — Vulnerability scans are performed	Static and SCA findings need validation against runtime reachability to reduce false priority.
Recommendation — Use risk analysis to weight reachable vulnerabilities above mere inventory presence. Embed reachability into your vulnerability management workflow to focus remediation. Correlate scan results with reachability evidence before escalating remediation.

Practitioner Guidance

What to prioritise: Start with findings where reachability is proven and the vulnerable function is on a production path that can be reached from external or semi-trusted input. Defer findings that are only present in manifests, unused modules, or non-shipped code unless other evidence suggests they are active.

What to verify: Confirm that the analysis matches the built artifact, not just the source tree, and that language boundaries are handled correctly when Java calls Kotlin code or vice versa. Teams often overtrust raw package data because it is easy to collect, but the decisive question is whether the vulnerable method is in a live path that can actually execute.

Practitioner takeaway: Use reachability to reduce noise, but keep exploitability as the final judgement, because the best triage result is a queue ordered by real execution risk, not by how many vulnerable packages were discovered.