Topic starter
02/08/2026 12:27 pm
TL;DR: Rule writing can focus on packages and functions that can actually be triggered in customer code by using reachability analysis, patch review, and vulnerability prioritisation, rather than treating every advisory as equal, according to Semgrep. The real lesson is that exposure management breaks down when severity is separated from runtime reachability and usage context.
Editorial analysis by NHI Mgmt Group, based on content published by Semgrep: “A day in the life: Supply Chain Security Researcher”.
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.
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.
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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
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