An embedded dependency is a software component bundled inside an application, image, appliance, or runtime rather than installed and managed separately. These dependencies are easy to overlook during patching, which makes them a common source of hidden exposure in trust and identity infrastructure.
Expanded Definition
An embedded dependency is a component bundled inside an application, container image, appliance, firmware package, or runtime so it is consumed as part of the product rather than managed as a separate asset. In NHI and IAM environments, that distinction matters because the dependency often carries its own certificates, token handling, update cadence, and trust assumptions, yet it may be invisible to the teams responsible for security operations.
Definitions vary across vendors on whether an embedded dependency must be physically packaged with the host artifact or simply shipped in a way that hides it from normal asset management. In practice, the term usually covers libraries, agents, plugins, and runtime modules that are difficult to inventory, patch, or attest independently. That makes embedded dependencies especially relevant where identity infrastructure depends on supporting software to validate tokens, broker secrets, or connect to external policy engines. The NIST Cybersecurity Framework 2.0 helps frame the operational need to identify, protect, detect, respond, and recover around these hidden components.
The most common misapplication is treating an embedded dependency as part of the base application only, which occurs when patching and ownership stop at the visible product boundary.
Examples and Use Cases
Implementing embedded-dependency governance rigorously often introduces release and compatibility constraints, requiring organisations to weigh faster delivery against the cost of deeper inspection and more frequent rebuilds.
- A service mesh sidecar is bundled into a platform image, so the security team must track the sidecar version separately from the workload that uses it.
- An API gateway appliance includes a certificate validation library that remains unpatched because the vendor controls the firmware lifecycle.
- A secrets broker ships with a built-in connector for a cloud KMS, and the connector’s trust chain becomes part of the NHI attack surface.
- A CI/CD runner image contains an authentication helper that caches tokens, creating an embedded exposure if the image is reused without rebuild verification.
- An organisation discovers a vulnerable transitive component after an incident similar to the LiteLLM PyPI package breach, where dependency packaging created a hidden path to credential theft.
For implementation guidance, teams often pair software bill of materials practices with identity-focused controls from the NIST Cybersecurity Framework 2.0. NHIMG’s research on the Ultimate Guide to NHIs is useful when evaluating whether bundled components introduce hidden identity dependencies that normal asset registers miss.
Why It Matters in NHI Security
Embedded dependencies are dangerous in NHI security because they can silently inherit trust, permissions, and secret-handling responsibilities without appearing in the systems of record. That is where patch delays, unsigned updates, and unowned certificates become operational risks. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, and that lack of visibility often extends to the software components those accounts rely on. When a dependency is embedded, a compromised token library or identity agent can undermine the entire trust chain before defenders realise the vulnerable code even exists.
The governance problem is not just vulnerability management. It is also lifecycle control, because embedded components may be updated only when the parent application is rebuilt, recertified, or replaced. That creates long exposure windows, especially when secrets, certificates, and identity brokers are packaged into images or appliances. Organisations typically encounter the consequences only after an outage, breach, or emergency rebuild, at which point embedded dependency management becomes operationally unavoidable to address.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Embedded components hide NHI inventory and trust boundaries. |
| NIST CSF 2.0 | PR.IP-12 | Highlights maintenance and change control for system components. |
| NIST Zero Trust (SP 800-207) | Zero trust depends on continuously verifying hidden trusted components. |
Inventory bundled identity components and verify ownership, update paths, and trust boundaries.
