Security teams in large enterprises already spend significant time tracking vulnerabilities across software supply chains, third-party libraries, and internal codebases. Java environments add another layer of exposure because so many mission-critical systems still run on the JVM. A 2026 Azul survey of more than 2,000 Java professionals found that 64% said more than half of their organization’s applications or workloads are built with Java or run on a Java Virtual Machine.
That footprint means Java security issues quickly become enterprise-wide problems, especially as organizations expand cloud deployments and integrate AI functionality into production services.
56% of enterprises deal with CVEs daily or weekly (Source: Azul)
CVE response is becoming a routine task
Many Java teams now treat vulnerability response as a recurring operational process. In the survey, 56% of respondents said their organization finds critical production security issues in the Java ecosystem daily or weekly. That includes vulnerabilities in Java applications, libraries, frameworks, and supporting infrastructure.
For many organizations, patching and remediation are part of regular DevOps workflows, driven by constant disclosures and continuous scanning. This pattern is especially relevant for regulated industries and large enterprises where Java supports transaction processing, customer portals, and backend services.
False positives are consuming DevOps time
In the survey, 30% of respondents said their DevOps teams spend more than half their time dealing with security vulnerability false positives tied to JVM-based workloads. False positives can come from multiple sources, including dependency scanners, misclassified vulnerabilities, and CI/CD pipeline tooling that flags code paths that never execute in production.
In practice, this creates a productivity issue with security impact. When teams spend large amounts of time sorting through low-value alerts, patching priorities become harder to manage and remediation cycles slow down.
Dead code is a security issue as much as a productivity issue
Large Java estates often accumulate unused code that teams hesitate to remove. In the survey, 63% of respondents said dead or unused Java code affects DevOps productivity either “to a great extent” or “somewhat.”
This matters for security because unused code still increases the attack surface in several ways. It can introduce additional dependencies, leave outdated libraries in place, and create uncertainty about what can safely be patched or removed.
Legacy code also complicates incident response. When teams do not have confidence in what code is active, vulnerability remediation often turns into broad patching exercises that require extensive testing and coordination.
Oracle licensing pressure is influencing security planning
In the survey, 92% of respondents said they were concerned about Oracle Java pricing. At the same time, 81% said their organization has migrated, is migrating, or plans to migrate some or all Oracle Java workloads to a non-Oracle OpenJDK distribution.
This trend creates two parallel risks. One is operational disruption. Migration projects involve changes to runtime environments, patching workflows, and support models. The second is version sprawl. Partial migrations can leave organizations maintaining multiple Java distributions across production systems, increasing complexity for vulnerability management and compliance audits.
The survey also tied faster adoption of newer Java LTS releases to security and compliance pressure, since unsupported Java versions increase exposure.
AI code generation adds another security variable
Java developers are increasingly using AI tools to write and update code. In the survey, 30% of respondents said more than half of their new Java application code is created by AI code-generation tools.
ChatGPT was the most commonly used tool for automated Java code updates, selected by 58% of respondents. Gemini AI followed at 51%, with Amazon Q at 32% and Claude AI at 31%.
This trend adds security questions around code provenance, insecure patterns introduced by generated code, and the risk of teams deploying code they did not review. It also increases the importance of runtime monitoring and vulnerability detection tied to production execution.

Deixe o seu comentário