What should teams do when a vulnerable library exists but may not be executed in production?

Why This Matters for Security Teams

A vulnerable library is not automatically an exploitable finding if the runtime never loads it, calls it, or exposes it on a reachable code path. Security teams get into trouble when they treat package inventory as proof of risk, because static dependency scanners cannot distinguish dead code from active execution. That gap leads to noisy backlogs, diverted engineering time, and missed prioritisation of issues that actually affect production exposure. Current guidance from the NIST Cybersecurity Framework 2.0 favours risk-based decisions grounded in real operational context, not just presence in a manifest. NHIMG research reinforces that the same principle applies to identity and secret exposure, where Ultimate Guide to NHIs notes that 96% of organisations still store secrets outside proper managers, making visibility and runtime proof essential before escalation. In practice, many security teams discover a library is “critical” only after a scanner flags it, rather than through intentional runtime validation.

How It Works in Practice

Teams should confirm three things before treating the library as an active production risk: whether it is loaded into the deployed artifact, whether application logic actually invokes it, and whether any reachable input path can trigger the vulnerable function. Static analysis is useful for discovery, but runtime evidence should decide severity. That means combining SBOM or dependency scans with observable telemetry from container images, application logs, tracing, eBPF, or endpoint instrumentation where available.

• Check deployment artefacts to see whether the library is bundled, referenced, or deferred by optional code paths.
• Validate runtime call graphs or traces to determine whether the vulnerable method is executed in the live application path.
• Assess reachability through exposed endpoints, message queues, background jobs, or admin-only flows.
• Document compensating controls, such as feature flags, network segmentation, or disabled modules, if execution is impossible in production.

This aligns with a risk-based process rather than a purely inventory-driven one. The NIST Cybersecurity Framework 2.0 supports prioritisation based on business impact and exposure, while NHIMG’s Schneider Electric credentials breach illustrates why proven exposure matters more than theoretical presence when deciding what to fix first. Where teams can show the code is dormant, they should still track remediation, but at a lower urgency and with a clear rationale. These controls tend to break down in monolithic applications with opaque startup logic, because scanners cannot reliably prove whether libraries are activated behind reflection, plugins, or conditional imports.

Common Variations and Edge Cases

Tighter prioritisation often reduces wasted remediation, but it also increases the burden of proof, so teams must balance speed against confidence. In current guidance, there is no universal standard for proving non-execution in every stack, so the acceptable evidence threshold varies by environment and risk tolerance.

Edge cases matter. A library may be unused in the main request path but still reachable through a cron job, an asynchronous worker, a debug endpoint, or an internal admin tool. In those cases, the vulnerability is not theoretical just because the public API never calls it. Teams should also be careful with libraries loaded only in certain deployment tiers, because production and staging behavior often diverge. For identity-heavy platforms, NHIMG’s Ultimate Guide to NHIs is a useful reminder that hidden execution paths and poor visibility create the same practical problem seen in secrets management: you cannot secure what you cannot observe. The safest operating model is to require runtime proof for escalation, but keep a follow-up action if the vulnerable component could become reachable later through a feature release, plugin enablement, or configuration drift.

Related resources from NHI Mgmt Group

• How should security teams handle risky behaviour from non-human identities without breaking production?
• What should security teams audit before allowing shared agents into production?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?