Reachability analysis changes how teams prioritise vulnerable packages

At a glance

What this is: Semgrep explains how reachability analysis helps teams decide which open-source vulnerabilities merit immediate attention by tracing whether a vulnerable function is actually callable from user code.

Why it matters: This matters because IAM and security teams often inherit the downstream impact of vulnerable software dependencies, where prioritisation, privilege scope, and runtime exposure can determine whether an issue becomes an incident.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Semgrep's analysis of reachability analysis for vulnerability prioritisation

Context

Reachability analysis is a way of separating theoretical vulnerability from practical exploitability. Instead of treating every advisory as equally urgent, it asks whether the vulnerable function is actually invoked in the code paths a real application can reach. For application security programmes, that distinction matters because triage quality determines where engineering time, patching effort, and access review focus.

This is also an identity and governance problem in practice. Vulnerable packages often expose secrets, tokens, or other non-human identities indirectly through build pipelines and dependency chains, which means the security question is not only whether code is vulnerable but whether the surrounding access model allows that vulnerability to be triggered and abused. The teams that get this right treat exposure as a lifecycle issue, not a static vulnerability list.

Key questions

Q: How should security teams prioritise vulnerable packages in large codebases?

A: Prioritise packages by whether the vulnerable code is reachable from real application paths, not by CVSS alone. Combine exploit conditions, patch evidence, dependency usage, and runtime behaviour to separate dormant exposure from triggerable risk. That approach reduces noise and focuses remediation on flaws that can actually be exercised in production.

Q: Why does reachability analysis improve vulnerability management?

A: Reachability analysis improves vulnerability management because it ties a vulnerability to actual execution paths. A package can look severe on paper yet never be invoked by the application. By checking whether the vulnerable function is callable, teams can make better remediation decisions and avoid wasting effort on issues that cannot be triggered.

Q: What do security teams get wrong about vulnerability prioritisation?

A: Security teams often treat vulnerability scores as if they represent operational risk on their own. In practice, a score only matters when the asset can reach something important. Graph analysis corrects this by showing which weaknesses are connected to critical systems, where lateral movement is possible, and which routes attackers are most likely to use.

Q: How do you know if a vulnerability rule is accurate enough to trust?

A: A trustworthy rule should align with a clearly identified vulnerable function, reproduce the expected trigger path, and avoid broad matches that create false positives. Test it against positive and negative cases drawn from real code patterns. If the rule cannot distinguish the vulnerable call path from safe usage, it is not ready for production.

Technical breakdown

How reachability analysis narrows vulnerability priority

Reachability analysis examines whether a vulnerable function, method, or code path can actually be invoked by an application. A package may contain a CVE, but if the affected function is private, unused, or gated behind parameters the application never passes, the practical risk is much lower than the advisory alone suggests. This is why reverse engineering patches matters: it reveals which symbols changed and how the exploit path works. The point is not to ignore vulnerable dependencies but to distinguish triggerable exposure from dormant presence.

Practical implication: prioritise remediation based on callable paths and runtime usage, not advisory volume alone.

Why advisory quality changes rule accuracy

Well written advisories provide the function name, exploit conditions, patch references, and sometimes proof-of-concept detail. Poor advisories omit the exact exported function or hide the fix inside a large diff, which forces researchers to infer the vulnerable boundary by tracing source changes and caller relationships. That extra uncertainty affects static rules, because an imprecise rule either misses real exposure or creates false positives that teams stop trusting. In other words, disclosure quality directly shapes the precision of AppSec controls.

Practical implication: feed rule-writing workflows with advisories that expose functions, fix commits, and triggering conditions.

Why secrets exposure is an identity governance issue

Open-source vulnerability management often intersects with secrets management because exploitable code paths can reveal credentials, tokens, or service account material embedded in repositories and pipelines. Once those secrets exist, the issue becomes lifecycle governance: whether they are discovered, rotated, revoked, and scoped to the minimum necessary privilege. That is where the NHI angle enters. A secret is a non-human identity artefact, and if the access it grants is not tracked through its lifecycle, the vulnerable package becomes an identity exposure point as much as a software flaw.

Practical implication: connect dependency risk workflows to secrets inventory, rotation, and non-human identity governance.

NHI Mgmt Group analysis

Reachability is the missing control layer between vulnerability discovery and actual exploitability. Static inventory alone tells teams that a package exists, but not whether the vulnerable path can be reached in production. That gap is why so many programmes drown in advisory backlogs. Reachability analysis turns vulnerability management into exposure management, which is the more useful security question for modern software estates. Practitioners should treat callable-path analysis as a priority filter, not an optional refinement.

Function-level exposure creates a quieter form of risk than mass compromise, but it is still governance failure. The article shows that the difference between a vulnerable library and a vulnerable application often comes down to whether a specific function can be triggered. That is a control problem, not a patching problem alone. If teams cannot map package behaviour to code execution paths, they cannot defend their prioritisation decisions. Practitioners should require evidence of triggerability before escalating every advisory to the same tier.

Secrets and non-human identities sit downstream of software vulnerability decisions. Vulnerable packages are often one hop away from credentials, tokens, and service accounts that power build systems and application workflows. That makes reachability a governance input for NHI management, because the blast radius of a reachable flaw depends on what secret material or privileged workload identity sits nearby. In this sense, vulnerability triage and NHI inventory should be treated as linked controls, not separate programmes. Practitioners should align AppSec findings with secrets lifecycle oversight.

Semgrep's workflow reflects where application security tooling is heading: from detection to decision support. The value is not merely in finding more issues, but in helping teams decide which issues affect actual runtime paths. That aligns with modern security operations, where noise reduction is a prerequisite for action. The broader market signal is that code scanning is becoming more contextual and less binary, which should push governance teams toward richer evidence standards for remediation prioritisation. Practitioners should expect risk scoring to become increasingly context-aware.

What this signals

Exposure triage is becoming a governance control, not just an AppSec workflow. As code scanning matures, teams will be judged less on how many vulnerabilities they find and more on whether they can prove which ones are actually reachable. That pushes programme owners to connect static analysis, runtime context, and dependency usage into a single prioritisation model. The practical result is fewer blanket escalations and more evidence-led remediation.

Reachability-driven AppSec also strengthens secrets governance. Once a vulnerability can be linked to reachable code paths, the next question is whether that path exposes credentials, tokens, or other non-human identity material. Teams should be aligning vulnerability triage with OWASP Non-Human Identity Top 10 thinking and hardening the lifecycle of secrets rather than relying on discovery alone. Reachable secret exposure: when vulnerable code paths intersect with valid credentials, the issue becomes both an AppSec and identity problem.

Security leaders should expect more tooling that helps separate theoretical exposure from actionable exposure. That is useful only if the organisation also has disciplined remediation, rotation, and offboarding processes for the identities and secrets touched by those paths. If the same leaked credential can survive for weeks, the organisation is still converting code risk into persistent identity risk.

For practitioners

• Build reachability into vulnerability triage Require security teams to distinguish between vulnerable packages present in a repository and vulnerable code paths that are actually callable from application entry points. Use patch diffs, caller tracing, and symbol analysis to justify priority.
• Link dependency findings to secrets inventory When a reachable flaw touches build systems, deployment pipelines, or application configuration, check whether tokens, API keys, or service account credentials are in scope. Tie the finding to the secrets inventory before assigning remediation priority.
• Use advisory quality as a review criterion Track whether advisories include the affected function, exploit condition, and fix reference. If those details are missing, require deeper reverse engineering before a rule is promoted into production workflows.
• Separate dormant exposure from active exposure Treat libraries with no triggerable path as lower urgency than libraries whose vulnerable function is invoked by known application behaviour. This prevents scarce engineering time from being consumed by theoretical risk that cannot be exercised.

Key takeaways

• Reachability analysis matters because a vulnerable dependency is only operationally urgent when the affected code path can actually be invoked.
• Advisory quality, caller context, and runtime usage determine whether a rule is accurate enough to drive remediation decisions.
• Vulnerability triage and non-human identity governance should be linked, because reachable flaws often expose secrets, tokens, and service accounts.

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.
• Vulnerable Function: The specific function, method, or code routine that contains the flaw described in an advisory. Identifying the vulnerable function is critical because it defines the boundary of real risk and allows teams to build precise detection or remediation rules.
• Secrets Lifecycle: Secrets lifecycle is the management of credentials from issuance through rotation, revocation, and offboarding. It matters because a secret that is technically valid can still be operationally unsafe if its owner, purpose, or downstream access paths are no longer current.

What's in the full article

Semgrep's full post covers the operational detail this post intentionally leaves for the source:

• Its step-by-step rule-writing workflow for identifying a vulnerable function from an advisory and patch diff.
• Its examples of how researchers separate public caller paths from internal helper functions when building a rule.
• Its testing approach for reducing false positives and false negatives before rules ship to users.
• Its internal automation model for queueing advisories and routing them into rule development.

👉 Semgrep's full post covers the advisory review workflow, rule construction steps, and testing approach in more operational detail.

Deepen your knowledge

NHI Mgmt Group's NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to broader security operations and risk decisions.