Editor's Note: this post now contains outdated information. You can find more information on SonarQube Server here.
TL;DR overview
- SonarQube provides granular project-level access control, allowing organizations to restrict visibility, analysis permissions, and quality gate management to appropriate team members based on role.
- Configuring access correctly is a security prerequisite: overly permissive project settings can expose sensitive code analysis findings—including vulnerability details—to users who should not have access to that information.
- SonarQube supports both organization-level permission templates and project-specific overrides, enabling centralized governance while allowing project teams to customize access within defined bounds.
- Teams migrating to SonarQube or onboarding new projects should review their default permission templates to ensure analysis results are visible only to authorized personnel and that scan authentication uses scoped tokens with minimal privileges.
When used out-of-the-box, Sonar is a code quality radiator accessible by everyone at anytime. Like for JIRA, Hudson, a post-it dashboard or any other piece of the development toolset transparency is a key success factor for adoption. So, by default in Sonar, anyone can access any project under continuous inspection and navigate through it.
But of course, there are situations where securing Sonar is necessary. Let's imagine for 2 minutes a consulting company that does development for customers and wishes to allow those customers to follow their own projects in Sonar. Since the company has many customers, it is necessary that group of projects can be isolated to make sure each customer only has access to his own projects. Prior to Sonar 1.12, this was only possible by having one instance of Sonar per customer.
Since Sonar 1.12 there are services available in the web interface to handle this and to cover the following use cases :
- Secure a Sonar instance by forcing login prior to access to any page
- Make a given project non accessible to anonymous
- Allow access to source code (Code Viewer) to a given set of people
- Restrict access to a project to a given group of people
- Define who can administer a project (setting exclusion patterns, tunning plugins configuration for that project, ...)
- Define who can administer a Sonar instance
All those use cases can be implemented through the Sonar web interface and will take effect immediately. The way security is handled in Sonar is pretty classic as the security policy is based on the following three concepts : user, group and role (global or by project). Let's take the example of the "Project roles" page available at project level:
(sonar-project-roles)
Three roles are available at project level : Administrator, User and Code Viewer. Users and/or a groups of users can be associated to each of those roles to get the required permissions.
User and group can be first created through the "Users" and "Groups" services available in the administration configuration section. Here is the screenshot of the "Groups" service :
(Sonar-groups)
That was authorization, let's now talk about authentication. By default, user authentication is done against the Sonar DB (user table) but an external authentication engine can also used : OpenLDAP, Microsoft Active Directory, Apache DS, Atlassian Crowd ... Three identity plugins already exist : two open source LDAP Plugin, Crowd plugin and a commercial one Identity Plugin. They all use the public Sonar authentication extension point.
To conclude, it is possible since Sonar 1.12 to easily implement a robust enterprise security policy. Those new functionality have been done with no impact whatsoever on Sonar users who do not want to activate security and want to keep full transparency.