Notifications
Clear all
Topic starter
24/06/2026 10:45 pm
TL;DR: AI-driven code security can now find more than 500 high-severity vulnerabilities in production open-source codebases, according to Aqua Security citing Anthropic’s Claude Code Security results. That improves pre-deployment analysis, but it does not replace runtime security, because production-only misconfigurations, privilege escalation, and workload drift still determine real exposure.
NHIMG editorial — based on content published by Aqua Security: When AI Writes, Scans and Fixes Code, Runtime Becomes the Last Line of Defense
By the numbers:
- Claude Code Security found over 500 high-severity vulnerabilities in production open-source codebases.
Questions worth separating out
Q: How should security teams combine AI code scanning with runtime security?
A: Use AI code scanning to reduce obvious pre-deployment defects, then use runtime security to validate what is actually executing in production.
Q: When does pre-deployment scanning stop being enough for cloud-native systems?
A: Pre-deployment scanning stops being enough when the security question depends on runtime state, not source code.
Q: What do security teams get wrong about shift-left and AI-assisted review?
A: The common mistake is assuming better analysis of code automatically means lower production risk.
Practitioner guidance
- Separate build-time and runtime control ownership Assign static analysis, container scanning, and dependency review to engineering pipelines, then assign workload monitoring, policy enforcement, and privileged-access control to runtime security owners.
- Prioritise exploitable runtime exposure over raw CVE volume Use live workload context to decide whether a vulnerability is reachable, whether the process is actually running, and whether the container can escalate privileges or move laterally.
- Map workload identities to their production blast radius Review which service accounts, tokens, and runtime identities are available after deployment, what they can reach, and what containers inherit them by default.
What's in the full article
Aqua Security's full article covers the operational detail this post intentionally leaves for the source:
- The container-layer explanation of why code, frameworks, and base images create different security failure modes.
- Aqua's runtime telemetry examples showing which processes, network connections, and file touches reveal actual exposure.
- The vendor's view of how runtime context separates theoretical vulnerabilities from production-reachable ones.
- The article's operational discussion of how faster AI-assisted development changes the burden on container protection teams.
👉 Read Aqua Security's analysis of why runtime security still matters for AI-assisted code review →
AI code scanning and runtime security: what changes for teams?
Explore further
25/06/2026 7:33 am
Runtime security is becoming the trust boundary that code scanning cannot cross. AI can improve pre-deployment detection, but it does not change the fact that exploitable exposure is often created after deployment by configuration, privilege, and workload behaviour. The important shift for the field is that the control plane moves from code correctness to runtime observability and enforcement. Practitioners should treat production behaviour as the authoritative security state.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to the same research.
A question worth separating out:
Q: Why does runtime security matter for workload identities in containers?
A: Workload identities control what a live container can do once it is running, so they define the practical blast radius of a compromise. If permissions are too broad or inherited by default, runtime exposure becomes much larger than source code review suggests. That is why identity scope must be managed in production, not just at build time.
👉 Read our full editorial: Runtime security remains the limit for AI code scanning
