Qodana 2026.2: More Security, Better Coverage, Less Configuration

Qodana 2026.2 makes it easier for development teams to act on code quality, security, and compliance findings throughout the development workflow. This release introduces clearer code coverage insights for pull requests, highlights uncovered new lines directly in the IDE, and automatically detects coverage reports in common project locations – reducing the configuration required to get started.

The release also expands Qodana’s security offering with new inspections, support for custom security rules, post-quantum cryptography inspections, and publicly available SAST benchmarks through SABER. Laravel inspections are now enabled by default, while new License Audit quality gates help teams prevent newly introduced dependencies with prohibited or unknown licences from progressing through the pipeline. Let’s get into the details.

Try Qodana

Better Code Coverage UX

Code Coverage for incremental analysis in the IDE

Starting with Qodana 2026.2, pull request analyses can show which changed or added lines are covered by tests and which are not, alongside the total coverage for newly added code, known as fresh coverage.

After the analysis, developers can open the report in the IDE and browse the files changed in the pull request. They can see which files lack coverage through statistics in the tool window, while new lines are highlighted in the IDE to reveal coverage gaps. Developers can use this information to write targeted tests for functionality that lacks coverage, improving the reliability of their software.

Out-of-the-box code coverage reporting

Showing code coverage results in Qodana now requires fewer configuration steps. You no longer need to copy all reports to the .qodana/code-coverage directory, which lets you simplify your build configuration.

Qodana 2026.2 automatically detects coverage reports in the project:

• Qodana for JVM and Qodana for Android: default paths for Jacoco and Kover plugins are supported for both Maven and Gradle
• Qodana for JS: default location coverage/lcov.info is supported, as well as some common community locations like reports or test-coverage directories
• Qodana for PHP: clover.xml and coverage.xml files are supported in common in community locations, such as the project root, build/logs, reports and coverage
• Qodana for Python:  coverage.xml file is supported in common locations like project root, coverage-reports or reports
• Qodana for Go: coverage.out or cover.out files in root directory and other common directories like  coverage, reports are supported
• Qodana for .NET: coverage.cobertura and coverage.info files in project root or other common directories like  coverage or TestResults are supported
  

To generate code coverage reports, set up one of the supported tools, and see your statistics in any run. To disable this behaviour, either selectively copy your reports to the .qodana/code-coverage directory, or specify your custom location using a new codeCoverageLocations parameter in your qodana.yaml file. See the documentation for an example of how to specify a custom directory. To disable coverage reporting, disable the corresponding inspection in your configuration.

View Documentation

New security inspections

Broader SAST and multi-file taint analysis

Qodana 2026.2 expands the security analysis available in the Qodana for .NET linter, helping teams detect a broader range of vulnerabilities in C#, JavaScript, and TypeScript code. The new inspections are enabled by default in the recommended profile and appear as standard Qodana findings within existing IDE, CI/CD, and reporting workflows.

The expanded inspection set combines two forms of analysis. Pattern-matching rules identify insecure coding practices within individual code locations, while taint analysis tracks untrusted data as it moves through an application, including across multiple files. This enables Qodana to detect vulnerabilities such as SQL injection, command injection, cross-site scripting (XSS), and path traversal.

Teams can also extend this coverage with their own security rules. Qodana for .NET now supports custom and third-party rules written in the OpenGrep format. Place these rules in the .qodana/opengrep directory at the project root, and Qodana will make them available as Qodana inspections.

The predefined rules are publicly available in the opengrep-sast-rules repository. Behind the scenes, pattern matching uses an open-source JetBrains fork of OpenGrep, while data-flow tracking is handled by Qodana’s own taint analysis engine. This gives teams access to the OpenGrep rule format and ecosystem while retaining Qodana’s multi-file analysis and developer workflows. Support will be extended to additional Qodana linters and languages (Kotlin/Java) in future releases.

The following example shows how Qodana detects a classic SQL injection vulnerability in the WebGoat.NET project. The taint trace follows untrusted input from Request[“productNumber”] to its use in an SQL query located in another file.

The taint trace begins with the untrusted user input in the Request[“productNumber”]

SABER – Static Analysis Benchmark Evaluation Runner

To make the performance of these inspections easier to evaluate, we have introduced SABER, the Static Analysis Benchmark Evaluation Runner. SABER runs Qodana against publicly available security benchmarks and compares its findings with known expected results.

Transparent SAST benchmarking with SABER

The current benchmark suite includes:

• CodeQL benchmarks for C# and JavaScript, built from CodeQL .expected files
• WebGoat.NET, using publicly available ground-truth data from Sonar
• The Qodana post-quantum cryptography demonstration project

The benchmark configurations, individual runs, and aggregated results are publicly available on the SABER TeamCity instance.

Guest access is enabled, allowing anyone to inspect the results and follow how Qodana’s SAST capabilities develop over time. It is available via this link: https://saber.teamcity.com/ (guest access is enabled, so anyone can open it using the ‘Log in as guest’ option). We have a strong commitment to demonstrating SAST-related capabilities and continually improving them using industry-standard benchmarks. For example, this is the aggregated report for the currently available benchmarks:

Projects ‘CodeQL C#’ and ‘CodeQL JS’  use the jetbrains-qodana/codeql-benchmark project that is built from the CodeQL ‘.expected’ files. Project WebGoat.NET is a well-known vulnerable C# project (our fork is here: jetbrains-qodana/WebGoat.NET) and uses the publicly available ground-truth.json as the expected results. The PQC demo project is a test project that demonstrates the capability to identify post-quantum cryptography issues in your code.

Post-Quantum Cryptography (PQC) inspections

If you have heard about quantum computation, you might know that it will, in the future, easily break many widely used public-key cryptographic algorithms (such as RSA and ECC). Even though quantum computation is not yet widely spread, you should be ready now because of the Harvest Now, Decrypt Later approach, in which future attackers might already harvest and store your encrypted data to decrypt it later.

Qodana for JVM now includes inspections that help developers identify affected code and guide them toward post-quantum cryptographic alternatives, reducing future security risk and supporting a gradual, manageable migration, helping organizations prepare for quantum-era security risks.

Our PQC inspections are implemented in accordance with NIST recommendations and are grouped into several priority levels (called PqcMinLevel1, PqcMinLevel2, and so on to PqcMinLevel5). To enable these inspections, activate one of the corresponding groups that represent NIST-based post-quantum readiness levels:

• Level 1 – Flag pre-quantum and legacy cryptographic algorithms. This uncovers the most critical vulnerabilities.
• Level 2 – Flag baseline post-quantum algorithms.
• Level 3 – Flag standard-strength post-quantum algorithms.
• Level 4 – Flag high-strength post-quantum algorithms.
• Level 5 – Flag all algorithms except those providing maximum security.

Every level includes all previous levels, so level 5 includes inspections from levels 1-4 as well.

We also prepared a demo project (PQC demo) that showcases PQC’s current capabilities. These inspections are backed by OpenGrep and taint analysis (described in the previous section), which also support excellent pattern matching and multifile taint analysis for Java and Kotlin, as shown in the example below.

A non-compliant crypto protocol is found in a string constant

Laravel checks enabled by default

Qodana for PHP now includes Laravel code inspections. This reduces the number of false positives in PHP code, and analyses code for Laravel-specific code problems, such as directly assigning values to guarded attributes.

Quality gates on License Audit

Qodana 2026.2 adds support for license audit quality gates, with two new options:                                                                                                                                                                              

• failOnProhibited — fails the run if any dependency uses a license prohibited by your configured license rules.                                                                                            
• failOnUnknown — fails the run if any dependency has a license that couldn’t be detected or categorized.

For example, in qodana.yaml, the failureConditions section may now contain a dependencyLicenses block:

failureConditions:                                                                                                                                                                                                                     
  dependencyLicenses:                                                                                                                                                                                                                  
    failOnProhibited: true
    failOnUnknown: true

Qodana evaluates the quality gate against the collected dependency licenses directly, independently of whether License Audit problems are present as inspection results. Only the CheckDependencyLicenses inspection needs to be enabled.

License audit quality gates also work for incremental analysis, and only fail on new violations.

What to do next:

If you’re already using the latest release, you’re ready to start using the improvements in Qodana 2026.2 right away. If not, update to 2026.2.

For setup details and feature-specific guidance, head over to the documentation. If you’d like to see what Qodana can do in your own environment, try it on your project and explore the latest updates on the Qodana blog.

Request a demo if you’d like to learn more from our sales team or want 20% off when switching to Qodana from a comparable, commercial solution.

Request Qodana Demo