Because the risk depends on what the system is doing now, not only on what the code or configuration looked like earlier. Static tools may miss behaviour that only appears in execution, while manual investigations are too slow to preserve a containment window.
Why runtime-sensitive attacks are harder to catch than static issues
Runtime-sensitive attacks are dangerous because the exploit condition only exists while the system is executing, interacting, or changing state. A static scan can confirm code shape, dependency versions, or a configuration snapshot, but it cannot reliably tell you how the system behaves under live inputs, timing, concurrency, or chained requests.
That gap matters when the attack path depends on event ordering, transient privileges, deserialisation at execution time, or a payload that becomes harmful only after a particular API call, message, or runtime branch. In those cases, the weakness is not just “present in the build”, it is “activated in the moment”.
NIST SP 800-190 Container Security is a useful reference point here because it treats runtime risk as distinct from image-time risk, including the orchestrator, the running container, and the enforcement boundary between them.
Why manual investigations lose the containment window
Manual investigation is often too slow for runtime-sensitive compromise because the evidence can evaporate when the process restarts, the session expires, the attacker rotates tooling, or the system auto-recovers. By the time an analyst has reconstructed context from logs and host artefacts, the live condition that exposed the issue may already be gone.
This is why time sensitivity is part of the security problem, not just an operational inconvenience. If the attacker can trigger, observe, and withdraw behaviour faster than the investigation cycle, the organisation is left with partial evidence and little chance to reproduce the exact state that mattered.
Static and manual approaches also miss “only under load” failures, which can be exploitable precisely because they are intermittent. A condition that appears only under concurrency, scale, or specific sequencing can evade both code review and spot-check investigation unless the detection method observes the system while it is active.
What practitioners should look for instead
Runtime-sensitive attacks need controls that observe execution, not just artefacts. That means prioritising telemetry from the running service, the host, the container platform, and the network path that carries the suspicious action. It also means preserving enough context to correlate what happened before, during, and immediately after the trigger.
MITRE ATT&CK Enterprise Matrix helps structure that thinking by mapping attack behaviour to concrete techniques such as execution, credential access, and lateral movement, which are usually more visible in runtime telemetry than in a static scan.
NIST SP 800-53 Rev 5 Security and Privacy Controls is also relevant because the answer depends on controls for logging, auditability, configuration management, and system integrity, all of which help expose behaviour that static analysis cannot confirm on its own.
Risk and Threat Considerations
Runtime-sensitive attacks create a narrow detection window: the system may be compromised only long enough for the malicious action to complete, then return to a normal-looking state. That makes them attractive for intrusions that depend on transient execution, stealth, or rapid abuse of a live session.
Failure mechanism: The attacker exploits a behaviour that appears only when the system is running, so scans and pre-execution reviews never see the triggered condition, and manual triage cannot move fast enough to catch it in situ.
Impact: Defenders lose the best evidence, the best reproduction path, and often the best chance to contain the abuse before data access, lateral movement, or persistence is established.
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 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 | AU-2 — Event Logging | Runtime-sensitive attacks require live activity evidence to reconstruct the trigger and sequence. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Manual investigations depend on timely review of runtime evidence before it disappears. | |
| SI-4 — System Monitoring | Behaviour that appears only at runtime needs monitoring of the active system, not just code or config. | |
| Recommendation — Enable event logging for live execution, request, and platform activity that static scans cannot see. Review audit data quickly enough to preserve the containment window and correlate execution-time events. Monitor active processes and service behaviour to detect conditions static analysis will miss. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored | Live network and service monitoring is needed to spot runtime-dependent abuse as it occurs. |
| Recommendation — Monitor network and service activity continuously to catch runtime-only attack behaviour. | ||
Practitioner Guidance
What to prioritise: Treat runtime observability as a primary control, not an afterthought. If the suspected issue depends on execution state, concurrency, or live traffic, use event logs, process telemetry, request traces, and platform-level alerts before relying on static findings.
What to verify: Confirm that you can reconstruct the trigger sequence, the affected process state, and the exact time window in which the behaviour occurred. If you cannot, your investigation method is probably too slow or too shallow for this class of attack.
Decision rule: If the suspected weakness disappears when the system stops, assume the investigation is racing the attacker. Escalate to live containment, evidence capture, and rapid correlation of runtime signals rather than waiting for a full manual root-cause review.
Practitioner takeaway: The key judgment is to investigate behaviour while it is happening, because runtime-sensitive attacks are won or lost in the small gap between trigger and disappearance.