A Code-to-Runtime Software Graph maps how source code becomes active software across build, deployment, and execution environments. It links code repositories, build artifacts, containers, services, identities, and runtime dependencies to show what is running, where it came from, and which non-human identities can influence it.
What the Code-to-Runtime Software Graph shows
A code-to-runtime software graph connects the lifecycle from source to execution, so teams can see which repositories, build artifacts, containers, services, identities, and dependencies are actually participating in a running system. It is useful because software risk rarely lives in code alone; it often appears in the handoffs between build, deployment, and runtime.
The graph is most valuable when it preserves provenance and dependency context together. That lets practitioners reason about what is deployed, what produced it, and which downstream components inherited trust from it, rather than treating each environment as a separate inventory.
Why code-to-runtime mapping matters for security
Security teams use this kind of mapping to reduce blind spots between development and production. A package may be approved in source control, but the security question changes once it is packaged into an image, promoted through a pipeline, or invoked by a service in production.
That shift matters because trust is cumulative. If the graph is incomplete, an organisation may miss a vulnerable build artifact, an unexpected dependency, or a runtime relationship that gives a component broader reach than intended.
How the graph supports investigation and governance
When an issue appears in production, the graph helps answer practical questions quickly: where the component came from, which deployment path introduced it, and what else depends on it. That shortens the path from alert to scope determination.
It also supports governance by making ownership and accountability more legible. If a service is running from an image built in one pipeline but operated in another environment, the graph can show where control boundaries blur and where review should occur.
For teams building out software supply-chain visibility, NIST SP 800-190 Container Security is a useful reference point for image, registry, orchestrator, and runtime concerns.
Runtime identity, dependencies, and control boundaries
The graph becomes more precise when it includes the identities and dependencies that influence runtime behaviour. That can include service-to-service credentials, automation accounts, deployment principals, secret stores, and external services that a workload calls at execution time.
This is where the model stops being a static architecture diagram and starts reflecting operational reality. If a service can only function because a non-human identity can reach a registry, fetch a secret, or assume a runtime role, that relationship is part of the security story and should be visible in the graph.
More broadly, the graph gives defenders a way to separate intended connections from accidental ones. That distinction is essential when analysing overexposed services, excessive trust, or dependencies that should not exist in production.
Risk and Threat Considerations
A code-to-runtime software graph is only as reliable as the data feeding it. If build, deployment, registry, or runtime telemetry is missing, the graph can create a false sense of completeness and leave hidden software paths, untracked identities, or unreviewed dependencies in place.
Failure mechanism: Attackers and misconfigurations both benefit when source, artifact, and runtime state are not joined into one view, because defenders may fail to notice tampered artifacts, shadow deployments, or unexpected runtime relationships.
Impact: The result can be weaker incident scoping, missed dependency exposure, delayed containment, and a higher chance that compromised or unapproved components remain active in production.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, SLSA, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Tracks what software components and runtime assets are present. |
| SI-7 — Software, Firmware, and Information Integrity | Protects trust in build outputs and runtime software integrity. | |
| Recommendation — Maintain a complete inventory that ties running components back to their source and deployment path. Verify artifact integrity before promotion and execution. | ||
| SLSA | Supply-chain integrity | Covers provenance and tamper resistance across build and release stages. |
| Recommendation — Adopt provenance controls that preserve traceability from source to deployed artifact. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Requires knowing what software exists and where it is running. |
| Recommendation — Keep software asset inventories aligned to observed runtime deployments. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems within the organization are inventoried | Supports mapping the assets and systems participating in runtime execution. |
| Recommendation — Inventory the systems and software that appear in the code-to-runtime path. | ||
Practitioner Guidance
Why practitioners should care: Treat the graph as an operational control, not just documentation. If it cannot answer what is running, where it came from, and which runtime relationships it depends on, it is not yet doing its security job.
What to watch for: Focus on gaps between declared and observed state, especially when a service is deployed by one pipeline, runs under a separate identity, or depends on artifacts that are not visible in the same inventory.
Practitioner takeaway: The strongest graphs connect provenance, deployment, and runtime into one accountable view, because that is where software trust is either preserved or lost.
Related resources from NHI Mgmt Group
- What is the difference between static software inventories and real-time code-to-runtime inventory?
- Who should be accountable for maintaining software inventory across code and runtime?
- What is the difference between securing software at code time and securing it at runtime?
- How should AppSec and cloud security teams align code-level findings with runtime risk in modern software delivery?