Notifications
Clear all
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.
NHIMG editorial — based on content published by Semgrep: a day in the life of a security researcher on the software supply chain team
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
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.
Q: Why does reachability analysis improve vulnerability management?
A: Reachability analysis improves vulnerability management because it ties a vulnerability to actual execution paths.
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.
Practitioner guidance
- 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.
- 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.
- Use advisory quality as a review criterion Track whether advisories include the affected function, exploit condition, and fix reference.
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.
👉 Read Semgrep's analysis of reachability analysis for vulnerability prioritisation →
Reachability analysis and vulnerable packages: what IAM teams should note?
Explore further
02/08/2026 1:26 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Reachability analysis changes how teams prioritise vulnerable packages
