Catching issues with connected mode in SonarQube for IDE
SonarQube for IDE is your first line of defense in keeping your code clean. Connected mode binds your SonarQube Cloud project to a local project so that SonarQube for IDE can catch issues immediately, right in the IDE, before you even commit them.
SonarQube for IDE is a free IDE extension that integrates with SonarQube (Server, Cloud) using connected mode. Like a spell checker, SonarQube for IDE highlights issues as you type. When an issue is identified, SonarQube for IDE provides you with clear remediation guidance so you can fix it before the code is even committed. In many cases, it also provides a quick fix that can automatically fix the issue for you.
Supported IDEs
SonarQube for IDE integrates with most JetBrains IDEs including IntelliJ IDEA, CLion, GoLand, WebStorm, PHPStorm, PyCharm, Rider, Android Studio & RubyMine.
- Feature overview
- Installation instructions
- Supported Rules and languages
- Connected Mode setup and list of Connected Mode benefits.
- Download
SonarQube for IDE provides Visual Studio developers with a comprehensive in-IDE solution for improving the quality and security of the code they deliver.
- Feature overview
- Installation instructions
- Supported Rules and languages
- Connected Mode setup and list of Connected Mode benefits.
- Downloads for:
SonarQube for VS Code will automatically identify and fix quality and security issues as you code with enhanced linting capabilities directly in your VS Code IDE.
- Feature overview
- Installation instructions
- Supported Rules and languages
- Connected Mode setup and list of Connected Mode benefits.
- Download
SonarQube for Eclipse will automatically identify and fix quality and security issues as you code with enhanced linting capabilities right in your Eclipse IDE.
- Feature overview
- Installation instructions
- Supported Rules and languages
- Connected Mode setup and list of Connected Mode benefits.
- Download
The supported languages vary by IDE. Check the Rules page for your IDE to learn which languages are supported out-of-the-box and which require the use of connected mode.
Though SonarQube for IDE can run local analyses in standalone mode, we highly recommend that you set up connected mode with SonarQube (Server, Cloud) or SonarQube Community Build. Running SonarQube Cloud and SonarQube for IDE in connected mode provides additional valuable features.
Connected mode benefits
- Combining SonarQube for IDE-supported rules with those supported by SonarQube Cloud allows you to analyze more languages and detect more issues.
- Highlight advanced issues (in the IDE) like injection vulnerabilities, detected by SonarQube Cloud.
- Use the same quality profile locally as is defined on SonarQube Cloud.
- Apply settings, such as rule selection and file exclusion defined on SonarQube Cloud, to your local analysis.
- Define specific analysis parameters on SonarQube Cloud, and have those parameters applied locally.
- Automatically suppress issues that are marked as Accepted or False Positive on SonarQube Cloud so that locally reported issues match those found on the server.
- Use the SonarQube for IDE focus on new code features to concentrate detection of issues only in new code.
- Changes in your SonarQube Cloud quality gate will arrive in your IDE when you accept Smart notifications.
Using the Open in IDE feature
If you’re using SonarQube for IntelliJ, Visual Studio, VS Code, or Eclipse, the Open in IDE button can be used to open most all issues in the code editor, speeding up the time it takes to find and fix your issue. Simply click the Open in IDE button from SonarQube Cloud to view it in your IDE; you’ll be prompted to set up connected mode if the project is not already bound.
Opening Security hotspots using the Open in IDE feature is available for all of the SonarQube IDEs. See Opening issues in your IDE for more details.
Reviewing issues in your IDE
Seeing an issue directly in the IDE can help you better understand its context. This is the purpose of the Open in IDE button that you'll see as an authenticated user.
This feature is available if you're using a compatible version and flavor of SonarQube for IDE. The project must be open in the appropriate IDE and bound to the server through connected mode. To learn more about managing issues locally, please check the SonarQube for IDE documentation for your IDE:
Simply open a file of a supported language and start coding, and you will start seeing issues highlighted in your code. For example, here is SonarQube for VSCode:

Keep in mind that the revision or branch analyzed by SonarQube (Server, Cloud) may not be the same as what you have opened in the IDE. In this case, SonarQube for IDE will do its best to locate the issue in your local code.
Injection vulnerabilities
Injection vulnerabilities are also known as injection flaws or taint vulnerabilities; the names are often used interchangeably (ie: injection flaws, injection vulnerabilities, and taint vulnerabilities). They are issues raised by specific security-related rules in SonarQube Server and SonarQube Cloud and remain a top concern. Common types include SQL Injection, Deserialization, and Command Injection vulnerabilities.
Injection vulnerabilities are unique issues because of how data and information flow within your application. This flow becomes a problem when a user controls the data input into the application (source), and that data is not validated or sanitized before it is used by sensitive functions (sink). This lack of validation or sanitization is what allows a potential attacker to manipulate the data flow for malicious purposes.
Because injection vulnerabilities (i.e., taint vulnerabilities) often involve code in multiple files and functions, SonarQube for IDE can only raise them after a full project analysis. This is why taint vulnerabilities are pulled from SonarQube Server or SonarQube Cloud after a project analysis.
You can find the definition of injection vulnerabilities in the SonarQube Server and SonarQube Cloud glossary.
Currently, as analyzed by SonarQube Cloud, injection vulnerabilities are only pulled from the project's main branch.
Issue types (bug, vulnerability, and code smell) were deprecated in late 2023. Issues are now tied to Clean Code attributes and software qualities impacted. See Clean Code for more details.
Smart notifications
Connected mode allows SonarQube (Server, Cloud) to send smart alerts to individuals or teams when new issues are discovered. With everyone in the loop, issues can be addressed promptly, improving the overall software quality and delivery. You'll receive smart notifications in your IDE when:
- the quality gate status of a project open in your IDE changes
- a SonarQube (Server, Cloud) analysis raises new issues that you've introduced in a project open in your IDE
Each developer must individually activate or deactivate SonarQube for IDE smart notifications directly in SonarQube for IDE on the IDE side. When setting up connected mode for the first time, there's a box to check to decide whether or not you want to receive Smart Notifications from SonarQube Cloud in your IDE.
For all the details about managing notifications, check the SonarQube for IDE documentation that matches your IDE:
- Notifications in SonarQube for IntelliJ
- Notifications in SonarQube for Visual Studio
- Notifications in SonarQube for VS Code
- Notifications in SonarQube for Eclipse
Troubleshooting unexpected analysis results
Unexpected analysis results
Observing different analysis results between SonarQube (Server, Cloud) and SonarQube for IDE can have different causes.
Some issues might be detected by a third-party
Due to extensive resource requirements, injection vulnerability and some advanced bug detection rules are ignored by SonarQube for IDE. Please check the analyzer (PMD, Checkstyle, ESLint, PyLint, …). SonarQube for IDE will only run rules from SonarSource analyzers including custom rules extending SonarSource analyzers. Third-party analyzers usually have their own IDE integration, so we have no plan to run them in SonarQube for IDE.
Your test files might be mistaken as source files
Test files can be defined on the server or in the IDE, and when running in connected mode, these test sources will be used by SonarQube for IDE. Each SonarQube for IDE flavor has its own way of detecting which file is considered a test file; in SonarQube for IntelliJ, you must define your test files as a Test Sources Root. To define test files on the server, please see the Analysis scope page to set the scope of your analysis.
Some complex rules are not run in SonarQube for IDE
Due to extensive resource requirements, injection vulnerabilities and some advanced bug detection rules are ignored by SonarQube for IDE. Please check the SonarQube for IDE roadmap for a list of features and enhancements on the horizon.
Only line-level issues are reported
Some rules are able to report issues at the project level. Such issues are not displayed in SonarQube Server for IDE, only in SonarQube Server; see the Security-related rules page for more details.
When analyzing Java files, the analyzer might need some context for some issues to be found
In IntelliJ, there is no incremental compilation of the .class files found in the compiler output folder; these are only produced or refreshed when the project is built. The workaround is to simply build your project with the green hammer (when using SonarQube for IntelliJ) in the top-right toolbar. The project should be built on a regular basis to keep the compiled files up-to-date and overcome this known limitation.
Was this page helpful?