How do security teams decide whether to fix or defer a vulnerable dependency?

Teams should prioritise the dependency when the vulnerable code path is reachable from application logic, the exposed function handles untrusted input, or the affected package sits on a critical path. If the vulnerable function is never called, the short-term risk may be low, but teams should still track it for planned remediation and governance.

Why This Matters for Security Teams

Deciding whether to fix or defer a vulnerable dependency is a risk decision, not just a patching decision. A package can look severe on paper and still present limited immediate exposure if the affected code path is unreachable. The reverse is also true: a modest-looking issue can become high risk when it sits in a critical path, processes untrusted input, or is reused across multiple services. The NIST Cybersecurity Framework 2.0 is useful here because it pushes teams to connect vulnerability handling to risk governance, asset context, and response discipline rather than treating every alert identically.

Practitioners often get this wrong in two ways. Some overreact to scanner output and spend time on low-exposure findings while real attack paths remain open. Others defer too aggressively and assume that “not called today” means “safe enough,” which ignores build changes, feature flags, indirect imports, and future reuse. For teams managing software supply chain risk, the right question is whether the vulnerable dependency is reachable, exploitable in the current environment, and acceptable under the organisation’s risk tolerance.

In practice, many security teams encounter dependency risk only after exploitability has been demonstrated in production-like conditions, rather than through intentional reachability testing.

How It Works in Practice

Security teams usually make the fix-or-defer call by combining vulnerability intelligence, code context, and business impact. The first step is to confirm whether the vulnerable function is actually invoked by the application, whether it can be reached through a network path, and whether an attacker can influence the input that reaches it. That is a stronger test than package version alone, because transitive dependencies and optional modules often inflate the apparent blast radius.

From there, teams typically weigh four factors:

• Reachability: is the vulnerable code path executed in the deployed configuration?
• Exposure: does the affected function handle untrusted data or external requests?
• Criticality: does the dependency support authentication, payments, identity, or other high-value workflows?
• Compensating controls: are WAF rules, isolation boundaries, feature flags, or privilege limits reducing practical risk?

Good governance also matters. Current guidance from the broader software security community aligns with tracking deferred items, assigning owners, and setting review dates instead of closing them as false positives. The NIST Secure Software Development Framework is a helpful reference point for tying dependency management to secure build, verification, and remediation practices. Where dependency risk touches identity or secrets, the same logic applies to packages that influence authentication flows, token handling, or non-human identity workflows.

For mature teams, the decision is often recorded in a vulnerability exception process: document exploitability, identify the affected service, note business impact, and define the remediation trigger. That makes deferral a controlled risk acceptance rather than an informal delay. The MITRE CWE catalogue can also help teams map a dependency issue to the underlying weakness class, which improves triage consistency across products and repositories.

These controls tend to break down when dependency ownership is unclear in large monorepos, because no single team can verify reachability, deployment scope, or remediation timing with confidence.

Common Variations and Edge Cases

Tighter dependency control often increases delivery overhead, requiring organisations to balance rapid shipping against the cost of deeper validation. That tradeoff becomes more visible in fast-moving environments, especially when teams rely on shared libraries, ephemeral branches, or automated dependency updates.

There is no universal standard for this yet, but current guidance suggests treating some cases as higher priority even when exploitability is not fully proven. Examples include authentication libraries, serialization code, cryptographic components, and packages embedded in internet-facing services. In those environments, the absence of a known exploit does not necessarily justify deferral, because the impact of a successful attack is disproportionately high.

Edge cases also matter. A vulnerability may be technically present but practically reduced by compile-time flags, dead code, or deployment profiles that exclude the affected module. Conversely, a low-severity flaw can become urgent if the package is shared across many applications or sits inside an AI pipeline, agentic workflow, or secrets-handling service. Where that identity or automation intersection exists, security teams should verify whether the dependency influences credentials, tokens, or execution authority before accepting delay. When teams are unsure, the safest approach is usually time-bound deferral with explicit compensating controls, not indefinite postponement.

Related resources from NHI Mgmt Group

• How do security teams decide whether a vulnerable platform is exposed enough to patch immediately?
• How should security teams decide whether JIT access is safe for non-human identities?
• How should security teams decide whether Light IGA is enough?
• How should security teams decide whether to revoke or rotate a leaked secret?