Currently, the hi-tech zeitgeist is filled with articles, comments, and warnings about how AI-powered tools have hit a tipping point whereby they can now find and exploit vulnerabilities in existing code faster than enterprise patch cycles can respond. That threat is real, well-documented, and the subject of our earlier posts in this series.
- Get Your Java Estate Ready for the Growing Agentic AI Threat
- Your Java Patching Cycle Was Designed for a Slower Enemy
But there’s a second direction that deserves equal attention, and it’s one that most enterprise security conversations are still catching up to. The same AI that is accelerating attacks on your Java estate is also being used by your developers to build it. And the code coming out of that process is introducing vulnerabilities at a rate that should concern every engineering and security leader running Java at scale.
These two forces — AI-accelerated exploitation from outside, and AI-generated vulnerability introduction from inside — are converging on the same codebase. Understanding both vectors is the precondition for managing either.
Did Your Developers Already Accept the Productivity Bargain?
AI coding adoption isn’t a future thing, it’s already happened. According to the Stack Overflow 2025 Developer Survey of nearly 50,000 respondents, 84% of developers use or plan to use AI coding tools, and daily usage is now the norm. Gartner projected that by 2028, 75% of enterprise software engineers would use AI code assistants, up from less than 10% in early 2023. The adoption curve has been steep, and largely invisible to security teams.
The productivity case is real. AI coding assistants save developers an average of 3.6 hours per week, accelerate time-to-PR by 48–58%, and enable commit rates 3–4x higher than developers working without AI assistance. For engineering leaders under pressure to ship faster, these are compelling numbers. However, it’s important to acknowledge the fact that, in the real world, raw commit velocity doesn’t equal secure delivery.
What’s less visible is what’s on the other side of the ledger. Cloud Security Alliance research across Fortune 50 enterprises found that AI-assisted developers introduce security findings at 10x the rate of their peers, even as they produce code 3–4x faster. The productivity gains are real. So is the security debt they’re generating, and it’s accumulating faster than most organizations can remediate it.
AI-Generated Code Affects Java Security Disproportionately
Not all languages are equally exposed to AI-generated security failures. Java is disproportionately impacted by a significant margin, and that matters even more for enterprises because Java is where the critical infrastructure lives.
Veracode’s 2025 GenAI Code Security Report is the largest systematic study of AI code security to date, with 100+ large language models tested across 80 real-world coding tasks in Java, Python, C#, and JavaScript, measuring vulnerability rates against OWASP Top 10 standards. The research is credible and rigorous, and has been independently corroborated. The headline finding: 45% of AI-generated code samples introduced OWASP Top 10 security vulnerabilities. For Java specifically, the security failure rate exceeded 70%.
Veracode’s Spring 2026 update made the picture more uncomfortable. Java performed worst “for cases involving CWEs (Common Weakness Enumeration) that are generally easier to avoid, such as SQL injection.” Newer and larger models did not produce more secure code than smaller ones. The pattern appears structural, not a versioning problem on its way to being fixed.
Should Engineering Leaders Be Worried About the Trust Paradox?
According to Stack Overflow survey data, 84% of developers are using AI , but only 29% say they trust AI coding tool output, down from 40% in 2024. Usage and trust are moving in opposite directions. A separate survey found that 76% of developers using AI coding tools reported generating code they didn’t fully understand at least some of the time.
That’s not a criticism of the developers; it’s a description of how these tools work. AI coding assistants excel at producing code that looks correct. The failure modes are subtle, not obvious. A vulnerability in AI-generated Java code doesn’t announce itself, it just gets shipped.
This is why Veracode’s CTO, Jens Wessling, described the dynamic as a fundamental shift: developers are no longer specifying security requirements when they generate code, “effectively leaving secure coding decisions to LLMs.” And LLMs, as the data shows, are not making those decisions well, particularly in Java.
What Does This Mean for the Java Estate You’re Trying to Secure?
The two trends intersect in a way that compounds the risk considerably:
- AI-assisted developers are committing code 3–4x faster.
- More code means a larger attack surface, faster.
- More AI-generated Java code means a higher density of security vulnerabilities entering production, typically in the form of OWASP Top 10 vulnerabilities: SQL injection, cross-site scripting, log injection, insecure cryptographic algorithms, etc.
Those vulnerabilities are landing in a Java estate that most enterprises lack complete visibility into, and that AI-powered adversaries are scanning continuously for exploitable flaws.
The developers writing this code aren’t being careless. They’re using the tools their organizations gave them to meet the velocity expectations their organizations set. The gap is a governance gap.
Where Does Visibility Fit into This Picture?
Neither the external threat (AI-accelerated exploitation) nor the internal threat (AI-generated vulnerabilities) can be managed without knowing what’s actually running in production. An enterprise that doesn’t have a complete, ground-truth picture of its Java estate – which JVMs are running, which versions, which carry active Known Exploited Vulnerabilities (KEV) exposure, which are EOL, etc. – is operating blind to both threat vectors simultaneously.
Azul’s free JVM vulnerability risk assessment establishes that baseline quickly by providing a complete JVM inventory across all hosts, cross-referenced against CISA KEV and NVD data, with a prioritized action list ranked by real-world risk. In most cases, a small number of Java versions account for the majority of exposure, making the path to a more defensible posture far more tractable than the sprawl suggests.
The goal isn’t to slow down AI-assisted development. The productivity gains are real and the competitive pressure is real. The goal is to ensure that the speed at which code is being generated doesn’t outpace the visibility and governance infrastructure needed to manage what gets deployed and what it’s running on.
Register for the July 16 webinar, The Agentic AI Threat Keeping CISOs Up at Night, and learn how to find the blind spots in your Java estate. Attendees are offered a free JVM vulnerability risk assessment from Azul.
