Runtime protection closes the container patching gap in production

At a glance

What this is: Aqua’s analysis says production vulnerability risk is outpacing patch cycles, and runtime compensating controls are the stopgap when patching cannot happen immediately.

Why it matters: For IAM and security teams, this matters because the same governance problem shows up in NHI and autonomous estates: visibility without runtime control does not reduce exposure.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Aqua Security's analysis of runtime protection for unpatched container workloads

Context

Production vulnerability management is a governance problem before it is a tooling problem. Teams can identify exposure faster than they can safely patch, and that mismatch leaves running workloads exposed even when scanning and prioritisation are working as designed. In container environments, the primary keyword here is runtime protection, because the control boundary shifts after deployment.

Shift left still matters, but it ends at the image. Once a workload is live, the organisation needs a control that can limit exploitation inside the running container without forcing emergency rebuilds or downtime. For practitioners building a broader identity and security programme, this is the same pattern seen in NHI governance: discovery alone does not equal control. See the NHI Lifecycle Management Guide for the lifecycle side of that problem.

Key questions

Q: How should security teams handle critical vulnerabilities when patching cannot happen right away?

A: Teams should treat the vulnerability as a live production exposure and decide whether a runtime compensating control can contain exploitation until patching is possible. If no runtime control exists, the workload needs an explicit exception with an owner, an expiry, and a clear remediation path. Visibility alone is not adequate when exploitation can begin before the next maintenance window.

Q: Why do container vulnerabilities remain dangerous after a scan has identified them?

A: Because scanning tells you what is present, not what can still be exploited in a running workload. Once the container is live, the attacker targets execution paths, process behaviour, and accessible resources. If the organisation cannot patch immediately, the risk persists until a runtime control limits the exploit path.

Q: What do security teams get wrong about shift left in vulnerability management?

A: They often assume that better pre-deployment scanning is enough to manage production risk. Shift left improves what gets shipped, but it does not control what happens after deployment. If a workload is already running, the organisation still needs a way to stop active exploitation without forcing immediate downtime.

Q: Who should own the decision to enforce runtime controls on live workloads?

A: Ownership should sit with the security and platform teams that manage production risk, not only with application developers. The decision is operational because it affects uptime, maintenance windows, and containment. The control needs a named owner, a review cadence, and an exception process for workloads that cannot yet be patched.

Technical breakdown

Why pre-deployment scanning stops at the runtime boundary

Pre-deployment scanning finds vulnerable packages, libraries, and container layers before release, but it cannot change the behaviour of a live process. Once a container is running, the exploit path depends on what the workload can access at execution time, not what the image looked like earlier in the pipeline. That is why shift left reduces introduction of risk but does not contain active exploitation. Runtime protection sits at a different control plane: it observes process activity, file access, network use, and system calls in the live workload, then blocks only the behaviours tied to a known weakness.

Practical implication: treat scan results as input to runtime containment decisions, not as proof that production exposure is acceptable.

Compensating controls for known vulnerabilities in containers

A compensating control does not remove the flaw. It narrows the exploit path enough to keep the workload operating while patching is deferred. In container security, that usually means enforcing policy at the process or kernel boundary so the vulnerable component cannot be reached in the way the exploit requires. The value is not theoretical coverage. It is the ability to keep a service live, preserve maintenance windows, and avoid turning every critical CVE into an emergency rebuild. This only works when the policy is specific to the vulnerable behaviour rather than a generic hardening rule.

Practical implication: prioritise exploit-specific runtime controls for high-severity CVEs that cannot be patched immediately.

Audit to enforce transitions change how operations teams absorb risk

Audit mode creates an observation period before enforcement. That matters because security teams need evidence that the runtime policy matches the real workload before they block behaviour in production. Scheduler-driven transitions reduce manual drift, but they also create a governance requirement: the organisation must define when evidence is sufficient to move from visibility to enforcement. This is not just a technical feature. It is an operational model for managing vulnerabilities when downtime, regression risk, and patch availability do not line up with attacker timelines.

Practical implication: build a documented audit-to-enforce workflow with explicit acceptance criteria for moving protections into production.

Threat narrative

Attacker objective: The attacker wants to exploit a live production workload before defenders can patch, rebuild, or safely take it offline.

1. entry: attackers target a container workload with a known vulnerability before the patch or rebuild is available.
2. escalation: exploit attempts reach the vulnerable component directly inside the running container, bypassing pre-deployment controls.
3. impact: the workload is compromised or disrupted unless a runtime compensating control blocks the exploit path in time.

Breaches seen in the wild

• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime protection is now a governance control, not a niche container feature. The article shows that vulnerability management has crossed from hygiene into operational governance because discovery, triage, and patching no longer happen inside the attacker’s timeline. Once exploitation speed outpaces change windows, the control question is whether the workload can be constrained while it still runs. Practitioners should treat runtime containment as part of the decision architecture, not as an optional hardening layer.

Patch-first thinking leaves a structural gap in production workloads. The basic assumption behind traditional vulnerability management is that remediation can follow identification quickly enough to matter. That assumption fails when a live workload cannot be patched without downtime or when exploit activity begins before the ticket is even assigned. The implication is that production risk must be governed as a separate state, not as a delayed extension of build-time security.

Compensating controls matter most where downtime is operationally expensive. The article’s strongest point is not that scanning is useless, but that scanning cannot carry the whole burden once a service is live. Runtime enforcement, especially for known exploits, changes the blast radius of a missed patch and buys time for orderly remediation. Practitioners should re-evaluate where their current programme assumes patch latency is harmless.

Identity and workload governance are converging around the same problem of exposure windows. Whether the subject is a container, a service account, or an autonomous workload, the failure mode is similar: access exists longer than the organisation can safely manage it. That makes runtime guardrails and lifecycle discipline part of the same governance conversation. Practitioners should align vulnerability management with identity lifecycle controls rather than treating them as separate programmes.

Runtime policy needs to be specific enough to match the exploit path. The article points to a crucial operational distinction: generic visibility does not stop a live attack, but a policy tied to the vulnerable component can. That means teams need controls that understand the actual runtime behaviour they are trying to prevent. Practitioners should test whether their current protections block the exploit mechanism or merely record that it happened.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For a broader governance lens on exposure windows, see NHI Lifecycle Management Guide for how lifecycle control changes the risk surface.

What this signals

Exposure windows are now the metric that matters. If remediation takes weeks, security programmes need a separate control path for live workloads, because patch latency is no longer a tolerable assumption. That is true across containers, machine identities, and other non-human execution paths. For teams shaping policy, runtime containment should be measured alongside patch completion, not after it.

Runtime protection will increasingly sit beside lifecycle governance. The organisations that manage production risk best will be the ones that can answer two questions at once: what is exposed, and what is still actively reachable. That is why the NHI Lifecycle Management Guide is relevant here, even though the article is about container runtime security. In practice, access windows and exploit windows are becoming the same governance problem.

Runtime policy turns vulnerability backlog into an operational containment queue. With 17 minutes the practical attacker window in exposed credential scenarios, teams cannot rely on a remediation cadence that assumes days of slack. The programme signal is clear: build decision paths for fast containment first, then remediation second. For a related control model, the OWASP NHI Top 10 helps frame where exposure and misuse converge.

For practitioners

• Separate discovery from containment decisions Classify critical and high vulnerabilities by whether the workload can be patched immediately, then decide which ones require runtime compensating controls before the next maintenance window.
• Use audit mode as a validation step Run runtime protections in audit mode first, review generated events for false positives, then promote only the policies that match the live workload’s actual behaviour.
• Tie enforcement to remediation SLAs Set a rule that production workloads with unpatched critical CVEs must have either an active runtime shield or a documented exception with named owner and expiry.
• Map runtime coverage to scan output Feed image scan results into a shield inventory so teams can see which vulnerabilities are already covered at runtime and which ones still depend on patching alone.

Key takeaways

• The article shows that vulnerability management fails when production exploitation moves faster than patching.
• The practical scale of the problem is not scan volume alone, but the gap between finding a flaw and containing it live.
• Teams should align runtime enforcement with remediation planning so critical workloads are not left exposed while they wait for maintenance windows.

Key terms

• Runtime Compensating Control: A runtime compensating control reduces the impact of a known weakness while the underlying flaw remains unpatched. In container and workload security, it works by restricting the behaviours an exploit needs, such as file access, network reachability, or process execution, so production can stay online during remediation.
• Shift Left: Shift left is the practice of moving security checks earlier in the software delivery lifecycle, usually into build and pipeline stages. It improves pre-deployment hygiene, but it does not govern the behaviour of a live workload after release, which is why runtime controls are still needed.
• Exposure Window: An exposure window is the period between discovering a weakness and reducing its exploitable risk. For live workloads, that window includes triage, scheduling, downtime constraints, and patch deployment. The shorter the window, the less time an attacker has to turn discovery into compromise.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Aqua Security: How Do You Protect a Workload You Cannot Afford to Patch Right Now? Read the original.