Topic starter
11/11/2026 5:57 pm
TL;DR: Dependency findings still overwhelm teams when scanners stop at reachability instead of proving exploitability, Maze reports. SCA has to move from possible exposure to evidence-backed risk decisions that reflect how code actually runs.
Editorial analysis by NHI Mgmt Group, based on content published by Maze: “SCA that investigates every dependency like your best security engineer”.
Key questions
Q: How should teams prioritise dependency vulnerabilities in production?
A: Prioritise production dependency vulnerabilities by exploitability, exposed runtime path, privilege level, and whether the affected component is actually loaded or invoked.
Q: How do SCA tools prove whether a vulnerable package matters?
A: SCA tools prove relevance by matching the vulnerable component to the exact version in use, then checking whether the vulnerable code is reachable through the runtime call path.
Q: What is the difference between reachability and exploitability in vulnerability prioritization?
A: Reachability asks whether the vulnerable code path is actually called by your application, while exploitability asks whether attackers can realistically use the flaw in the wild.
Practitioner guidance
- Instrument dependency triage for exploitability, not just reachability Require each high-severity finding to show the exact call path, the triggering condition and the runtime setting that would have to be abused before it becomes an engineering ticket.
- Link build artefacts to deployed workload context Correlate manifest data, resolved package versions and deployment metadata so remediation decisions reflect where the vulnerable code actually runs.
- Suppress non-exploitable dependency findings with evidence Close findings only when the investigation proves an attacker cannot control the vulnerable input, feature state or execution path in the target environment.
Bottom line: Dependency scanners are most useful when they distinguish theoretical exposure from flaws that can actually be triggered in the deployed application.
Glossary terms: Exploitability, Software Composition Analysis, Reachability analysis, Transitive Dependency
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/11/2026 5:57 pm
Exploitability is the governance gap that matters, not version exposure alone. Dependency scanners that stop at detection leave security teams with a list of possible problems, not a decision about actual risk. The deeper issue is that many programmes still treat the presence of a vulnerable package as the control objective, even though the real question is whether the application can be driven into the vulnerable state. That shifts the governance burden from inventory to proof, which is where SCA becomes operationally useful.
A question worth separating out:
Q: Can a vulnerable dependency be safe to leave in place?
A: Yes. A vulnerable dependency can sometimes remain in place if the vulnerable code path is unreachable, the package is isolated, or a compensating control blocks exploitation. Common examples are dead code, optional features that are disabled, or a library present only for build time. The decision should be based on reachability, exposure, and compensating controls, not the CVE alone.
👉 Read our full editorial: Exploitability evidence makes dependency alerts more actionable