Notifications
Clear all
Topic starter
19/08/2026 3:27 pm
TL;DR: AI code generation can produce working code 83% to 95% of the time, but only 24% to 36% of outputs are both functional and secure, according to Checkmarx-initiated research. Adding a post-generation security review lifts the secure-and-functional rate to 47% to 56%, showing that application security now has to verify what models produce, not just whether it runs.
NHIMG editorial — based on content published by Checkmarx: Black Hat USA 2026 and the AppSec trust gap created by AI-generated code
By the numbers:
- On real-world repository tasks, frontier models produced working code 83% to 95% of the time.
- Only 24% to 36% of those solutions were both functional and secure.
- A post-generation security review improved the secure-and-functional rate to 47% to 56%.
Questions worth separating out
Q: How should security teams govern AI-generated code in production pipelines?
A: Security teams should treat AI-generated code as a controlled identity event, not just a development artifact.
Q: Why do traditional AppSec signals fail with AI-generated code?
A: Traditional signals such as passing tests, successful builds, and confident model explanations only prove that the code behaves as requested.
Q: What do teams get wrong about AI-generated documentation and code review?
A: They often assume documentation or review output is proof of oversight.
Practitioner guidance
- Separate generation from verification Require an independent security control to review AI-generated code before merge, especially for access control logic, dependency changes, and secret handling.
- Prioritise context-enriched triage Score findings using reachability, exploitability, ownership, runtime exposure, and business criticality so teams focus on attackable risk rather than raw alert volume.
- Treat AI agents as governed actors Inventory repositories, MCP servers, packages, and permissions used by coding agents, then map each one to an accountable owner and an explicit policy boundary.
What's in the full article
Checkmarx's full article covers the operational detail this post intentionally leaves for the source:
- The underlying research setup and how the AI-generated code tasks were evaluated across real repository scenarios.
- The specific workflow design behind the post-generation security review and how it changed secure output rates.
- Operational details on Checkmarx Fusion, AI Inventory, Triage Assist, and Developer Assist in practice.
- The article's full explanation of how context, policy, and remediation are applied across the software lifecycle.
👉 Read Checkmarx's analysis of AI-generated code and AppSec trust signals →
AI-generated code and AppSec: are your trust signals still valid?
Explore further
19/08/2026 4:11 pm
AI-generated code has created an AppSec trust gap: code that works is no longer a reliable proxy for code that is safe. The article shows that functional success and security success are now diverging, which means verification has to become a separate control, not a side effect of testing. This is a governance problem for every programme that relies on AI-assisted development, because the organisation is effectively accepting software from a system that can produce plausible but insecure output. Practitioners should treat independent verification as a required control, not a discretionary quality step.
A question worth separating out:
Q: How can organisations reduce risk without stopping AI-assisted development?
A: Organisations should keep AI assistance but make the secure path the easiest path. That means secure prompt guidance, mandatory scanning, dependency allowlists, and extra review for security-critical code paths. The aim is not to ban speed, but to make sure productivity gains do not bypass the controls that protect production systems.
👉 Read our full editorial: AI-generated code exposes an AppSec trust gap beyond test results
