Knowingly Shipping Vulnerable Code Has Become Standard Practice, Survey Finds
A Checkmarx survey of 2,350 security leaders finds nearly half of production code is AI-generated, and enterprises are deploying it despite knowing it carries unresolved flaws.
Key points
- Three-quarters of enterprises now knowingly deploy vulnerable code, per a Checkmarx survey of 2,350 security leaders across 14 countries.
- Enterprises where AI writes 81-100% of code ship vulnerable software 3.4 times more often than those keeping AI output at 20% or below.
- About 30% of respondents ship compromised code and simply hope the flaw goes undetected.
- Only 22% of surveyed organizations have formal AI governance in place.
- The report warns that Mythos-class models compress the window from vulnerability discovery to working exploit from months to minutes.
How bad is the normalization problem?
Three-quarters of enterprises now knowingly deploy vulnerable code. The Checkmarx survey, covering CISOs, AppSec managers and developers across 14 countries, describes an industry that has normalized risk rather than reduced it.
Nearly half of all production code is AI-generated. Seventy percent of developers said AI code generation introduced vulnerabilities in 2025, and 93% of surveyed enterprises experienced at least one breach directly attributable to an in-house application. More than a third leave at least half their known vulnerabilities unpatched for 90 days or longer.
Should you worry about the self-assessment gap?
Yes, and the numbers make it concrete. Among organizations rating themselves "highly mature" on AI security, 42% ship some of the most vulnerable code, with breach rates "barely distinguishable" from less confident peers. The report is blunt: "Confidence isn't protecting them. It's blinding them."
Manual code review remains the dominant compliance mechanism. Developers apply security tooling continuously only 18% of the time. When things fail, developers absorb the blame in post-mortems and performance reviews, even when the workflows that set them up to fail go unfixed.
We covered Anthropic's Mythos in June, reporting that machine-speed vulnerability discovery is no longer theoretical. Checkmarx's survey was completed before Mythos became publicly discussed, yet the data already reflects an acceleration problem that model has since sharpened.
What does Checkmarx say enterprises must actually change?
Four structural shifts. First, prioritize risk over code volume rather than treating vulnerabilities as isolated incidents. Second, embed security into IDE and pipeline workflows instead of staging it as a checkpoint. Third, consolidate fragmented tool stacks with clear ownership. Fourth, replace manual triage with automated remediation that doesn't require human sign-off at every step.
What are the regulatory stakes?
The survey doesn't fully surface them, but they're real. Public companies face disclosure obligations around known, material weaknesses in their controls, and deliberately deferring patches while executives certify sound controls is a narrow lane to walk. CIRCIA's forthcoming final rulemaking will add incident-reporting obligations for critical infrastructure operators. The survey data suggests many organizations aren't positioned for either regime.
On this beat, the piece that sticks with me is HD Moore's argument from 3 June that blast-radius control, not patch velocity, is what regulators should be measuring. This survey is evidence he's right: the bottleneck isn't detection, it's the decision to ship anyway.
