What is the difference between loaded libraries and executed libraries in runtime security analysis?

Why Loaded vs Executed Libraries Matters in Runtime Security

Loaded libraries and executed libraries answer two different security questions. A library can be present in memory, mapped by the runtime, or shipped with the workload without ever being on a live execution path. runtime security analysis becomes much more precise when teams separate “available to the process” from “actually reachable during execution,” because exploitability depends on code paths, not inventory alone. That distinction is especially useful when triaging alerts, reducing vulnerability noise, and deciding what deserves immediate remediation.

For containerised applications, this distinction aligns with runtime reality, where packaged components and active behaviour often diverge. A vulnerability in a loaded-but-unused library may still matter later, but it does not prove a present attack path. By contrast, executed libraries show that the vulnerable code is reachable in the current workload state. NIST’s container security guidance is a useful anchor here because it treats runtime behaviour, not just static image contents, as a meaningful security concern.

In practice, many teams only discover this difference after a scanner floods them with findings that do not match what the application actually does in production.

How It Works in Practice

Runtime tools identify libraries at different stages of application behaviour. A loaded library is one that the process has mapped or prepared for use, often because the runtime, framework, or dependency loader initialised it. An executed library is one whose functions have actually been called during the observed window. Security analysis should treat that distinction as a reachability test, not a semantic preference.

This matters because exploitability is tied to whether attacker-controlled input can reach vulnerable code. If a library is loaded but never invoked, the exposed surface is narrower than a scanner might suggest. If the library executes under normal traffic, then the vulnerability becomes relevant to the live workload and may justify prioritisation, compensating controls, or immediate patching.

• Loaded only: present in memory, but not proven reachable in the observed runtime path.
• Executed: function calls observed, so the vulnerable code path is materially active.
• Security decision: focus remediation on executed code first, then validate whether dormant loaded code can become reachable through different inputs or modes.

This distinction is strongest when tied to telemetry from real application sessions, request traces, or sandboxed runtime observation rather than static package lists alone. It is also useful when different frameworks or plugins share the same process but are not exercised uniformly. These controls tend to break down when execution is highly conditional, such as feature flags, background jobs, or rarely used error handlers, because a library can remain dormant until an unusual path is triggered.

Common Variations and Edge Cases

Tighter runtime filtering often reduces alert volume, but it also increases the chance of missing low-frequency paths that are real under rare conditions. Teams need to balance noise reduction against the possibility that a loaded library becomes executable under a different tenant, input pattern, or configuration state.

One common edge case is lazy loading, where code is only fetched or initialised after a trigger. Another is plugin-based software, where a library may be loaded by default but only executed when a feature is enabled. A third is background processing, where code is inactive during web requests but runs in scheduled tasks or asynchronous workers. In those environments, “not executed yet” should be treated as “not proven reachable yet,” not “safe.”

Loaded versus executed is also a useful way to frame exception handling. Some vulnerabilities are only reachable in failure conditions, so the absence of observed execution during normal traffic is not a complete control. The right judgement is to combine runtime evidence with architectural context, then separate immediate exploitability from latent exposure.

Practitioner Guidance

What to prioritise: Triage executed libraries first, especially when the vulnerable function is tied to live request handling, task processing, or externally reachable inputs. Loaded-only libraries should still be tracked, but they belong behind confirmed reachable code paths unless configuration or feature activation can make them active.

What to verify: Confirm the observation window and workload mode before trusting a runtime result. A library that never executed during a quiet period may still be reachable under peak traffic, alternate tenants, scheduled jobs, or error conditions. The best evidence combines runtime telemetry with application context, not scanner output alone.

Practitioner takeaway: The operational value of this distinction is prioritisation, not absolution, because “loaded” describes presence while “executed” demonstrates a live path that can actually carry risk.

Related resources from NHI Mgmt Group

• What is the difference between AI code analysis and runtime DAST for application security?
• How should security teams prioritize runtime vulnerabilities when only some loaded libraries are actually executed in production?
• What is the difference between shift left and runtime enforcement for container security?
• What is the difference between observability and enforceable runtime security?