TL;DR overview
- When source code is leaked publicly, the primary security concern is exposed secrets: API keys, database credentials, and access tokens committed to the codebase must be rotated immediately, regardless of how the leak occurred.
- A structured incident response for code leaks involves inventorying all secrets in the leaked codebase, revoking and rotating every exposed credential, and auditing access logs for signs that exposed keys were already used.
- Preventing future leaks requires integrating secrets detection into the developer workflow—catching hardcoded credentials in the IDE before they are committed, and enforcing quality gates that block PRs containing secrets.
- SonarQube helps detect a wide range of hardcoded secrets across cloud services and APIs, enabling teams to identify and remediate credential exposure early.
On July 27th 2020 we learned via media coverage that Till Kottmann (@deletescape) was able to access non open-source code from various companies, through several DevOps tools including SonarQube Server. We immediately reacted and tried to understand what happened. After exchanging with Till Kottmann directly, we had the confirmation of our initial intuition: it was possible to access the source code because of the way these specific SonarQube Server instances were configured, not because of a vulnerability in the SonarQube Server product itself.
I would like to clarify this further. SonarQube Server is an on-premise product to analyze code quality and code security. As such, it is designed to sit behind the firewall, within companies’ private environments. Companies may of course decide to expose it outside of their firewall, in which case it requires specific configuration. The impacted instances of SonarQube Server are the ones that are accessible on the web and have not done the extra configuration to prevent unauthenticated access. This is what allowed Till Kottmann to access these instances, and to then collect snapshots of non open-source code.
Till Kottmann also confirmed this on his Twitter channel: https://twitter.com/deletescape/status/1288874392668299264
Our teams at SonarSource fully realize that affected companies were nonetheless caught by surprise on this, and we take it as a responsibility to provide clear guidance on how to secure a SonarQube Server instance (especially so if it is not secured behind a private network/firewall):
- our Installation Security documentation , which guides towards the 'Force user authentication' setting, a key config to consider if you decide to expose your instance to the public web
- our project provisioning documentation , which covers the meaning of a Public VS Private project in SonarQube Server. This is an essential consideration in case of instances opened to the web and allowing anonymous access.
- also relevant (although less directly related) would be our documentation about Delegating Authentication , a typical corporate setup that helps better manage access to internal tools in a more centralized manner
Even though we have confirmed with Till Kottmann that there is no software vulnerability to fix in SonarQube Server itself, we will still be reviewing possible product improvements to better guide our users through the above settings, as they set up and onboard their SonarQube Server installation.
We thank you for your continued trust in our products, and would like to thank Till Kottmann for his collaboration in confirming the root-causes of this incident.
---
Update: The FBI recently issued an alert about this same misconfiguration problem. While this is not a flaw in SonarQube Server itself, we have nonetheless made changes starting from SonarQube Server 8.6 to the default configuration. The use of the default admin/admin credentials is now limited and authenticated access is the default in new instances.