TL;DR overview
- Third-party SonarQube plugins carry inherent risks including security vulnerabilities, compatibility issues with new SonarQube versions, and inconsistent maintenance from community authors.
- Plugins execute within the SonarQube server process and have access to its data and infrastructure, meaning a vulnerable or malicious plugin can compromise the entire analysis platform.
- Sonar cannot guarantee the quality, security, or compatibility of community-developed plugins and recommends evaluating each plugin's maintenance status before installation.
- Organizations should prefer Sonar's built-in language analyzers and features where possible, reserving third-party plugins for use cases where no native alternative exists.
SonarQube Server has always had a rich plugin Marketplace, with much of SonarQube Server's functionality originally delivered as plugins and many additional needs being met by community-maintained plugins. But since October 2019, all SonarSource-provided functionality is bundled with SonarQube Server. That means any plugins you're using today probably come from third parties (unless you're writing your own). If you're using 3rd-party plugins, you're obviously already aware of the benefits. With this blog post, we want to make sure you're also aware of the risks. Because there are risks.
To be clear, we're not aware of any plugins that are crafted with malicious intent, and the vast majority of plugin maintainers undertake the effort in good faith and with a pure will to benefit the community. Let me say that again. We consider the vast majority of plugin maintainers to be good folks providing a valuable service to fill the gaps they see in SonarQube Server's functionality.
That doesn't mean there's not the potential for things to go wrong. In the 8.9 LTS we added some restrictions on what plugins can do in order to limit the risks. But if we closed all the doors, plugins wouldn't be able to accomplish much, so they still have access to a powerful API. And we don't have plans to change that. We don't want to interfere with plugins' ability to deliver value or your ability to use them.
But we do think you should be clear-eyed about using plugins.
Marketplace plugins
So first, let's lift the veil on the Marketplace, SonarQube Server's selective, in-app listing of 3rd-party plugins. Before being added, every plugin in the Marketplace is initially tested by SonarSource for
- basic functionality (Does the server still start up? Does analysis succeed?...)
- acceptable behavior (Are the analysis logs overly chatty? Does it "phone home"? Leave the file systems littered with temp files?...),
- user experience (Are the metrics, interfaces, docs clear and understandable?...).
Once a plugin passes those tests and meets some routine requirements (including being open source) its initial version is in. After that… All that's required for new versions is a passing Quality Gate on SonarQube Cloud and a properly formatted request. We don't audit or vet the source code or the binaries, and there is no guarantee that the code that's published is the code that's distributed in the binary. We rely on maintainers and on your reports to know if plugins start acting badly or stop being compatible with new versions.
So you can look on plugins in the Marketplace as being minimally vetted. But not as being endorsed or supported by SonarSource.
The Marketplace in commercial editions
Maybe it's already obvious at this point why we changed how the Marketplace works in commercial editions starting from 8.9 LTS. Now, instead of being able to install plugins directly in the Marketplace, you only have a list of Marketplace plugins, and notification when updates are available. Each plugin listing includes a link to its homepage, so you should be able to find the binaries easily. But you have to manually download and install the plugins you're interested in.
That's because installing non-SonarSource functionality is inherently risky and we want to make sure you are aware of it when you take that risk. Again, maintainers of Marketplace plugins are good folks providing a valuable service to the community at large for little thanks and less gain. But even the best-intentioned maintainers can make mistakes or overlook changes in the base. At SonarSource we get paid to make sure everything in SonarQube Server works properly. And we still mess up sometimes. Because we're human. Plugin maintainers are human too.
At SonarSource, we stand behind and support the functionality we provide in SonarQube Server. We can't do that for 3rd-party plugins. Which is why we've deliberately added a small barrier to installing them. If you're running a commercial edition, that implies a certain criticality of the service and a business reliance on SonarQube Server's dependability and security. So we feel a responsibility to make you very aware of it when you do something that could potentially jeopardize that reliability.
This isn't quite a case of "warranty void if seal broken" but if you have problems, one of the first things we'll do is ask you to remove all plugins (Marketplace or not). You'd be amazed at how many times that fixes a "broken" SonarQube Server instance.
Non-marketplace plugins
For plugins distributed outside the Marketplace, all bets are off, and we have seen cases where seemingly innocuous non-Marketplace plugins broke built-in functionality. So you should be more cautious with non-Marketplace plugins, and especially cautious when plugin installation requires anything outside the normal installation steps, i.e.: drop the plugin in the right directory, remove any old versions, and restart your server. Plugins already have access to a powerful, full-featured API, so anything that requires extra installation steps (generally to grab even more access) is suspect by default.
We made changes in the 8.9 LTS to limit plugins' ability to commandeer access to functionality they shouldn't have. But if you choose to sidestep the guardrails by following unusual installation instructions then you should be very aware that you may be giving more access to your system resources than you intended. The community branch plugin is an example of this. Its installation instructions have you change how the SonarQube Server JVM is configured. You end up overriding all the limitations SonarQube Server has placed on plugins to give the plugin access to everything SonarQube Server has access to.
Another thing to be aware of (beware of?) is plugins that elevate user privileges, such as BiteGarden's Universal Plugin Manager. In essence, it gives file system access to users who didn't have it before the plugin manager was installed.
Wrapping it up
So to sum up:
- Plugins are a valuable part of the SonarQube Server ecosystem. Plugin maintainers are good folks who are motivated to extend SonarQube Server's functionality for themselves and their peers. They perform a valuable, but thankless service for the community.
- SonarQube Server exposes a powerful API that gives plugins broad access to its internals. Thus there is an inherent risk in installing a plugin.
- Plugins that are in the Marketplace have undergone minimal acceptability testing before being added to the Marketplace, but they aren't monitored on an ongoing basis.
- All bets are off for plugins outside the Marketplace and especially so for plugins with unusual installation steps. They can considerably increase the risk to your delivery pipeline.
If you're currently using plugins in your SonarQube Server instance, now might be a good time to run an audit and make sure you still really need each one. As BiteGarden itself put it:
We couldn't have said it better.