Dependency Vulnerability Communication — Vocabulary

CVE triage: step 1: does your software use the vulnerable component? (SBOM helps here). Step 2: are you using the vulnerable version? Step 3: is the vulnerable code path reachable in your deployment? (reachability analysis). Step 4: what is the actual exploitability in your context? Step 5: remediation priority based on real risk, not just CVSS score.

Reachability analysis: a critical dependency with a critical CVE might not actually be exploitable in your context if your code never calls the vulnerable function. Tools (Snyk, Endor Labs, Semgrep Supply Chain) perform reachability analysis to reduce alert noise — flagging only vulnerabilities where the vulnerable code path is actually exercised.

Vulnerability MTTR: from disclosure (or detection in your environment) to fix deployed in production. Industry benchmarks: Critical CVEs should be remediated within 24-72 hours. High: 7-30 days. Medium: 30-90 days. Tracking MTTR reveals whether your vulnerability management process is effective — long MTTR signals process or resource gaps.

False positives are a major challenge in dependency scanning: a tool reports 50 critical vulnerabilities, but 40 of them are in test-only dependencies, 5 are in unreachable code paths, and 3 are in components not included in production builds. Reachability analysis and context-aware scanning reduce false positives and prevent alert fatigue.

Virtual patching: if updating a critical library is complex and risky (may break the application), a WAF rule or security control can block the specific attack vector while the proper fix is developed and tested. Virtual patching reduces the risk window but is not a permanent solution — it must be tracked and the underlying dependency must still be updated.