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.