The clearest sign is execution from a file that did not exist in the original image or was created after the instance started. That usually shows up as an unfamiliar binary, script, or downloaded payload appearing in a workload that should not change. Security teams should treat that as suspicious even before other alerts arrive, because it often precedes privilege escalation or lateral movement.
Runtime tampering usually leaves behavioural fingerprints, not just filesystem changes
An immutable container or VM is designed so the base image stays fixed, but runtime tampering can still occur through injected processes, altered memory state, mounted volumes, or abused management paths. The practical question is not whether the image hash still matches, but whether the running instance is doing things the image never authorised. That makes process lineage, command lines, child processes, unexpected network destinations, and new persistence artefacts more valuable than a simple image comparison. Security teams often miss this distinction when they assume immutability alone equals integrity. In practice, a workload can remain “immutable” at rest while still being manipulated in memory or through ephemeral runtime access paths.
For control context, teams often map this problem to NIST SP 800-53 Rev 5 Security and Privacy Controls because the detection problem spans integrity monitoring, auditability, and access control rather than image hardening alone. In practice, many security teams discover runtime compromise only after a later detection path sees suspicious network or privilege activity, not through any intended immutability check.
How runtime compromise shows up inside a supposedly fixed image
The first place to look is the delta between the original deployment intent and the observed runtime state. If a container or VM was launched from a known image, then any executable activity that cannot be explained by that image, its declared entrypoint, or its normal operational tooling is a strong signal. That includes binaries dropped into writable paths, scripts pulled from the network, memory-resident payloads, or scheduled tasks and services created after startup. In containers, this may appear through shell access, writable overlay layers, mounted secrets, or a process started by an unexpected parent. In VMs, the same pattern can emerge through remote administration tools, injected services, kernel-level tampering, or modified startup tasks.
- Unrecognised processes running from temporary, writable, or newly created locations.
- Unexpected child processes, especially shells spawned from application runtimes.
- Outbound connections to unusual hosts, ports, or domains for that workload.
- New autoruns, services, cron entries, scheduled tasks, or persistence files.
- Changes to logs, audit settings, or security tooling that reduce visibility.
Runtime integrity also depends on how much of the environment is truly ephemeral. A container that mounts host paths, persists writable volumes, or runs with elevated privileges can be tampered with even if the base image is unchanged. Likewise, a VM with weak administrative isolation can be altered through valid management interfaces rather than direct malware installation. For that reason, teams should correlate process telemetry, network telemetry, and host integrity signals before concluding the instance is clean. The strongest evidence is not a single alert but a chain of events that does not fit the approved build and execution pattern. This guidance breaks down when telemetry is sparse, when the workload is intentionally self-modifying, or when operators cannot distinguish sanctioned maintenance activity from unauthorised runtime change.
Normal exceptions can look suspicious, but the trust boundary still matters
Tighter runtime control often increases operational overhead, requiring organisations to balance detection certainty against application flexibility. Some workloads legitimately generate files, unpack dependencies, or launch helper processes at runtime, so the key issue is whether those behaviours are expected, documented, and tightly bounded. If the answer is unclear, the safer assumption is that the environment has drifted from the trust model that made immutability meaningful in the first place.
Guidance versus consensus: there is broad agreement that image immutability does not eliminate runtime compromise, but teams still disagree on how much self-modification is acceptable in containers versus VMs. The practical threshold is whether the behaviour is reproducible, attributable to approved software, and visible to monitoring. A container or VM that changes in ways the operator cannot explain is already outside the intended trust boundary, even if the original image remains intact.
When a workload relies on runtime downloads, plugins, or hot patching, the detection model must shift from “no changes should happen” to “only approved changes should happen, and they must be observable.” That is a governance choice as much as a technical one, because it determines whether the environment is truly immutable or merely redeployable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 8 — Audit Log Management | Runtime tampering is often exposed through audit and process evidence. |
| 10 — Malware Defenses | Dropped payloads and injected executables are core tampering indicators. | |
| 6 — Access Control Management | Runtime compromise often depends on abused administrative or shell access. | |
| Recommendation — Centralise and protect logs so unexpected runtime actions remain detectable. Block or detect untrusted executables that appear inside the workload at runtime. Restrict interactive and privileged access paths that can alter live instances. | ||
| MITRE ATT&CK | T1055 — Process Injection | Injected code can change runtime behaviour without altering the original image. |
| T1053 — Scheduled Task/Job | Tampered systems often persist through newly created jobs or tasks. | |
| Recommendation — Correlate memory and process telemetry to detect injected execution in live workloads. Hunt for unexpected scheduled execution that was not part of the baseline image. | ||
| NIST CSF 2.0 | DE.CM — Security Continuous Monitoring | Runtime tampering is primarily a continuous monitoring problem. |
| Recommendation — Continuously monitor runtime behaviour for deviations from the approved workload state. | ||
Practitioner Guidance
What to prioritise: Treat unexplained process creation, unexpected network egress, and new persistence artefacts as higher-value indicators than file integrity alone. Those signals tell you whether the workload is behaving outside its approved execution model.
What to verify: Confirm the declared image, entrypoint, runtime flags, mounted volumes, and administrative access path before trusting the instance state. If any of those elements can change the running behaviour, the workload is not being assessed as a closed system.
What good looks like: The running state matches the approved build, the approved process tree, and the approved network profile, with any runtime changes either absent or explicitly documented and monitored.
Practitioner takeaway: For immutable workloads, the decisive question is not “did the image change?” but “did the live instance start doing something the approved build never allowed?”
Related resources from NHI Mgmt Group
- What are the signs that runtime security is not working well in container platforms?
- What is the difference between shift left and runtime enforcement for container security?
- What is the difference between static image security and runtime container security?
- What breaks when a container runtime like runC mishandles mount paths?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
