Package inventories show presence, not execution. A dependency can exist in a repository or build output without being active in production, while a loaded runtime component can be exploitable even when the broader application looks compliant. Teams need runtime telemetry to decide whether a vulnerability is truly reachable.
Why This Matters for Security Teams
Package inventories answer a narrow question: what was declared, built, or scanned. Framework vulnerability risk depends on something different, which is whether a vulnerable component is actually loaded, invoked, or reachable in production. That distinction matters because attackers do not need every listed package, only the one path that executes. Current guidance suggests pairing inventory data with runtime evidence, as reflected in the NIST Cybersecurity Framework 2.0 emphasis on asset and exposure management.
For NHI Management Group, the deeper lesson is that visibility without execution context creates false confidence. A dependency can sit dormant in a lockfile while a different code path, plugin, or transitive framework component becomes the real attack surface. This is why the operational view in Top 10 NHI Issues and the Ultimate Guide to NHIs — Key Challenges and Risks keeps returning to runtime truth, not just static lists.
In practice, many security teams encounter the real risk only after a scanner reports compliance and an incident review reveals the vulnerable code was executing all along.
How It Works in Practice
Operationally, the answer is to treat package inventories as a starting point, then enrich them with runtime telemetry, dependency reachability, and application context. A package list tells you what may be present. Runtime signals tell you whether a vulnerable function is reachable, whether the framework is loaded in the active process, and whether the affected path can be triggered by an external request or an internal job. That is the difference between theoretical exposure and exploitable exposure.
Security teams often combine three data sources:
- Build-time inventory from SBOMs, package managers, or container scans.
- Runtime evidence from process telemetry, eBPF, agent-based monitoring, or application tracing.
- Path analysis that maps a CVE to the actual call chain, configuration, and deployment tier.
This approach aligns with the broader lifecycle discipline described in the NHI Lifecycle Management Guide, where visibility is only useful when it supports action. It also fits the risk-based framing in Ultimate Guide to NHIs — Regulatory and Audit Perspectives, because audit evidence should show actual control of exposure, not merely declared presence.
In vulnerability triage, the practical test is simple: can the affected code execute in the current environment, with the current configuration, and with the current permissions? If the answer is yes, the risk is real even when the inventory looks clean. If the answer is no, remediation may be lower priority than the scanner suggests. These controls tend to break down in polyglot microservice estates with heavy transitive dependencies, because ownership, loading behavior, and runtime paths become difficult to map accurately.
Common Variations and Edge Cases
Tighter exposure analysis often increases operational overhead, requiring organisations to balance faster vulnerability reporting against the cost of deeper runtime validation. That tradeoff matters because not every environment can afford full tracing or agent deployment everywhere, especially in high-volume, short-lived container fleets or legacy systems with limited observability.
There is also no universal standard for this yet. Current guidance suggests treating reachability as a prioritisation input, not an absolute yes-or-no security verdict. Some teams will mark a package as “present but not reachable” when telemetry proves the vulnerable code path is disabled, while others will still track it as a latent risk because configuration drift can re-enable it later. The difference is governance maturity, not a contradiction.
Edge cases include shared libraries, plugin architectures, and dynamic imports. In those environments, a framework may appear unused in one deployment but become active through feature flags, tenant-specific configuration, or scheduled jobs. The same logic applies to build artifacts: a package removed from source control can still remain in a deployed image or cached layer if release hygiene is weak. For that reason, the LiteLLM PyPI package breach is a useful reminder that package presence alone does not tell the full operational story, and the Ultimate Guide to NHIs — Why NHI Security Matters Now reinforces why visibility without context leaves teams exposed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM | Asset inventory alone misses runtime exposure and active attack paths. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Visibility gaps are a core non-human identity and dependency risk pattern. |
| NIST AI RMF | Risk management must distinguish static presence from operational impact. |
Pair package lists with runtime telemetry to identify which vulnerable components are actually exposed.
