They need runtime evidence. A declared dependency range may look benign, but the only reliable signal is what was installed and executed in live environments. If runtime telemetry shows a compromised version or unexpected repository activity, the risk is real even if the manifest still appears unchanged.
Why This Matters for Security Teams
Dependency risk is often discussed as a supply chain problem, but for security teams the real question is simpler: did anything risky actually reach execution? A manifest, lockfile, or SBOM can declare a version range, yet that does not prove what was installed, loaded, or invoked in production. Runtime evidence matters because compromise usually shows up in telemetry first, not in documentation. This is why current guidance from the NIST Cybersecurity Framework 2.0 emphasizes continuous monitoring, and why NHI-focused analysis in Top 10 NHI Issues treats visibility gaps as a recurring control failure.
Security teams get tripped up when they equate declared dependency state with trusted runtime state. A package can appear pinned, approved, and scanned while a build cache, transitive update, or poisoned repository delivers something different into execution. That distinction matters even more for non-human identities and agentic workloads, where software components routinely authenticate, fetch, and chain other services without a human in the loop. In practice, many security teams encounter the compromise only after unusual repository activity or secret use has already occurred, rather than through intentional verification.
How It Works in Practice
The operational test is whether the dependency can be tied to runtime proof, not just source control declarations. Teams typically compare four signals: the declared range, the resolved artifact, the executed binary or package hash, and the telemetry showing where it ran. If those four do not align, the dependency risk should be treated as real, even if the manifest still looks clean.
That is where software supply chain controls and NHI governance overlap. The Ultimate Guide to NHIs — Key Challenges and Risks highlights why credentialed workloads are sensitive to invisible trust shifts, and the LiteLLM PyPI package breach shows how quickly package-level compromise can become an identity event when secrets or tokens are present.
- Use build-time attestations to capture what was resolved, then verify the same artifact hash appears in runtime telemetry.
- Correlate package manager logs, container admission data, and process execution records to confirm what actually executed.
- Flag unexpected repository calls, unsigned artifacts, or drift from approved digest pins as live risk indicators.
- For agents and automated workloads, tie dependency checks to workload identity so the executing service, not just the package name, is known.
Runtime-first detection becomes especially important when dependencies are pulled dynamically, cached across pipelines, or fetched by autonomous agents that may chain tools and services without predictable patterns. These controls tend to break down when ephemeral build environments, aggressive caching, or mirrored registries obscure the artifact that actually reached production.
Common Variations and Edge Cases
Tighter runtime verification often increases operational overhead, requiring organisations to balance stronger assurance against build latency and telemetry complexity. That tradeoff is real, and best practice is evolving rather than universally settled.
For example, a dependency may be declared as safe but still be risky if a subdependency changed in transit, if a private registry was tampered with, or if a CI runner reused a stale cache. Conversely, a version that looks suspicious on paper may pose limited practical risk if runtime evidence shows it never executed in a sensitive path. The key is to avoid binary thinking: declared risk and realised risk are related, but not identical.
One useful way to separate the two is to ask whether the dependency affected an executable control plane, credential flow, or data movement path. If yes, treat it as a live security concern and not a theoretical hygiene issue. If the dependency is present only in documentation or a dormant branch, the risk is still worth tracking, but it has not yet become operational exposure. The State of Non-Human Identity Security is a reminder that visibility gaps are common, and runtime confirmation is often what closes them.
Where this guidance breaks down is highly distributed environments with incomplete telemetry, because missing execution data can make both benign and dangerous dependencies look the same.
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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Runtime proof is needed to confirm which NHI-related dependency actually executed. |
| NIST CSF 2.0 | DE.CM-01 | Continuous monitoring is central to distinguishing declared risk from live execution risk. |
| NIST AI RMF | GOVERN | AI governance must account for dynamic software and agent dependencies that change at runtime. |
Verify executed artifacts and dependency provenance before trusting declared NHI risk posture.
