# DevOps: CodeQL 2.24.3 adds Java 26 support — but the bigger shift is analysis catching up with modern build reality

- Link: https://thestackobserver.com/devops-codeql-2-24-3-adds-java-26-support-but-the-bigger-shift-is-analysis-catching-up-with-modern-build-reality/
- Published: 2026-03-11T08:12:37-04:00
- Author: Stackxx

CodeQL 2.24.3 adds Java 26 support, expands Java analysis to select versions based
on Maven POMs across project modules, and ships query improvements for Python, Ruby,
Rust, C/C++, and C#. The obvious headline is language support. The more useful headline
is that code scanning vendors keep having to close the gap between abstract analysis
and real build systems.

That gap is where false confidence lives. A static scanner can be technically enabled
and still be weakly aligned with how a large codebase actually compiles, resolves
frameworks, or models taint flow. This release is another reminder that analysis
fidelity is an operations problem, not just a security feature checkbox.

## What shipped

 * Java 26 support for Java/Kotlin analysis
 * Maven projects now choose Java versions based on module POM data, preferring 
   Java 17+ where possible
 * React observer wrapper support for JavaScript/TypeScript
 * New SSRF sanitization barrier support in Python via AntiSSRF
 * Better taint tracking for Ruby shell escaping and broader jakarta namespace modeling
   for Java

For enterprise teams, the _jakarta_ namespace note is the one to watch. GitHub explicitly
warns that this modeling expansion may increase alerts. That is usually the price
of analysis getting closer to the framework reality your code already depends on.

## Why platform and AppSec teams should care

The maturation pattern is familiar. Teams adopt code scanning, wire it into CI, 
and then discover the hard part is not “running the job.” The hard part is keeping
build images, extractors, language versions, and query packs aligned with the software
they actually ship. When the analysis engine improves its build awareness, you usually
get one of two outcomes:

 * better detection quality, which is good
 * more alerts, which is annoying but often also good

If your organization treats new findings as product regressions instead of visibility
improvements, these upgrades become politically painful. If you treat them as model
improvements that need triage capacity, they become useful.

## What to validate before you celebrate

 * Java monorepos with mixed module settings: do scans now resolve the effective
   Java version more accurately?
 * Teams using `jakarta.*` packages: did alert volume rise, and are the new findings
   legitimate?
 * Polyglot repos: are query-pack upgrades changing baseline noise in a way your
   triage process can absorb?

There is also a timing point here. GitHub says github.com users get new CodeQL versions
automatically, while GHES customers will see the functionality in a future release
or can upgrade manually. In other words, centralized cloud customers inherit improvements
faster, while self-managed customers keep earning their customization story.

Static analysis keeps moving toward environment fidelity because modern software
stacks keep moving away from simple builds. This release is less about Java 26 hype
than about security tooling admitting, again, that build context is part of correctness.

---

## Sources

 * [GitHub Changelog: CodeQL 2.24.3 adds Java 26 support and other improvements](https://github.blog/changelog/2026-03-10-codeql-2-24-3-adds-java-26-support-and-other-improvements/)
 * [CodeQL changelog for version 2.24.3](https://codeql.github.com/docs/codeql-overview/codeql-changelog/codeql-cli-2.24.3/)