Reachability analysis changes how teams prioritise vulnerable packages

At a glance

What this is: Semgrep argues that reachability analysis narrows vulnerability triage to package functions that are actually callable in customer code, instead of ranking every advisory by CVSS alone.

Why it matters: This matters because security and IAM teams need to align remediation effort with exploitable paths, especially where software supply chain exposure intersects with workload and service identity.

Context

Reachability analysis is a control problem as much as a code-scanning problem. A vulnerability only becomes actionable when there is a real execution path from application logic to the risky function, so severity scores alone are a weak proxy for operational exposure.

In supply chain and dependency-heavy environments, that distinction affects how teams spend limited remediation time. For identity and access programmes, the same logic applies to non-human identities and service workflows: access, permissions, and execution paths matter more than the existence of a theoretical weakness.

Key questions

Q: How should teams prioritise vulnerable packages when only some functions are reachable?

A: Prioritise the package only when the vulnerable function is reachable in deployed code. A high CVSS score still matters, but it should not outrank a confirmed execution path. The best queue combines severity, actual usage, and call-path evidence so teams spend effort on exploitable exposure rather than theoretical risk.

Q: Why do runtime and reachability checks reduce vulnerability triage overload?

A: Because they convert a broad list of theoretical weaknesses into a smaller set of findings that an attacker can genuinely reach. When severity is filtered by production context, teams stop treating every critical as equally urgent and can focus scarce time on issues that change real risk.

Q: What do security teams get wrong about package vulnerability alerts?

A: They often treat package presence as equivalent to package exposure. That mistake causes teams to patch every advisory at the same pace, even when only a small subset of functions is actually callable. Better practice is to confirm the exact function, caller, and runtime condition before setting priority.

Q: What is the difference between severity scoring and reachability analysis?

A: Severity scoring estimates how bad a vulnerability could be in general, while reachability analysis tests whether the vulnerable code path exists in the application that is actually deployed. The first is a broad risk signal. The second is an exposure test that tells you whether the issue is actionable now.

Technical breakdown

How reachability analysis maps advisory risk to executable paths

Reachability analysis asks a narrow question: can application code actually call the vulnerable function under real runtime conditions? Semgrep describes a workflow that reviews advisories, reverse engineers patches, and traces call chains to determine whether a function is exposed through import paths, wrapper methods, or parameter values that control execution. That approach is more precise than advisory scoring because it separates theoretical vulnerability from exploitable vulnerability. It also explains why private-looking functions may still matter if public wrappers expose them.

Practical implication: triage vulnerabilities by reachable call path before assigning engineering effort.

Why CVSS alone is not enough for package prioritisation

CVSS is a useful severity baseline, but it does not tell you whether a package is actually used, reachable, or reachable in a dangerous way. Semgrep’s analysis highlights a common failure mode in dependency management: treating high scores, low scores, and unused libraries as if they deserve the same response. The more accurate model combines severity with ecosystem support, customer usage visibility, and whether a vulnerable code path exists in the deployed application. That is a governance issue, not just a scanning issue.

Practical implication: combine severity scoring with runtime reachability and actual dependency usage in your remediation queue.

What vulnerable function discovery means for secure code analysis

When a package advisory is incomplete, researchers have to infer the vulnerable surface by reading patches, checking callers, and distinguishing exposed public APIs from internal helpers. That is why rule writing becomes an evidence-based exercise rather than a pure matching problem. The security value comes from identifying the exact function or operation that introduces risk, then writing detection logic that follows the same execution path. In practice, this reduces noise and improves confidence in automated findings.

Practical implication: build detection rules around the specific function that creates exposure, not the package name alone.

Threat narrative

Attacker objective: The objective is to exploit a callable vulnerability in software supply chain dependencies that defenders have not prioritised because it looked important only on paper.

1. Entry occurs through a vulnerable open-source package that is imported into application code and therefore reachable at runtime.
2. Credential or data exposure happens when the vulnerable function is actually invoked through a legitimate call path rather than remaining dormant in the dependency tree.
3. Impact follows when teams patch everything by severity instead of by reachability, leaving exploitable package paths in production longer than necessary.

Breaches seen in the wild

• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
• SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Reachability is becoming the missing governance layer in software supply chain triage. Severity scoring tells teams what could matter, but not what can actually be hit in deployed code. Once dependency sprawl meets modern CI/CD, the control question becomes whether the vulnerable function is reachable through real application behaviour. Practitioners should treat reachability as a prioritisation gate, not a secondary refinement.

Package risk is only meaningful when execution context is known. The article shows why advisory management fails when teams stop at package names and version ranges. In practice, the exposed surface is the callable function, wrapper, or path that activates it, which means remediation has to follow code flow, not just inventory data. That is especially important for organisations with large transitive dependency estates.

Reachability analysis sharpens the boundary between signal and noise in vulnerability operations. The strongest concept here is callable exposure, not raw disclosure volume. That concept matters because teams that cannot distinguish reachable from unreachable issues will continue to burn time on low-value patching while missing real exploit paths. The practitioner takeaway is to make runtime reachability a first-class part of vulnerability governance.

This is also an identity governance problem when software components act as non-human identities. Service accounts, build tasks, and application components inherit privileges through code paths and package dependencies, so exploitability is partly a question of who or what can execute the risky function. That intersection makes NHI governance relevant even in a software supply chain story. Teams should map package reachability to the identities and permissions that make execution possible.

Observed vulnerability volume should never outrank exposed execution paths. The article’s core lesson is that risk concentration is created by reachable code, not by advisory count. For security programmes, this pushes vulnerability management closer to exploitability governance and away from checklist remediation. Practitioners should rank fixes by whether the vulnerable behaviour can be invoked in production.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Callable exposure is the control boundary that vulnerability programmes keep missing. Teams that organise remediation around advisory counts will continue to overinvest in dormant packages and underinvest in package paths that are actually executed. Reachability turns dependency management into an exposure management problem, which is where prioritisation should have been all along.

If an application security programme cannot show which package functions are reachable in production, it is not really prioritising risk. It is ranking disclosures. The operational change is to make code flow, runtime conditions, and dependency usage part of the same triage decision.

The same logic applies to software components that behave like non-human identities: access only matters when the identity can actually act. That is why runtime reachability is becoming a useful lens for broader identity-aware supply chain governance.

For practitioners

• Prioritise reachable vulnerabilities first Build remediation queues around functions that can actually be called in production code, then sort the queue by reachability and severity together.
• Trace package advisories to concrete call paths Require researchers or engineers to show the import chain, wrapper function, and runtime condition that exposes the vulnerable code before a ticket is escalated.
• Separate unused dependencies from exposed dependencies Track whether a library is present, imported, and reachable in deployed services, because those are different operational states with different risk.
• Write detection rules around vulnerable functions Use fully qualified function names and patch analysis to detect the exact API surface that introduces exposure, instead of flagging the whole package indiscriminately.

Key takeaways

• Reachability analysis reduces false urgency by separating merely disclosed package issues from functions that application code can actually invoke.
• The article’s strongest lesson is that severity scores alone do not tell teams which vulnerabilities are operationally exposed in production.
• Security teams should tie remediation to code paths, runtime conditions, and actual dependency usage before they assign priority.

Key terms

• Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
• Callable Exposure: The state where a vulnerable component is not just present in a dependency tree but can be reached and executed through real application behaviour. This is the practical threshold that turns a theoretical vulnerability into an operational risk.
• Software Supply Chain Vulnerability: A software supply chain vulnerability is a weakness that enters software through the people, code, tools, or services used to build, package, distribute, or update it. It can affect source code, dependencies, build systems, signing keys, or update channels, allowing attackers to alter trusted software before it reaches users.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.