TL;DR: Aqua argues that vulnerability management is breaking under production scale because AI-driven attacks can weaponize a newly discovered flaw within hours, long before teams can patch or schedule downtime. The real control gap is the time between discovery and remediation, and runtime compensating controls now matter more than scan volume.
NHIMG editorial — based on content published by Aqua Security: How Do You Protect a Workload You Cannot Afford to Patch Right Now?
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
Aqua's full blog covers the operational detail this post intentionally leaves for the source:
- The runtime policy workflow for activating protections directly from scan results.
- The audit mode to enforce mode transition model used before production blocking.
- The scenarios where the vendor says runtime shielding reduces pressure on patch schedules.
- The product and architecture discussion behind its container enforcement approach.
👉 Read Aqua Security's analysis of runtime protection for unpatched container workloads →
Container runtime protection: what it means for vulnerability management?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Runtime protection closes the container patching gap in production