Code-to-runtime discovery is the ability to connect what exists in source code with what is actually deployed and operating in runtime environments. This gives security teams a more complete picture of applications, dependencies, sensitive data, and exposed components, which improves visibility, scoping, and remediation decisions.
Expanded Definition
Code-to-runtime discovery connects what is written in source code with what is actually deployed in production, so teams can trace services, secrets, dependencies, and exposed interfaces across the full application lifecycle. In NHI security, that matters because the same service account, API key, certificate, or token may appear in code repositories, CI/CD pipelines, container images, and runtime workloads, but only the runtime view reveals what is currently active. The term is still evolving across vendors: some tools emphasize code scanning, while others focus on asset inventory or runtime posture, so there is no single standard definition yet. The most useful interpretation is operational rather than theoretical, aligning findings to control decisions such as exposure, privilege, and rotation. NIST Cybersecurity Framework 2.0 frames this kind of visibility as part of stronger governance and risk management, while NIST Cybersecurity Framework 2.0 provides the broader control context for discovery and response.
The most common misapplication is treating repository scanning as complete discovery, which occurs when teams assume committed code reflects what is actually running in production.
Examples and Use Cases
Implementing code-to-runtime discovery rigorously often introduces correlation overhead, requiring organisations to weigh better scoping and faster remediation against the cost of joining data from source control, build systems, and live infrastructure.
- Detecting an API key committed to a repository and confirming whether that key is still mounted in a running container or serverless function.
- Mapping application dependencies from source manifests to runtime libraries to identify exposed components that were never removed from production images.
- Comparing CI/CD secrets usage with deployed workloads to find credentials embedded in build pipelines but still reachable at runtime.
- Linking service account references in code to cloud identities in production, which supports the lifecycle discipline described in the NHI Lifecycle Management Guide.
- Reconciling discovered runtime exposure with the broader risk patterns documented in Top 10 NHI Issues and with asset visibility guidance from NIST Cybersecurity Framework 2.0.
In mature programs, the strongest use case is not simple inventory, but proving whether a secret or dependency that appears in code is still reachable in a live trust boundary.
Why It Matters in NHI Security
Code-to-runtime discovery is critical because NHI risk rarely stays where it was first introduced. A secret may begin in source code, pass through build artifacts, and end up in a running workload with broad access, making static reviews incomplete unless they are joined to runtime evidence. NHIMG research shows that 30.9% of organisations store long-term credentials directly in code, and that pattern becomes far more dangerous when teams cannot verify where those credentials are active. The same visibility gap also weakens incident response, because defenders cannot confidently determine blast radius, revocation scope, or whether a compromised token is still live. That is why this concept supports Zero Trust thinking in practice: every deployed identity and dependency must be continuously revalidated rather than assumed safe because it once passed a scan. The risk becomes operationally unavoidable after a leak, exposed workload, or suspected compromise forces teams to decide what to revoke first, what to preserve, and what remains exposed. For deeper context, the Ultimate Guide to NHIs — Key Challenges and Risks is especially relevant here.
Organisations typically encounter the true value of code-to-runtime discovery only after a breach investigation reveals that the compromised secret was still active in production.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) 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-01 | Discovery across code and runtime supports visibility into NHI inventory and exposure. |
| NIST CSF 2.0 | ID.AM-1 | Asset inventory control aligns with mapping code artifacts to deployed runtime components. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires continuous validation of what is actually running and accessible. |
| NIST AI RMF | Risk measurement depends on knowing where AI or software artifacts are deployed and used. | |
| OWASP Agentic AI Top 10 | Agentic systems need traceability from coded behavior to deployed execution paths. |
Maintain a reconciled inventory of code references and deployed services to support risk decisions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
