TL;DR overview
- Part two of the SonarQube 9.9 LTS extra features series continues documenting improvements delivered in patch releases, including additional security rules, performance optimizations, and expanded language coverage.
- New detections target code vulnerability patterns identified by Sonar's research team and informed by customer feedback from production deployments of the 9.9 LTS.
- Performance improvements in this batch reduce analysis time for large Java and C++ codebases, addressing common bottlenecks reported by enterprise teams with monorepo or multi-module projects.
- Organizations that have not yet applied all 9.9 LTS patches should do so to receive the complete set of improvements before planning an upgrade to the 2025.1 LTA.
SonarQube Server 9.9 LTS was released in February, and we hope you’ve already seen our announcement and are working on your upgrade!
In March, we published 9 more reasons to upgrade to SonarQube Server 9.9 LTS that weren’t featured in our big release announcement – and we aren’t done yet! There’s still more to know about the micro-features and improvements that are in our Best LTS Ever.
Without further ado, here are another 9 reasons you should prioritize upgrading to SonarQube Server 9.9 LTS.
1. Import SARIF reports generated by other tools
In 2019, the Static Analysis Results Interchange Format (SARIF) was defined as a standard format for the output of static analysis tools. Since then, this format has seen a lot of adoption among security tools.
Responding to feedback from our Community, in SonarQube Server 9.9 LTS it’s now possible to import issues from SARIF reports alongside your SonarQube Server analysis! Now developers don’t need to leave SonarQube Server to be aware of findings from these reports.
2. Detect New Code in Git Submodules
Git allows you to use submodules when referencing another git repository.
Love them or hate them, they exist – and until recently, they broke SonarQube Server’s detection of New Code. This caused unnecessary noise to appear for developers when analyzing their pull requests. While SonarQube Server could detect that files some files had changed, SonarQube Server couldn't determine which specific lines had changed.
In SonarQube Server 9.9 LTS, we’ve addressed this. Welcome to the family, git submodules (bless your heart).
3. No more “zombie” Quality Profiles from removed plugins
When installing third-party plugins, they sometimes provide built-in Quality Profiles (like how Sonar's analyzers provide the built-in “Sonar Way” Quality Profiles).
In the past, if you removed such a third-party plugin, you were stuck with a Quality Profile you couldn’t delete unless you made dangerous database changes. This was understandably frustrating for users who didn't want clutter and confusion when viewing Quality Profiles.
After first being reported all the way back in SonarQube Server v6.7 LTS (with the introduction of built-in Quality Profiles), these “zombie” profiles can finally be deleted in SonarQube Server 9.9 LTS.
4. “Acknowledge” Security Hotspots
Security Hotspots highlight a security-sensitive piece of code that a developer needs to review.
In SonarQube Server 8.9 LTS, it only was possible to mark a Hotspot as “Safe” or “Fixed” – and we heard feedback from our users that there was a gap when a developer reviews the security hotspot and a resolution to the highlighted risk is pending.
SonarQube Server 9.9 LTS adds the Acknowledged state to Security Hotspots to tell your team (and your auditors…) that you’ve seen an issue and the fix is pending.
5. Select Reference Branch at scan-time
SonarQube Server 8.9 LTS introduced the Reference Branch New Code Period, where a user can configure their New Code Period to be based on a comparison to an existing branch.
Some users want to set this at the scanner level instead of using the UI/API, and SonarQube Server 9.9 LTS allows this with the sonar.newCode.referenceBranch analysis parameter.
This is particularly useful if you have a specific build for branches targeting a specific release branch, or you have some logic in your pipeline that determines which branch your code will be merged into (based on the branch name, for example).
6. Support of compilation databases for C/C++ analysis
C/C++ analysis requires a lot of precise configuration information to produce an accurate analysis. That’s why, historically, a build wrapped with our “build wrapper” has been necessary to collect all the information about the environment and the commands being sent to the compiler.
This is reliable but comes with trade-offs, like needing to use a tool similar to ccache to perform an incremental build. Sometimes, that’s not an option.
In SonarQube Server 9.9 LTS, it’s possible to pass a compilation database to the scanner instead of wrapping a full build, offering increased flexibility.
Read more about this in the blog post: Compilation database: An alternative way to configure your C or C++ analysis
7. New (and improved) analysis tutorials
SonarQube Server offers in-app tutorials for integrating analysis into your new and existing build pipelines. In SonarQube Server 9.9 LTS there are now new tutorials to cover even more combinations of DevOps Platforms and CI tools, and many updates to existing tutorials.
This includes new and improved tutorials for…
- Bitbucket Pipelines
- GitHub + Azure DevOps
- Jenkins + Bitbucket
- C/C++ analysis across all supported DevOps platforms
- Projects not bound to a specific DevOps platform
This makes it easier than ever to configure analysis without reading through mountains of documentation or having to be a SonarQube Server expert.
8. Reinforcing the security of SonarQube Server
There was a significant effort in SonarQube Server 9.9 LTS to address some security issues based on our own penetration testing, and adding some “nice-to-haves” that users have been requesting to make complying with internal audits easier.
These improvements include:
- Adding the
Content-Security-PolicyHTTP Header - Adding the
Strict-Transport-Security(HSTS) Header when HTTPS is used - Adding
SameSiteandHttpOnlyflags to cookies - Not following redirects when integrating with DevOps Platforms
- Preventing plugins from modifying SonarQube Server’s home directory
- Supporting SAML request signing and assertion encryption
SonarQube Server 9.9 LTS is, without a doubt, the most secure SonarQube Server LTS we've released.
9. Project Move moved to Community Build
The Enterprise and Data Center Editions of SonarQube Server allow users to export and import projects so that they can be moved from one instance to another – we call this Project Move and it is particularly useful when organizations are consolidating many SonarQube Server instances.
Previously, this required that the source and target SonarQube Server instances were running the same version and edition. The edition requirement complicated consolidating many Community/Developer Editions into an Enterprise Edition (or higher) because any Community/Developer Edition instances would need to first be upgraded to Enterprise Edition with a temporary license key.
We’ve made moving projects between SonarQube Server instances easier in SonarQube Server 9.9 LTS by allowing project export from any edition (the version requirement remains)!
Project Import remains a feature of Enterprise and Data Center Edition.
Just an upgrade away from it all
If you haven’t tried SonarQube Server 9.9 LTS yet, I hope you now have even more reasons to prepare that upgrade with your team. This is a free version upgrade for all, and you can get the LTS in just a few clicks @ SonarQube Server Downloads.
Need more help getting started? Check the following resources:
- SonarQube Server LTS Upgrade Checklist
- Get help upgrading using the 9.9 LTS Upgrade category of the Sonar Community