Code-to-Runtime Software Inventory

Expanded Definition

Code-to-runtime software inventory is the operational record that traces software from source code through build, packaging, deployment, and live execution. In NHI and application security work, it helps teams see which libraries, services, containers, workloads, and dependencies actually exist, not just what is documented in repositories. That distinction matters because security decisions are only as reliable as the inventory behind them.

This concept overlaps with software bill of materials practices, configuration management, and runtime asset discovery, but it is broader than a static list. A useful inventory reflects change over time, links components to owning teams, and supports security actions such as patching, secret rotation, exposure review, and dependency risk triage. Guidance varies across vendors on how much runtime telemetry is required, so no single standard governs this yet. The most useful baseline is to tie the inventory to authoritative sources such as the NIST Cybersecurity Framework 2.0 and the application lifecycle, then reconcile it against what is actually deployed.

The most common misapplication is treating a build manifest as the full inventory, which occurs when teams ignore containers, injected dependencies, and ephemeral runtime services.

Examples and Use Cases

Implementing code-to-runtime inventory rigorously often introduces telemetry and governance overhead, requiring organisations to weigh better exposure awareness against the cost of continuous reconciliation.

• A platform team maps a microservice from Git commit to container image, then to the running pod, so security can verify whether a vulnerable library is still active in production.
• An NHI program identifies API keys embedded in code and confirms where those credentials are consumed at runtime, using the Ultimate Guide to NHIs as a reference for lifecycle and visibility controls.
• A cloud security team correlates deployment metadata with service accounts to determine whether a workload has drifted from its approved configuration.
• An engineering organisation uses the inventory to prioritise patching when a vulnerable dependency appears in a service that is externally reachable and has privileged runtime access.
• A security operations team compares build artefacts to live workloads after an incident, then isolates components that were never documented in the original release record.

These use cases align with runtime visibility expectations in the NIST Cybersecurity Framework 2.0, especially where asset visibility and ongoing monitoring are required.

Why It Matters in NHI Security

Code-to-runtime inventory is critical in NHI security because service accounts, workload identities, API keys, and certificates often become invisible once they leave source control. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, and only 5.7% have full visibility into their service accounts, according to the Ultimate Guide to NHIs. Those conditions make it difficult to know which identities are active, which dependencies they trust, and which runtime paths expose them.

A strong inventory supports Zero Trust Architecture, reduces shadow dependencies, and helps teams remove stale credentials before they become attack paths. It also strengthens governance around build pipelines, because the inventory reveals when a trusted code path no longer matches what is running in production. Without that bridge, security teams can miss privileged components that were introduced after code review but before deployment. The most relevant control logic is consistent with NIST Cybersecurity Framework 2.0 visibility and protection outcomes, even though implementation details vary by environment and tooling.

Organisations typically encounter the need for code-to-runtime inventory only after an exposed dependency, orphaned secret, or unexpected workload has already been found in production, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between static software inventories and real-time code-to-runtime inventory?
• What is the difference between code scanning and runtime identity monitoring?
• What is the difference between code review and access review in AI-generated software?
• Why do runtime security issues often survive static code review?