Executed Dependency

A third-party or open-source component that is not just present in a build, but actually loaded and called in production. This distinction matters because only executed dependencies represent live exposure that attackers can often reach.

Expanded Definition

An executed dependency is a component that is not merely declared in a manifest or bundled in a repository, but actually loaded, invoked, or run in production. That execution boundary matters because live code can interact with secrets, network services, memory, and identity tokens in ways dormant dependencies cannot. In NHI and application governance, the term helps separate theoretical supply chain exposure from reachable runtime exposure.

Definitions vary across vendors when they extend the term to transitive packages, plugins, or dynamically fetched modules, so the practical test is whether the code path is active in the deployed environment. This is why runtime evidence, telemetry, and software bill of materials records should be reconciled with production execution data. For a standards-oriented lens on risk treatment and asset visibility, see the NIST Cybersecurity Framework 2.0 and NIST’s broader guidance on asset management and monitoring.

The most common misapplication is treating every listed dependency as equally exposed, which occurs when teams conflate build-time presence with code that is actually reachable in production.

Examples and Use Cases

Implementing executed-dependency analysis rigorously often introduces runtime visibility overhead, requiring organisations to weigh better exposure accuracy against added instrumentation and review effort.

• A CI pipeline flags a package in the lockfile, but only the packages actually imported by the service are counted as executed dependencies during risk triage.
• A container image includes a plugin library, yet production telemetry shows the plugin never loads, so it is tracked as present but not executed.
• A third-party SDK is called on every authentication flow, making it an executed dependency that can influence token handling and secret access.
• A dynamically downloaded module is fetched after startup and runs only under a feature flag, so security teams validate both the flag state and the live invocation path.
• The distinction becomes critical after supply chain incidents like the LiteLLM PyPI package breach, where runtime behavior determines whether exposed code can actually reach production secrets.

For teams formalising dependency controls, software composition analysis should be paired with runtime validation and change detection, not used as a static inventory alone.

Why It Matters in NHI Security

Executed dependencies matter because they define the practical blast radius for secrets, service accounts, API keys, and tokens at runtime. A dormant package may be irrelevant, but an executed one can read environment variables, call identity endpoints, and forward credentials to external services. That makes exposure assessment a live governance problem, not just a build hygiene problem. The NHI Mgmt Group reports that 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, which means an executed dependency can become a direct path to credential leakage when runtime access is too broad.

This is also why dependency governance should align with least privilege and monitoring expectations in the NIST Cybersecurity Framework 2.0. If a runtime component is executed, it must be treated as part of the identity attack surface, especially when it can touch secrets or authenticate outbound requests. Organisations typically encounter the consequence only after a package is exploited in production, at which point executed-dependency analysis becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When does a dependency compromise become an identity incident?
• How should teams slow down malicious dependency updates without breaking delivery?
• What is the difference between automating dependency updates and granting them blind trust?
• Should organisations allow pull_request_target for automated dependency workflows?