ICYMI: improved C++ vulnerability coverage and CodeQL support for Lombok

CodeQL expands C++ memory-safety checks and adds Lombok support

Static analysis is only as useful as the ground it covers. Codebases lean on a wide mix of languages, frameworks and libraries, so a scanner that misses a common pattern or a whole ecosystem can leave real gaps in your security posture. Two recent updates to CodeQL narrow those gaps: deeper C++ vulnerability detection and native support for Java codebases using Project Lombok.

New C++ memory corruption queries in the default suite

Memory corruption in C and C++ is notoriously hard to trace. Low-level pointer manipulation, undefined behavior, platform differences and dynamic allocation all make it easy for a subtle bug to slip through. CodeQL's default query suite now catches two classic failure modes directly:

• cpp/double-free and cpp/use-after-free for double-free and use-after-free vulnerabilities
• cpp/redundant-null-check-simple, which flags dereferences that happen regardless of a null check's outcome, or where a null check always follows the dereference — a strong hint the pointer can actually be null

General "suspicious dereference" detection is difficult precisely because code often makes the dereference appear safe. The null-check query sidesteps that by focusing on the logic around the dereference rather than the pointer itself.

Buffer overflow analysis in the security-extended suite

Two additional queries — cpp/overrun-write and cpp/invalid-pointer-deref — improve detection of out-of-bounds pointer dereferences. Both rely on a novel technique that runs two parallel dataflow analyses: one tracks the pointer, the other tracks the allocation size. This lets the queries identify places where a guard is off by one, a pattern common enough to be a recurring source of CVEs.

The approach has already proven itself against real-world vulnerabilities. On the LibX11 project, cpp/invalid-pointer-deref finds both the read and the write of a pointer to an element one past the end of an allocation in CVE-2018-14599:

Similarly, in the PHP interpreter, the query catches an off-by-one write guarded incorrectly, exploitable via a crafted PHAR archive in CVE-2016-10160:

These queries are deliberately tuned to avoid flooding developers with alerts. The current focus is on holding down false positives while gradually eliminating false negatives in memory corruption detection.

Lombok support lands for Java scanning

Lombok removes Java boilerplate by generating common methods and behaviors at compile time. Previously, scanning a Java project that used Lombok meant that files containing Lombok annotations were skipped entirely, or required a workaround to prepare the code for analysis. CodeQL now handles Lombok code automatically, so code-scanning users get full coverage without extra steps.

For more on enabling security features across your repositories, see the getting started guide.