TL;DR: Securing containerized cloud-native applications from development through production, with runtime protection positioned to reduce mean time to repair and business risk, is the focus of Aqua Security’s CNAPP. For IAM and cloud security teams, the main question is whether security control depth is matching the speed and sprawl of modern workload identity.
At a glance
What this is: This is Aqua Security’s argument that CNAPP must cover the full lifecycle from development to production, with runtime protection as the control layer that limits damage when workloads are live.
Why it matters: For IAM, cloud security, and NHI teams, the message is that workload identity and container controls cannot stop at deployment gates if the business risk appears during execution.
Context
Aqua Security’s article argues that container security should not stop at pre-deployment checks. The core problem is that cloud-native workloads change state after release, so controls limited to build time leave runtime behaviour under-governed.
In identity terms, this is a workload and cloud security governance issue, not just a scanning issue. CNAPP only becomes meaningful when it can observe and constrain what applications, containers, and supporting identities do in production.
The article positions runtime protection as the point where prevention and detection meet operational reality. That framing is typical for CNAPP discussions, but the emphasis on live production risk is the central takeaway.
Key questions
Q: How should cloud teams govern workload risk after deployment?
A: Cloud teams should treat runtime as the control point where workload permissions, process behaviour, and response actions are actively governed. Pre-deployment scanning is necessary, but it does not address what happens once containers are live and connected to cloud services. The practical test is whether teams can observe, constrain, and remediate behaviour in production.
Q: Why do build-time controls fall short for container security?
A: Build-time controls cannot see the permissions, network relationships, and runtime behaviour that appear only after release. A container that passed scanning can still create risk in production if it inherits broad access or behaves unexpectedly. That is why runtime protection matters: it governs the live attack surface, not just the package that was approved.
Q: What are the signs that cloud-native security is too narrow?
A: The clearest sign is when teams can describe image scanning in detail but cannot explain how they detect or contain malicious behaviour once workloads are running. Another sign is when runtime events, service permissions, and workload telemetry are owned by different teams with no shared response model. That usually means the programme is narrower than the risk.
Q: What happens when CNAPP focuses only on pre-deployment checks?
A: The programme may reduce known defects, but it leaves live workload behaviour under-governed. That creates a gap between approval and execution, which is where many cloud incidents become expensive. Runtime controls are the layer that limits blast radius when something slips past the build pipeline or changes state after deployment.
Technical breakdown
Why runtime protection matters after deployment
Runtime protection addresses the part of cloud-native risk that build-time controls cannot see. Container images may be scanned before release, but the actual attack surface emerges when workloads start communicating, mounting secrets, calling APIs, and inheriting cloud permissions in production. CNAPP combines agent and agentless visibility so security teams can detect suspicious process activity, policy drift, and unexpected behaviour after deployment. That matters because many cloud incidents are not caused by a bad image alone, but by what happens once a workload is live and connected to other services.
Practical implication: Treat runtime telemetry as a separate control plane, not as a supplement to pre-release scanning.
How CNAPP links prevention and mitigation
The article describes a lifecycle model that runs from code to cloud, which is the right lens for container and cloud-native security. Pre-deployment hygiene reduces known risk, but runtime controls are what limit blast radius when something slips through. In practical terms, CNAPP has to connect policy enforcement, workload visibility, and detection in one operating model so teams can prevent obvious issues early and still react when something unexpected happens in production. That is especially relevant where cloud workloads move quickly and remain short-lived.
Practical implication: Map controls to the full lifecycle and define where prevention ends and mitigation begins.
What agent and agentless coverage changes for cloud teams
Agent-based and agentless approaches solve different visibility problems. Agentless inspection can reduce friction in cloud environments, while agent-based telemetry can provide deeper process and runtime context inside the workload. The article frames both as part of a single CNAPP approach, which reflects a broader market reality: cloud teams need coverage that works across heterogeneous environments without slowing delivery. The technical challenge is less about choosing one method and more about understanding which runtime signals each method can actually observe.
Practical implication: Validate which runtime events each inspection method can see before assuming coverage is complete.
Breaches seen in the wild
- SAP Kubernetes secrets exposure 2023: Kubernetes secrets committed to GitHub exposed 203 valid registry credentials, including SAP artifact repository access. SAP closed it after Aqua's report.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Runtime protection is the missing control plane in many CNAPP programmes: build-time security reduces known defects, but it does not govern what a workload does once it is live. That gap matters because modern cloud risk is increasingly operational, not just structural. Practitioners should treat runtime as the point where cloud security either becomes real or remains theoretical.
CNAPP only changes practitioner outcomes when it connects visibility to enforcement: a tool that simply reports drift does not close the governance gap. The article’s real signal is that teams are looking for one operating model that spans prevention, detection, and response across containerised workloads. That aligns with how cloud-native programmes now have to be run.
Identity scope inside the workload matters as much as image hygiene: containers do not become safe because the image passed a scan. Once deployed, they inherit permissions, call services, and touch data paths that can widen blast radius if runtime behaviour is not constrained. Cloud teams need to govern what the workload can do after launch, not only what was approved before launch.
Deep runtime focus is a response to cloud sprawl, not a niche preference: the more distributed the environment, the less useful one-dimensional control coverage becomes. That makes the operational question sharper for IAM and cloud security leads: which controls actually reduce risk in production, and which only improve posture reports? The answer increasingly determines whether CNAPP is useful or cosmetic.
Cloud-native security is converging on production-time accountability: the industry is moving away from a build-only mindset and toward controls that can prove value during execution. That shifts the conversation from feature breadth to governance depth, which is where practitioner programmes either mature or accumulate blind spots. The implication is to benchmark controls against live workload risk, not product category labels.
What this signals
Runtime protection is becoming the practical test for cloud-native maturity: once workloads are live, the question is no longer whether they were scanned but whether they can be observed and constrained in motion. Security programmes that stop at the deployment gate will keep missing the part of the attack surface that actually creates incident cost.
Cloud workload identity and runtime telemetry need to be governed together: containers inherit permissions, contact services, and expose data paths after launch, which means identity scope and runtime behaviour are inseparable in production. Teams that split those responsibilities across siloed controls will keep discovering gaps too late.
CNAPP value now depends on whether it reduces blast radius, not just noise: the operational win is not another dashboard, but faster containment when workloads misbehave under real conditions. That makes runtime enforcement, response integration, and workload visibility the controls that matter most to programme owners.
For practitioners
- Define runtime as a separate control objective Map the controls that must operate after deployment, including behavioural detection, policy enforcement, and response paths for live workloads.
- Inventory workload permissions in production Review the cloud permissions, service-to-service access, and inherited identities that become active only when containers start running.
- Test whether agentless visibility covers live behaviour Verify which runtime events are visible without agents and where you still need deeper process-level telemetry.
- Separate pre-deployment hygiene from mitigation Keep image scanning and policy checks, but define the runtime controls that contain incidents after release rather than assuming prevention is enough.
Key takeaways
- Cloud-native security becomes materially different once workloads are running, because production-time behaviour creates risk that build-time controls cannot fully see.
- The article’s main signal is that runtime protection is not a niche add-on, but the control layer that turns CNAPP from posture reporting into live risk management.
- For practitioners, the decision is whether their cloud programme can observe and contain workload behaviour after deployment, not just approve images before release.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-08 — Environment Isolation | Runtime protection for containers depends on isolating workloads and constraining what they can reach in production. |
| Recommendation — Use environment isolation controls to limit what deployed workloads can access if runtime behaviour changes. | ||
| NIST CSF 2.0 | PR.PS-01 — Configuration management | The article centres on securing cloud-native workloads through lifecycle controls from deployment into production. |
| DE.CM-08 — Vulnerabilities, threats and anomalies are monitored | Runtime protection depends on monitoring live workload behaviour for anomalies and suspicious actions. | |
| Recommendation — Maintain secure baseline configurations for workloads before they enter production. Monitor production workloads for anomalous runtime activity and alert on deviation from expected behaviour. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | The article’s pre-deployment hygiene and runtime posture themes align with secure configuration discipline. |
| Recommendation — Apply secure configuration baselines to cloud workloads and validate them continuously after deployment. | ||
Key terms
- Runtime Protection: Runtime protection is a control model that observes application behavior while software is running and blocks unsafe actions as they occur. In Java estates, it helps distinguish active exploit paths from dormant vulnerable code, which is essential when patching is delayed or impossible.
- CNAPP: Cloud-Native Application Protection Platform is an integration model that combines posture, entitlement, workload, data, and runtime signals in one view. Its value depends on the quality of the underlying governance layers, not on correlation alone.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org