TL;DR: Noise from dependency scanners still obscures real risk when tools can see a vulnerable package but not whether it is exploitable in the application, according to Maze. The practical shift is from reachability alone to evidence-driven triage that ties code paths, runtime context and exposure together before a ticket is raised.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Maze's blog post: Software composition analysis becomes materially more useful when it proves whether a dependency flaw is exploitable in the target environment.
Why it matters: IAM, NHI and application security teams need evidence-based dependency triage because false positives waste remediation capacity and hide the findings that can actually affect production systems.
Context
Software composition analysis is meant to answer a simple question: which third-party components expose the application to real risk? In practice, many scanners answer only part of that question by flagging vulnerable packages without proving whether the flaw can actually be triggered in the deployed service.
That gap matters because exploitability depends on runtime conditions, call paths and control over inputs, not just on the presence of a vulnerable version. In an environment where open-source software is embedded across build pipelines and production workloads, open source software risks become operational only when the package, the code path and the deployment context line up.
For security engineering teams, the problem is not that dependency data is unavailable. The problem is that the data often lacks enough context to separate theoretical exposure from exploitable exposure, which makes prioritisation unreliable.
Key questions
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. A vulnerability can be severe on paper, but if it is not reachable or has no evidence of exploitation, it usually deserves less immediate attention than a reachable, actively exploited issue.
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. A critical issue in an unused library is usually lower risk than a lower-severity flaw in a package that processes untrusted input, sits on an internet-facing service, or runs with elevated privileges. Reachability analysis and asset criticality should guide patch order.
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. Stronger tools combine dependency graphs, symbol or function-level analysis, and package lock data to show whether the flaw can actually be triggered in that application context.
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.
Technical breakdown
Why reachability is necessary but not sufficient
Reachability asks whether application code can call into a vulnerable library path. That is a useful filter, but it does not prove an attacker can influence the data, state or configuration that makes the flaw dangerous. A decompression bug, for example, may be reachable from a request path while still being unreachable to an attacker who cannot control the server, payload or trigger condition. In SCA, this distinction matters because reachability tells you where to look, not whether exploitation is possible.
Practical implication: Treat reachability as an investigation step, not a remediation decision.
How exploitability depends on data flow and runtime context
Exploitability is a question about conditions, not just code presence. A flaw becomes real only when the vulnerable code is exercised in a way the attacker can shape, and when any feature flags, configuration settings or deployment boundaries fail to block that path. To decide that, the tool has to connect source, dependency, build artefact and runtime location. Without that chain, a scanner cannot tell whether the vulnerability is dormant, isolated or actually reachable by an external actor.
Practical implication: Bind vulnerability triage to the configuration and runtime path that would have to be abused.
Why evidence-backed triage reduces false positives
Evidence-backed triage gives defenders a defensible reason to close findings that cannot be exploited, rather than forcing every alert into the same patch queue. The operational advantage is not only speed; it is trust in the queue itself. When engineers can see the call path, the build evidence and the runtime constraints, they can focus on vulnerabilities that change actual risk. That is especially important in fast-moving delivery environments where shallow findings quickly become ignored noise.
Practical implication: Require proof of exploitability before escalating dependency findings into engineering work.
NHI Mgmt Group analysis
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.
Reachability without environmental context creates a noisy control surface. A package can be present, imported and even callable without being exploitable in production. The article's billing-service example shows why a scanner must understand request construction, configuration sources and deployed service boundaries. When teams do not separate those conditions, they spend remediation effort on code paths that no attacker can reach, while the exploitable cases stay buried in the backlog.
Runtime dependency context: this is the control gap where code, build and deployment evidence have to meet. Software teams need a single decision point that ties the manifest, the resolved version, the call chain and the environment together. That is the only way to tell whether a dependency issue is theoretical, dormant or active in the workload. Practitioners should expect SCA to move from static vulnerability surfacing toward proof-based prioritisation.
AI-assisted investigation is most valuable when it replaces brittle rules with traceable reasoning. The article frames the benefit as investigation depth, not magical detection. That matters because the hard part of dependency security is often stitching together evidence across repositories, builds and runtime. Where this intersection touches identity and access, the same principle applies to service accounts and workload privileges: the control question is whether the dependency can be reached through an authorised execution path, not whether it merely exists.
What this signals
Exploitability-based triage: dependency governance is moving toward decisions that require proof of real attackability before engineering effort is spent. Security teams should expect scanners, pipelines and review workflows to converge on the same question: can an attacker actually reach the vulnerable behaviour in this runtime?
Programmes that still rank dependency findings by version severity alone will keep generating alert fatigue. The practical shift is to align SCA with build evidence, deployment context and application control paths so remediation capacity follows exposure rather than noise.
For practitioners
- 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.
- Prioritise production exposure over theoretical vulnerability counts Rank remediation by whether the vulnerable component sits in a customer-facing flow, a trusted internal service or a non-production environment with no real traffic.
Key takeaways
- Dependency scanners are most useful when they distinguish theoretical exposure from flaws that can actually be triggered in the deployed application.
- The strongest evidence in this model comes from tracing the vulnerable package through code, build and runtime context before assigning severity.
- Security teams should treat exploitability as the remediation threshold, because version-based alerting alone creates noise and hides the issues that matter.
Related NHI Mgmt Group resources: Top 10 Open Source Software Risks · Open Source Security Guide · OWASP Top 10 A03 Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The article's exploitability logic depends on deployment and configuration state determining whether a flaw can be triggered. |
| Recommendation — Verify runtime configuration prevents vulnerable dependency paths from being triggered in production. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | SCA triage is a vulnerability-management workflow that must separate exploitable from non-exploitable findings. |
| Recommendation — Tune vulnerability management to prioritise exploitable dependency findings over raw alert volume. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset Vulnerability Identification | The article centres on identifying which dependency vulnerabilities are actually relevant to the environment. |
| Recommendation — Map dependency findings to environment-specific risk rather than treating every vulnerability as equal. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The exploitability question is whether an attacker can reach and trigger vulnerable code, a classic precondition for adversary action. |
| Recommendation — Use ATT&CK to connect reachable dependency flaws to realistic attacker pathways and test preconditions. | ||
Key terms
- Exploitability: Exploitability is the likelihood that a weakness can be turned into actual harm. In cybersecurity, it measures how readily an attacker can abuse a vulnerability, misconfiguration, exposed secret, or weak control, considering access required, available tools, and the value of the target asset or identity.
- Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.
- Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
- Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on November 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org