Topic starter
02/08/2026 12:27 pm
TL;DR: Reachability analysis narrows vulnerability triage to package functions that are actually callable in customer code, Semgrep reports, instead of ranking every advisory by CVSS alone. Prioritisation then follows the code paths and runtime conditions that show whether exposure is real in production.
Editorial analysis by NHI Mgmt Group, based on content published by Semgrep: “A day in the life: Supply Chain Security Researcher”.
Key questions
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.
Q: What do security teams get wrong about package vulnerability alerts?
A: They often treat package presence as equivalent to package exposure.
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.
Practitioner guidance
- 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.
Bottom line: Reachability analysis reduces false urgency by separating merely disclosed package issues from functions that application code can actually invoke.
Glossary terms: Reachability analysis, Callable Exposure, Software Supply Chain Vulnerability
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
02/08/2026 1:26 pm
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.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: Reachability analysis changes how teams prioritise vulnerable packages