Release notes

Server operation

IPv6 support

SonarQube Server now supports IPv6 addresses:

• For the ZIP installation: all editions.
• For the Docker installation: Developer Edition and Enterprise Edition.

An additional configuration is required. For setup information, see Enabling IPv6 in ZIP installation or Docker installation. 

System info and server logs improved

Data Center Edition server logs available from the UI

If you have a Data Center Edition, you can now download the server logs for all nodes by using the Administration > System menu on any node. 

Java options in system info more accurate 

The system info now includes Java options information:

• For a Developer or Enterprise Edition: for each process (Web, Compute Engine, or Search) instead of globally.
• For a Data Center Edition: for each node instead of only for application nodes.

AI features

AI CodeFix 

Support of self-hosted LLMs on Azure Open AI

You can now choose your own Azure OpenAI LLM as the provider for AI CodeFix. See Enabling AI-generated fix suggestions.

Expansion of rules coverage

The AI CodeFix's rule coverage has been extended across multiple programming languages, ultimately improving code quality and developer productivity with relative ease.

The following rules have been updated to support AI CodeFix:

• C#: S3241
• C++:  S125, S995, S5416, S5350, S1238, S1905, S3490, S3659, S1155, S3229, S959, S2259, S6229, S905, S3923, S1768, S1751
• JavaScript / TypeScript: S878, S1874, S125, S3358, S905, S1854, S1481, S6644
• Python: S112, S5754, S1186, S1940, S1854, S6660, S1515, S1110, S5795

New SONAR_AI_CODEFIX_HIDDEN environment variable

You can now use the SONAR_AI_CODEFIX_HIDDEN environment variable to disable AI CodeFix in SonarQube Server in addition to the sonar.ai.codefix.hidden property.

Analyzers, scanners, languages

New Design and Architecture feature

Through its new Design & Architecture feature, SonarQube Server can now verify the architecture and design of Java source code by:

• Verifying the code structure against architecture and design patterns.
• Applying cycle detection to detect circular dependencies in your code.

The verification process is as follows:

• You specify in a configuration file your architecture model including architectural constraints. 
• SonarQube Server compares your code with your model based on architecture rules. It raises issues when it identifies divergences and when it detects circular dependencies. 

For more information, see Design and Architecture.

CFamily analysis

New C++ rule

The following C++ rule has been added:

• S7172: Named methods should be used to avoid confusion between testing an optional or an expected and testing the wrapped value

New Misra C++ 2023 rules in Early Access

New Misra C++ 2023 rules are supported from the Enterprise Edition in Early Access.

To enable the new rules in your SonarQube Server instance, go to Administration > General Settings > Early Access Features.

Note: To disable the Early Access warning, see Disabling the Misra 2023 C++ Early Access warning.

Go analysis

Go 1.23 now supported

SonarQube Server now supports the analysis of Go 1.23 code.

New foundational Go security rules

The following foundational Go security rules have been added:

Vulnerability issues:

• S4423: Weak SSL/TLS protocols should not be used
• S3330: Creating cookies without the “HttpOnly” flag is security-sensitive
• S2092: Creating cookies without the “secure” flag is security-sensitive
• S4507: Delivering code in production with debug features activated is security-sensitive
• S2068: Hard-coded credentials are security-sensitive
• S2612: Setting loose POSIX file permissions is security-sensitive
• S1313: Using hardcoded IP addresses is security-sensitive
• S2245: Using pseudorandom number generators (PRNGs) is security-sensitive
• S4790: Using weak hashing algorithms is security-sensitive
• S6437: Credentials should not be hard-coded
• S5547: Cipher algorithms should be robust
• S3329: Cipher Block Chaining IVs should be unpredictable
• S5542: Encryption algorithms should be used with secure mode and padding scheme
• S5445: Insecure temporary file creation methods should not be used
• S5344: Passwords should not be stored in plaintext or with a fast hashing algorithm
• S4830: Server certificates should be verified during SSL/TLS connections
• S5527: Server hostnames should be verified during SSL/TLS connections
• S4426: Cryptographic keys should be robust
• S2053: Password hashing functions should use an unpredictable salt

Security hotpots:

• S6418: Hard-coded secrets are security-sensitive
• S5443: Using publicly writable directories is security-sensitive
• S5332: Using clear-text protocols is security-sensitive
• S4036: Searching OS commands in PATH is security-sensitive
• S2077: Formatting SQL queries is security-sensitive

Java analysis

The following Spring Java rules have been added:

• S7177: Use appropriate @DirtiesContext modes
• S7178: Injecting data into static fields is not supported by Spring
• S7179: @Cacheable and @CachePut should not be combined
• S7180: "@Cache*" annotations should only be applied on concrete classes
• S7183: @InitBinder methods should have void return type
• S7184: "@Scheduled" annotation should only be applied to no-arg methods
• S7185: @eventlistener methods should have one parameter at most
• S7186: Methods returning "Page" or "Slice" must take "Pageable" as an input parameter
• S7190: Methods annotated with "@BeforeTransaction" or "@AfterTransaction" must respect the contract

The following Spring Java rules have been improved:

• S6856: "@PathVariable" annotation should be present if a path variable is used
  This rule will now raise an issue if a method has a path template with a placeholder, but no corresponding @PathVariable, or vice-versa.
• S6809: Methods with Spring proxy should not be called via "this"
  This rule will now also check for methods annotated with Spring's @Cacheable annotation.

Kotlin analysis

Over 80 rules have been rebuilt to support Kotlin 2.0 and the new K2 compiler. As a result, Kotlin analysis is now 50% faster than before this release. Kotlin developers can now not only use Sonar to analyze Kotlin 2.0 and newer, but it also performs better than before.

.NET analysis

Upload of test-related metrics at file level

Projects based on .NET now show test-related metrics at the file level. The SonarScanner for .NET will calculate and pass to the server the per-file metrics of:

• Number of Unit Tests
• Errors in Unit Tests
• Failed Unit Tests
• Skipped Unit Tests
• Duration of Unit Tests

The SonarScanner for .NET will only support the following test reports:

• NUnit
• XUnit
• Visual Studio

.NET rules improved

A secondary location message has been added to the .NET rules.

PHP analysis

The elsif keyword is now taken into account in the Cyclomatic Complexity calculation.

Python analysis

The following rules are now available to allow you to check performance, maintainability and correctness in your PySpark code in Python and Jupyter Notebook files with SonarQube Server:

• S7181: PySpark Window functions should always specify a frame
• S7182: The “subset” argument should be provided when using PySpark DataFrame “dropDuplicates” method
• S7187: PySpark Pandas DataFrame columns should not use a reserved name
• S7189: PySpark DataFrames used multiple times should be cached or persisted
• S7191: PySpark withColumns should be preferred over withColumn when multiple columns are specified
• S7192: The “how” parameter should be specified when joining two PySpark DataFrames
• S7195: PySpark lit(None) should be used when populating empty columns
• S7196: Complex logic provided to PySpark “withColumn”, “filter” and “when” methods should be refactored into separate expressions

README for local project installation improved

Information about building locally has been added to the README.

New rules to cover OWASP Mobile Top 10

By now providing at least one rule for each of the OWASP Mobile Top 10 categories, with the exception of M4: Insufficient Input/Output Validation, Sonar offers a solution that enables Android developers to assess their applications against the OWASP Mobile Top 10, ensuring they meet industry standards for security.

Issue retrieval and fixing

Issue filters now more compact

The vertical padding of the issue filter conditions has been reduced.

Web API

Deprecated POST and PATCH parameters now logged into the deprecated log file

Whenever a V2 deprecated POST or PATCH parameter is used, a deprecation message is logged into the deprecated log file indicating what is or will be deprecated and from when.

Server operation

Java 21 supported for running SonarQube Server

SonarQube Server can now run in a Java 21 environment. 

DevOps platform integration

Improvement to BitBucket server onboarding

To improve the import of BitBucket repositories, you can now browse and easily import all the projects from the onboarding page, without any limitation of number.

AI features

Automatic detection of AI-generated code from GitHub Copilot

Knowing if your project contains AI-generated code helps raise awareness of code ownership and code security. To help build this awareness, SonarQube Server can autodetect AI-generated code in projects on GitHub using GitHub Copilot. You can then protect these projects using the AI code assurance features. See the Autodetecting AI code page for more information.

Analyzers, scanners, languages

Faster analysis bootstrap

To improve analysis efficiency, we’ve shortened the time it takes to load the active rules in your quality profile.

PHP analysis

PHP analysis now supports asymmetric property visibility (PHP 8.4).

T-SQL analysis

T-SQL analysis supports the STIG security standard and more language constructs.

VB analysis

VB analysis has 2 new rules.

None in this release.

Update in PostgreSQL support

PostgreSQL version 11 is no longer supported. Supported versions are now from 13 to 17.

SAML configuration update required

When configuring SAML on your SonarQube Server instance with assertion encryption, the response signature must be enforced. You might need to update your SAML configuration:

• If you use SAML with Microsoft Entra, make sure you sign the response by selecting Sign SAML response or Sign SAML response and assertion as the sign-in response. See Step 2 > If you use encryption, enforce response signature in Setup of security features.
• If you use SAML with PingID, make sure you sign the response by selecting Sign Response or Sign Assertion & Response as the sign-in response. See Step 2 > To enable the encryption of SAML assertions in Setup of security features.

In addition, the assertion decryption now requires that you also store the public key certificate in SonarQube Server (not only the private key). Make sure the certificate is stored in SonarQube as follows:

1. In SonarQube Server, go to Administration > Configuration > General Settings > Authentication > SAML.
2. In SAML Configuration > SAML, select Edit. The Edit SAML configuration dialog opens.
3. In Service provider certificate, enter the certificate.

Server base URL setup now mandatory for SAML authentication

Your SAML authentication setup will not work if the SonarQube Server base URL is not set in SonarQube Server. See Configuring the SonarQube Server base URL.

If migrating from 10.7: AI Code Assurance lost on projects

In SonarQube Server 10.7, the Sonar way quality gate was enforced on projects marked as containing AI Code. If you're migrating from this version, these projects will loose AI Code Assurance. To resolve this, you must apply a quality gate qualified for AI Code Assurance to these projects. To do so, you can use the Sonar way for AI Code quality gate or a custom quality gate you have qualified for AI Code Assurance. See Assuring your AI Code.

None in this release.

Property encryption on scanner side deprecated

Property encryption on the scanner side is now deprecated. 

sonar.password property removed

The sonar.password scanner property that was deprecated in SonarQube Server 9.8 has now been removed. 

BCrypt password hashing method removed

The BCrypt hash method used for passwords was deprecated in SonarQube Server 8.9. It has now been removed. As a result, the passwords of users who have not logged in since SonarQube 8.9 are deactivated and an admin must reset them if these users need to log in again.

Some complexity metrics removed

The following complexity metrics, which were deprecated in SonarQube Server 6.7, have now been removed: 

• file_complexity
• complexity_in_classes
• class_complexity
• complexity_in_functions
• function_complexity
• function_complexity_distribution
• file_complexity_distribution