What’s new

When we originally released Scoped Organization Tokens (SOT), they only covered authentication for performing analysis. Any workflow beyond running a scan required a personal access token or a broader administrative credential. This release removes that limitation. Now tools like compliance dashboards, reporting pipelines, CI/CD provisioning scripts, and project governance workflows that need an API credential can be authenticated with an SOT.

SOT now supports the authentication needed to automate building internal dashboards and reporting pipelines: project search, analysis history, issue search, branch and pull request listings, component navigation, measures, quality gate status, and metrics. For projects SOT also now supports project creation, tagging, browse, and admin actions so organizations can automate project provisioning and attribution end to end without granting broader administrative rights than the task requires. For teams running CI/CD pipelines on Azure DevOps, SOT now supports Azure service connections, extending token coverage across more of your toolchain.

Administrators select the allowable permissions for a given token. A token built for a reporting dashboard can be granted different permissions than one built for project provisioning. SonarQube documentation lists exactly what is supported today, and that list will grow as more use cases are addressed.

Large compliance-driven enterprises needed a credential model that satisfied audit requirements. Security and platform teams needed one token model to replace a growing sprawl of personal access tokens across automation, reporting, and administrative workflows. The result is a token model built for how enterprises actually operate.

For more details read our Community post.

R is where regulated enterprises run their statistics: clinical trial analysis, actuarial modeling, risk models, and R&D data science. That code informs regulatory decisions. SonarQube Cloud now analyzes it natively.

R is written by data scientists and researchers often outside the engineering org that uses SonarQube today to verify other coding languages like Java. As R code moves into production applications and regulatory submissions, it carries production risk. SonarQube gives platform engineering and security teams the same coverage details for R in the developer workflow that they already have for Java, Python, and C#, enforced automatically through quality gates in the CI pipeline rather than through manual review.

What's included

• Analysis of R source files and embedded R code in R Markdown files
• 82 rules, covering key sections of lintr's rule set, plus additional Sonar-authored rules
• Code metrics, syntax highlighting, copy-paste detection, and secrets scanning
• Import of lintr problem reports and Cobertura test coverage reports
• Full integration with quality profiles, quality gates, PR decoration, and branch analysis

Getting started

R analysis follows the same setup as any other language in SonarQube: connect your CI pipeline, select a quality profile, and set a quality gate. For large or unfamiliar R codebases, start with a reduced quality profile before rolling out the full 82-rule set.

Read more in our Community post.

Automatic analysis for GitLab repositories provides effortless, zero-configuration code verification, eliminating the need to manage CI pipelines.

• Rapid feedback: Your project is evaluated immediately upon import, providing instant insights into code quality and code security.
• Always-on verification: Once enabled, analysis occurs automatically with every push to your default branch and on every pull request, keeping your code consistently secure.

For details on connecting your GitLab repositories, please refer to our how-to guide and the Community post.

SonarQube Cloud now supports four new programming languages: MuleSoft DataWeave, Gosu, Groovy, and PowerShell. Each verified with the same deterministic analysis applied across the other 40+ languages in SonarQube, catching bugs, security vulnerabilities, and maintainability issues before they reach production.

What's changing

• MuleSoft DataWeave: Analysis reads your MuleSoft DataWeave configuration files and flows, so integration issues surface before a flawed flow takes down the systems it connects.
• Gosu: Coverage extends to insurance and enterprise systems, including Guidewire, closing a longstanding gap in policy, billing, and claims logic.
• Groovy: Analysis covers, web development, rapid prototyping, and metaprograming, and even the recently popular Jenkins pipeline definitions, Gradle build scripts, so a broken script does not stall your pipeline.
• PowerShell: Detection targets the failures that cause real incidents: unsafe type handling, hardcoded credentials, injection risks, and unsafe command execution.

How it works

No extra plugins. No manual programming language configuration. Your next scan detects files in all four languages and analyzes them alongside your existing code, with results in the same dashboards and pull request checks you already use. All four are supported in GitHub, GitLab, BitBucket, and Azure DevOps.

The code verification standard does not change based on who, or what, wrote the code. AI-generated and AI-generated code meet the same deterministic bar, so you catch issues before they compound.

Get started: Connect a repository and run your first analysis, or rerun an analysis on an existing repository connected to SonarQube Cloud to start verifying these new languages.

Read more details in the blog post.

Atlassian is retiring the Connect platform that the current SonarQube Cloud app for Bitbucket Cloud is built on. We have released a replacement app built on Atlassian's Forge platform, live now on the Atlassian Marketplace with full feature parity.

If your SonarQube Cloud organization is bound to Bitbucket Cloud, an organization admin needs to switch to the new app before 30 November 2026. This is an Atlassian platform change, not a change to SonarQube Cloud - it affects every third-party app still built on Connect.

What you need to do

• A full step by step guide can be found in the docs. It should take an estimated 5 minutes.
• Top level overview:
  • Install the new SonarQube Cloud app for Bitbucket Cloud from the Atlassian Marketplace.
  • In your Bitbucket workspace, go to Forge Apps → SonarQube Cloud. 
  • Select the SonarQube Cloud organization to reconnect, and confirm.
  • Once the new app is working, remove the old app from Apps and features → Installed apps → Connect apps.

For additional information and to ask questions, please see this Community post.

SonarQube Cloud Enterprise now gives administrators opt-in controls to lock down organization creation and enforce strict SSO identity paths for verified corporate domains. This builds on the Domain Verification and the Breakglass Mechanism controls already available.

What's new:

• Centralized organization governance: Block any user authenticating via your Enterprise SSO - or matching a verified corporate domain - from creating SonarQube Cloud organizations outside your Enterprise.
• Strict SSO identity enforcement: Once activated, block logins and Personal Access Token (PAT) usage via parallel DevOps accounts (e.g., independent GitHub or GitLab authentication) for users on your verified domains, routing all access through your SSO Identity Provider.
• Opt-in per verified domain: Turn these policies on only when you're ready, domain by domain.

Where to find it: 

Go to Administration > Authentication / SSO in your organization settings, complete the Domain Verification step if you haven't already, then toggle on the new governance and SSO enforcement controls.

For more details, see the documentation and the Community post.