Sonar Blog

The next State of Code developer survey is open

Anirban Chatterjee — Tue, 08 Sep 2026 13:00:00 GMT

We're opening the call for responses for our next State of Code developer survey, and we want to hear from you.

Last year, more than 1,100 professionals told us what AI coding actually looks like day to day. Your answers surfaced findings that shaped an industry conversation: 42% of committed code was AI-generated, only 48% of software developers always verified AI output before committing, and reviewing AI code often took more effort than reviewing a colleague's. That data exposed important trends. This round goes deeper.

What this survey is about

The next Developer Survey will explore harder questions about what happens to all that AI code once it's written.

Agents have changed the shape of work since our last survey. More code arrives in every pull request, more of it arrives at once, and the review step is under pressure it wasn't designed for. We want the ground truth from the people living it.

Questions we're asking

This round focuses on what happens after code gets written. We're exploring topics like

What percentage of AI-authored changes reach production with no separate human review at all?
When AI reviews AI, is the same model that wrote the code grading its own work?
How has the split between writing and reviewing shifted since agents arrived?
Are the productivity gains still climbing, or have they quietly plateaued?

Together, these questions tell us whether verification is keeping pace with generation, or falling behind it.

Add your data to the record

It only takes about 20 minutes to contribute. Your insights will help us build the next State of Code report, intended to provide a data-driven compass for developers navigating AI adoption.

At Sonar, we believe all code should meet the same quality and security standards, whether written by human or agent. Understanding real-world practices helps us see how these standards can remain effective as AI writes more and more code.

Take the survey

Thanks for helping us define the real state of code!

Four new languages arrive in SonarQube Cloud: MuleSoft DataWeave, Gosu, Groovy, and PowerShell

Robert Curlee — Fri, 04 Sep 2026 13:00:00 GMT

Some of the most critical code in your stack has either run without independent verification for years or you’re using separate tooling than SonarQube to analyze that code. Integration flows move data between your systems. Gosu drives policy and claims logic. Recently, Groovy has become popular for defining how your software gets built in Gradle build files, Jenkinsfiles, and Groovy scripts. PowerShell provisions the infrastructure everything else depends on. When any of it fails, the blast radius reaches production, yet most of it has sat outside the reach of SonarQube’s automated code verification that developers of mainstream languages take for granted.

Integration flows, insurance logic, build scripts, and infrastructure automation deserve the same scrutiny as the application code they support. SonarQube Cloud adds support for MuleSoft DataWeave, Gosu, Groovy, and PowerShell, extending deterministic analysis to four ecosystems that run business-critical logic. Combined with the other 40+ programming languages SonarQube already supports including Java, JavaScript, TypeScript, Python, and C#, you get one unified code verification layer, from your APIs to your build pipelines to the scripts that run your cloud.

Here is what each new language brings, why it matters, and how to start.

MuleSoft DataWeave: verify the integration code your enterprise runs on

Integration code is the connective tissue of your enterprise. It moves data between systems, exposes APIs, and orchestrates the workflows your business depends on. When that code fails, the outage cascades across everything downstream. Until now, MuleSoft DataWeave development lacked the independent verification layer other languages take for granted. With only a community supported plug-in, previous support didn’t have the native depth and cloud support that developers have been asking for.

What SonarQube Cloud analyzes. SonarQube Cloud inspects your MuleSoft DataWeave applications for bugs, security vulnerabilities, and maintainability issues. The analysis reads your MuleSoft DataWeave files and flows, then applies deterministic rules to surface problems the eye misses. Every issue comes with a clear explanation and a path to a fix.

Why it matters. AI agents write more integration code, and they write it fast. A single flawed integration flow can take down the systems it connects. SonarQube is the verification layer that checks MuleSoft DataWeave code against your functional, security, and maintainability standards before it ships, so your developers catch issues in the pull request, not on a 2 a.m. incident call.

Gosu: close a longstanding coverage gap for insurance systems

Gosu code has run critical insurance and enterprise systems for years, often without the verification coverage mainstream languages receive. Gosu is a statically typed language on the JVM, used most notably behind Guidewire's platform for policy, billing, and claims management. That business-critical logic has sat outside most quality tooling or lacked up-to-date changes in the community plugin, until now.

What SonarQube Cloud analyzes. SonarQube Cloud analyzes Gosu source code the same way it verifies every other language: deterministically, transparently, and consistently. Coverage spans the checks that matter most:

Bugs: catch logic errors and reliability problems before they reach production.
Vulnerabilities: identify security weaknesses attackers could exploit.
Maintainability issues: flag the problems that accumulate into technical debt.

Every finding includes a clear explanation of the problem and guidance on how to fix it. No guesswork, no opaque scoring.

Why it matters. In insurance systems, a single reliability bug carries financial and regulatory consequences. SonarQube applies the same deterministic standard to Gosu that it applies to Java, Python, and C#, so AI-generated and hand-written Gosu code meet identical quality and security thresholds. Teams running Guidewire and other Gosu-based platforms gain audit-ready evidence that the code meets standard, and developers get faster, clearer feedback inside their existing pull request workflow.

Groovy: verify the code that runs your pipelines

Groovy runs deeper in your infrastructure than most teams realize. Not only is it used for web development, rapid prototyping, and metaprograming, it is also heavily used to define Jenkins pipelines, power Gradle build scripts, and glues together automation across the JVM ecosystem. When that code fails, your delivery pipeline fails with it. Yet these uses of Groovy have long sat outside the reach of automated verification, a blind spot in workflows that demand consistency everywhere else.

What SonarQube Cloud analyzes. SonarQube Cloud analyzes Groovy against a dedicated rule set built to catch the issues that matter most: bugs, vulnerabilities, and maintainability problems. Coverage includes the Groovy you actually write:

Jenkins pipeline definitions
Gradle build scripts
Standalone Groovy applications

The analysis is deterministic. Every scan applies the same rules and returns the same verdict, and SonarQube flags issues directly in your pull requests, so problems surface before they merge, not after they break a build.

Why it matters. Unverified Groovy can be unverified infrastructure. A broken Jenkins pipeline or a flawed Gradle script does not just introduce a bug. It stalls every deployment that depends on it. Agents now generate Groovy alongside everything else, and that code can look correct while hiding defects that only surface at runtime. Deterministic analysis catches the complex mistakes that LLM self-review misses, so you verify the code that runs your pipelines and keep delivery moving.

PowerShell: hold your infrastructure scripts to one standard

PowerShell sits at the control layer of modern infrastructure. It provisions cloud resources, automates deployments, and orchestrates critical operations across your environment. When a PowerShell script fails silently, the blast radius is your production systems. These scripts often skip the review rigor applied to application code, which leaves a gap in your risk posture, and AI widened it.

What SonarQube Cloud analyzes. SonarQube Cloud analyzes PowerShell for bugs, security vulnerabilities, and maintainability issues. The analysis is deterministic, catching the concrete, hard-to-find mistakes a language model reviewing its own output misses. Coverage targets the problems that cause real incidents:

Bugs that break automation at runtime: incorrect logic, unsafe type handling, and control-flow errors that pass review but fail in production.
Security vulnerabilities including hardcoded credentials, injection risks, and unsafe command execution that expose your infrastructure.
Maintainability issues like dead code, needless complexity, and inconsistent patterns that accumulate over time.

Every issue comes with a clear explanation and a path to a fix. Your team learns why a rule fired, not just that it did.

Why it matters. A flawed script does not just fail. It can misconfigure a cloud environment, expose a secret, or take down a service. SonarQube Cloud is the independent verification layer for your PowerShell, applying multilayered, deterministic analysis to every script. Your team ships automation faster, and your engineering org governs it with confidence.

How does SonarQube Cloud analyze all supported languages automatically?

All four languages are available now and join the more than 40+ programming languages SonarQube Cloud already supports in GitHub, GitLab, BitBucket, and Azure DevOps repositories. SonarQube Cloud activates automatically across MuleSoft DataWeave, Gosu, Groovy, and PowerShell projects with no extra plugins, no manual language configuration, no separate setup required. Your next scan picks up the new languages alongside your existing ones and surfaces results in the same dashboards and pull request checks you use today.

Open your SonarQube Cloud project, connect a repository, and run your first analysis today.

The context tax: why your coding agent reads the same 600 lines 400 times

Antonio Aversa — Tue, 01 Sep 2026 13:00:00 GMT

When a coding agent works in a codebase that doesn't fit in its context window, it navigates the only way a shell can: grep, then read a file, then read a bigger slice of the file.

Every one of those reads stays in the conversation and is re-billed on every later turn.
On one ordinary ~800-line pull request in our own codebase, that added up to 156 million context tokens and a context window that peaked at 459k tokens, for a change whose final diff a person could read in five minutes.

Sonar Vortex is our enterprise harness for AI coding agents, guiding them with the right context and verifying every change in real time. To provide guidance, it works inside the agent's loop and answers navigation questions from a graph of your codebase instead of from raw file reads. That graph is built by SemSitter™, our in-house semantic navigation engine, which keeps a local Unified Dependency Graph (UDG) of the repository updated instantly on every change.

Instead of grep, then a slice, then a wider slice, the agent queries the graph for a specific node and gets back that node plus its typed relationships.
The measurable effects are less context carried per task, fewer round-trips, and, in a repository larger than the window, call sites a regex would not have matched.

The story of a refactor that shouldn't have hurt

We build SemSitter with coding agents: that makes it a great candidate to show how agentic navigation capabilities can make the difference. A recent PR taught SemSitter's Python analyzer to do call-site resolution, that is, for a method call, record which type owns the method and what the call returns. The C# analyzer already did this, so the job was to mirror it in Python.

Well into the change, the agent had to work with this line of SemSitter's own code:

let return_type = ctx.method_index.resolve_return_type(owner, method_name);

To touch it safely, the agent needed the answer to the most ordinary question in programming, the one your IDE's "Go to Definition" gives you for free: for the call ctx.method_index.resolve_return_type(...), what type is ctx.method_index, where is resolve_return_type defined, and what does it return? The honest answers: ctx.method_index is a MethodIndex, the method lives in method_index.rs, and it returns Option<&str>.

The agent had no index of its own. So it did what a shell allows:

grep -rn "resolve_return_type", and got back a definition in every backend at once: Python, TypeScript, Java, Rust, C#, and a shared core. The regex cannot say which one this call binds to.
Open method_index.rs to read the definition. It doesn't know where the function starts or ends, so it reads a generous slice, or the whole file.
The return type is produced by a helper, extract_type_name. Grep for that, open that file, read another wide slice.
Is ctx.method_index really a MethodIndex? Grep for the field, open the struct, repeat.

Each of those reads is now permanently in the conversation, and you are going to pay for it, over and over again, until the conversation is over.

There is a small irony here worth stating plainly: the agent was building the exact capability it was missing. Call-site resolution is "given this call, hand me its owner type and return type." The agent needed precisely that to navigate the code, and, lacking it, fell back to grep and whole-file reads.

What it actually cost us (with real numbers)

While building SemSitter with coding agents, we keep the full traces. So we can measure the tax precisely.

Here's one pull request from the SemSitter repo, a backend change of about 800 lines that added call-site resolution (more on that below):

Metric (one PR, measured)	Value
Model round-trips in the session	512
Context window at its peak	458,700 tokens
Fresh input tokens	106k
Cache-read tokens (the re-billed transcript)	152.8 million
Cache-write tokens	3.1 million
Output tokens	289k
Total context tokens billed	≈ 156 million
Approx. cost of the session	≈ $41

The line that matters is cache-read: 152.8 million tokens. Here's why it's so large.

The mechanism: context is a tax you pay every turn

A coding agent doesn't read a file once. On every new step, the model is re-sent the entire conversation so far as input. Prompt caching makes those repeated tokens cheap per unit (≈10% of the input price), but you still pay for them on every single turn. So the true cost of a token isn't its size. It's its size times the number of turns it survives.

Read a 600-line file on turn 40 of a 512-turn session and you haven't paid for 600 lines. You've paid for 600 lines × ~470 more turns.

Context size per model round-trip, measured from the real session. It only grows: every file read and tool result stays in, and is re-sent, until the run ends or the window is compacted.

One over-read, traced end to end

Early in that PR, the agent needed to understand one helper: a ~67-line function that, given a value, works out its type name. To find it, the agent read the whole 618-line file (6,472 tokens) instead of the 67 lines it used (~700 tokens).

Wasted immediately: ~5,770 tokens.
That read entered the conversation around turn 42 and stayed for the remaining 470 turns.
Re-billed as a cache read each turn: 5,770 × 470 ≈ 2.7 million tokens of pure waste.
At current cache-read pricing (~$0.20 / million), that's ≈ $0.54, for one unnecessary file read.

Fifty-four cents sounds trivial. But this PR did that ~10 times, plus dozens of blind tree-wide greps, several of which returned nothing and forced a second, wider grep. Add it up and the avoidable navigation overhead alone runs into several dollars on a single $41 PR, and it scales with the size of the repo, not the size of your change.

And this is not one unlucky PR

Across 18 comparable single-ticket PRs in the same repo, the average was:

~234 million context tokens per PR
~$65 per PR (median ~$52)
~700 model round-trips per PR
context windows routinely peaking between 450k and 975k tokens, brushing the 1M ceiling, at which point the agent is forced to compact and lose earlier context entirely.

Context tokens billed to complete each of 18 comparable PRs in the same repository. The spread is wide because it tracks how much of the codebase the agent had to traverse, not how large the final diff was.

That last point is the second, quieter failure mode. In a repo too big for the window, grep doesn't just cost tokens. It misses. A regex finds the strings you thought to search for, not the call that reaches your function through an interface, an alias, or another programming language. Missed call sites become failed builds, another round-trip to CI, and more rework, each with its own fresh context tax.

What SemSitter in Sonar Vortex does instead

This is what Sonar Vortex does instead, using SemSitter, the navigation engine underneath it. SemSitter builds a Unified Dependency Graph (UDG) of the codebase: every function, method, class, field and parameter is a node, and the relationships between them are typed edges: calls, references, returns, has-param, is-type, contains, extends. How we build that graph accurately, across languages, leveraging parallelism and incrementality while scaling to millions of nodes, is the interesting part we keep under the hood.

The point for the agent is simple. It no longer asks the filesystem "which files mention resolve_return_type?" It asks the graph a precise, semantic question:

"Give me the definition of resolve_return_type that this call binds to, the type that owns it, its return type, and its callers."

and gets back exactly that: the one method body, plus the edges that answer the rest, with no surrounding file, no six-way grep, and nothing to widen.

That is, in fact, the feature the PR was building. For the call ctx.method_index.resolve_return_type(...), the graph records which type owns the method (a references edge from emit_call to MethodIndex, because ctx.method_index is a MethodIndex) and what it returns (resolve_return_type carries a returns edge to Option<&str>). The agent gets "where is this defined, on what type, and what comes back?" as data, not as a page of text it has to read and then carry forever.

The graph the agent navigates

The subgraph SemSitter returns for the call ctx.method_index.resolve_return_type(...). Blue nodes are code, green is documentation, orange is code in another language.

When the agent touches resolve_return_type, the graph hands it the small, exact neighborhood shown above. Compare the two ways of answering the same three questions:

Question	grep + read	SemSitter (graph)
Which `resolve_return_type` does this call bind to?	grep returns one per backend; open files to guess	one `references` edge → the Python `MethodIndex`
What does it return?	read the file until the signature is in view	one `returns` edge → `Option<&str>`
Who calls it, and on what type?	grep again, per file, hope the regex matched	upstream `calls` + owner `references` edges, complete
Tokens dragged through the rest of the chat	thousands, per file, × every later turn	the one method body, once

Same answers. One is a page of text you re-pay for on every turn and that still misses the indirect callers. The other is a handful of typed edges that are complete by construction.

The single over-read from earlier, framed as a lookup. Loading ~9x fewer tokens matters most because of the multiplier: this read survived 470 turns, so grep+read carried ~2.7M extra cache-read tokens versus ~0.33M for the graph lookup.

Why the gains compound: beyond code-to-code

Structural edges (calls, returns, references) are only the first layer. The same graph carries two more kinds of relationship, and each multiplies the savings on exactly the tasks that hurt most today.

Code → text (documented_by). Every code node can be linked to the specific piece of documentation that governs it: the one paragraph of a design doc, the one ADR, the one section of the README. This is the "misleading docs" problem turned on its head. Instead of the agent scraping a wiki and being led astray by a stale page, touching resolve_return_type surfaces the note on how MethodIndex is built from the callees' -> annotations: a few hundred exact tokens instead of a document dump, and the right few hundred.
Text → text. Documentation, tickets and design notes are linked to each other by meaning, so the agent can follow "this rule is refined by that ADR" without a full-text search that returns fifty near-misses.
Code → code, across programming languages. The same idea implemented in two languages can be linked even when the names differ. This PR was mirroring C#'s call-site resolution in Python, and C#'s return-type logic lives in a function called resolve_type_node, not resolve_return_type. A grep for one name will never surface the other. A cross-language rename or contract change, today one of the most token-expensive, error-prone things you can ask an agent to do, because it means grepping several backends in several syntaxes, becomes follow the edge. Both ends arrive in context together, and neither is missed because the other language happened to use a different word.

In the diagram above, those are the green documented_by edge and the dashed semantically_related edge to the C# backend. Each one is a navigation the shell simply cannot make: grep cannot cross from code to prose, and it cannot connect resolve_return_type in the Python backend to resolve_type_node in the C# one. The graph can, and it hands the agent only the node it asked for.

The takeaway

The bottleneck for AI coding agents in real, large codebases isn't reasoning. It's navigation, and navigation-by-grep has two costs that don't show up until you measure:

Token cost. Every blind read is re-billed on every later turn. On one ordinary PR that was 156M context tokens and ~$41; across a batch it averaged ~$65 a PR, with context windows brushing the 1M ceiling.
Correctness cost. grep finds strings, not meaning. What it misses becomes rework and extra trips to CI, each paying the token tax again.

SemSitter, our in-house code navigation engine powering Sonar Vortex, turns navigation from a text search into a graph query. The agent carries the nodes it asked for rather than the files it had to scan, and it can follow relationships across files, docs, and languages that a regex cannot express.

The result is lower context cost per change and fewer call sites missed, and both effects grow with the size of the codebase.

If your agents work in a codebase bigger than their context window, this tax is already on your bill. Sonar Vortex is how you stop paying it.

SonarQube Hunter Agent is now GA: Catch broken access control and business logic flaws

Satinder Khasriya — Thu, 27 Aug 2026 13:00:00 GMT

In 2026, a researcher was paid a $78,000 bug bounty for finding a flaw in Meta's systems: a logged-in user could pull another user's private support tickets and personal data just by changing an identifier in a request. Authentication worked exactly as designed. The system correctly confirmed who the user was—it just never checked whether that user was allowed to see that specific piece of data. SAST wouldn't have caught it, because there was no data flow/injection issue in the code. It ran exactly as written.

This is one of many gaps SonarQube Hunter Agent is built to close, and as of today, it's generally available on SonarQube Cloud. SonarQube Server support is coming soon.

Broken access control has been the OWASP Top 10's #1 web application risk since 2021, and it isn't shrinking: In OWASP's 2025 testing, every single application tested (100%) had some form of broken access control. Researchers found over 1.8 million individual instances of it, spread across 40 different types of access control flaws more than any other risk category in the Top 10. It's also the category security tooling is least equipped to find, and the problem is compounding: AI coding agents now author more than 42% of committed enterprise code, generating access-control logic, permission checks, and business workflows faster than any human review process was built to handle.

Vulnerabilities that SAST tools miss

SonarQube's SAST engine is excellent at what it's designed to do: algorithmic and data-flow analysis that trace tainted input from an untrusted source to a sensitive sink. That's how it catches SQL injection, XSS, path traversal, hardcoded secrets, and hundreds of other vulnerability classes reliably, at scale, on every commit.

But there's a category of vulnerability that sits outside what any SAST can reach, not because of a tooling limitation, but because of the nature of the question itself. Does /invoices/8472 check that the requesting user actually owns invoice 8472, or does it just return whatever record matches the ID? Is a role check enforced only in the UI, and never revalidated server-side? Does completing step 3 of a checkout flow actually require having completed step 2? None of these are syntax problems. They're questions about intent, about what a system is supposed to do, versus what it actually lets you do. And answering them requires reasoning about identity, roles, and workflow logic that a static analyzer has no mechanism to evaluate.

For years, the only way to close that gap was people: senior engineers doing manual code review, external pentest engagements once or twice a year, bug bounty programs, pre-release audits. That model is running out of runway. AppSec talent is scarce, pentests are point-in-time snapshots with long gaps between them, and release velocity, accelerated by AI-generated code has outpaced what manual review can keep up with. The cost of leaving that gap open isn't theoretical: broken access control alone exposed roughly 885 million records at First American, 64 million applicant records at McDonald's, and drained $9 million from Yearn Finance in a single exploit. These are not edge cases but real headlines.

How does Hunter Agent detect logic flaws?

Hunter Agent is an AI security agent, native to SonarQube, that reasons through your codebase the way a human security researcher works through a whitebox audit and confirms every finding before it ever reaches a developer.

It targets three classes of logic-level vulnerability that pattern-based scanning structurally cannot evaluate:

Broken access control: IDOR, missing or incorrect authorization checks, privilege escalation, CSRF, sensitive data exposure
Business logic flaws: skipped workflow steps, abuse of repeatable actions, missing rate limits
Authentication & session management flaws: session fixation, non-expiring sessions, weak password recovery, missing MFA, brute-force gaps

Under the hood, Hunter Agent runs on the harness used by the SWE-bench-leading Sonar Foundation Agent. Rather than issuing a single prompt and taking whatever the model returns, it executes a structured, multi-phase pipeline:

Analyze: runs security playbooks in parallel across chunks of the codebase to surface candidate issues
Explore: maps the structure of the repository and splits it into manageable segments, which is how the agent scales to codebases beyond 10 million lines of code
Validate exploitability: a dedicated subagent takes each candidate finding and actively explores whether a feasible attack path exists, discarding anything it can't substantiate
Synthesize: consolidates validated findings into a single, reported result

From the outside, using it collapses to four steps with effectively zero setup: connect a SonarQube project (nothing to install), the playbook runs the analysis, the validation subagent confirms exploitability, and confirmed findings are raised as SonarQube issues—tagged, triaged, and gated exactly like any other finding your team already reviews. There's no separate portal and no new dashboard.

How reliable are SonarQube Hunter Agent’s findings?

Any sufficiently capable LLM can be prompted to “look for security bugs” in a codebase. The problem is that raw model output on a task like this is neither precise nor stable. Point a generic prompt at the same codebase twice and you can get three findings on one run and 60 on the next. That is a variance that makes the output impossible to build a process around. A security team can't build a triage process around a tool that doesn't agree with itself.

That's the specific problem the exploitability-validation subagent is designed to solve: every candidate finding from the Analyze phase has to survive an independent attempt to demonstrate a feasible attack path before it's allowed to surface. In practice, that pushes average precision to 80–90%, high enough that a finding from Hunter Agent can be treated as a real, actionable signal rather than something to filter through another layer of manual investigation. In internal testing, it has surfaced more than 200 zero-day vulnerabilities across popular, well-audited open source projects.

How do I automatically detect broken access control in source code?

Hunter Agent is designed to add a reasoning layer without adding friction. It can run as a background agent scheduled weekly or monthly against your main branch, or it can be triggered on demand. Findings surface asynchronously as SonarQube issues once they're confirmed, alongside the SAST and SCA findings your team already triages.

That's a deliberate design choice: surfacing both SAST issues and findings from Hunter Agent in the same workflow means you get full-spectrum coverage without forcing a tradeoff between depth and speed. It's language-agnostic across the 40+ programming languages SonarQube already supports, and incremental scanning cuts re-scan time on large repositories by roughly half.

Layered, not just independent

The agent that reviews your code is not the agent or model that wrote it. As more of your codebase is authored by AI coding assistants or agents themselves, a structurally independent verification layer matters: it's the difference between a system checking its own work and a second, differently purposed system checking whether the first one's output actually enforces the rules it was supposed to.

That independence is layered. SAST catches static code flaws, SCA catches vulnerable dependencies, and Hunter Agent adds a third lens, reasoning over code the way a security researcher would and catching logic and behavioral issues the others aren't built to see. Nothing is trusted by default to have caught everything alone, and that's Sonar’s zero-trust, multilayered approach to verification.

Hunter Agent's findings are also auditable: every finding carries the discovery path the agent followed, so a reviewer can see exactly how it got there.

Available today

SonarQube Hunter Agent is generally available now on SonarQube Cloud, for the Enterprise plan. Point it at any existing SonarQube project. There's nothing new to install, no new config needed. Support for SonarQube Server is coming soon.

Logic-level vulnerabilities don't announce themselves in a code review. They announce themselves in a breach report, or in someone else's bug bounty payout. Hunter Agent exists to make sure it's your team that finds them first.

Bring your own hook: a 5-line PostToolUse template calling sonar analyze agentic

Prasenjit Sarkar — Mon, 24 Aug 2026 13:00:00 GMT

sonar integrate claude will set up Sonar Vortex for you. That is the right call for most people. But sometimes you want to own the hook yourself: to scope it to a subset of files, to decide exactly when it blocks, to check it into a repo your teammates share, or just to understand what is running before you trust it. This post is the smallest hook that does the job. Five lines, one command, and your agent starts getting CI-grade feedback on every edit.

One naming note up front. The CLI subcommand is sonar analyze agentic; sonar verify is an alias, and there is no sqaa subcommand (the installed hook is just named sonar-sqaa). As of CLI 0.14.x, sonar analyze has secrets, dependency-risks, and agentic. When in doubt: sonar analyze agentic --help.

What do you need before setting up a Claude Code SonarQube hook?

SonarQube CLI installed and authenticated.
curl -fsSL https://raw.githubusercontent.com/SonarSource/sonarqube-cli/refs/heads/master/user-scripts/install.sh | bash
Then run sonar auth login
Confirm with sonar auth status.
A SonarQube Cloud project with the Vortex entitlement. Vortex is SonarQube Cloud only and is a paid add-on.
One prior CI analysis. The project has to have been analyzed in your CI pipeline on a long-lived branch at least once after Vortex was enabled for the org; without it there is nothing to analyze against.
jq on your PATH. The hook uses it to read Claude Code's event JSON.

Vortex runs server-side over HTTPS against SonarQube Cloud, so you do not need Docker for this CLI path.

The template

Two files. First the hook script.

.claude/hooks/sonar-agentic.sh:

#!/usr/bin/env bash
file=$(jq -r '.tool_input.file_path // empty')                    # 1
[ -f "$file" ] || exit 0                                          # 2
out=$(sonar analyze agentic --depth DEEP --file "$file" --format text); rc=$?  # 3
[ "$rc" -eq 51 ] && { printf '%s\n' "$out" >&2; exit 2; }         # 4
exit 0                                                            # 5

chmod +x .claude/hooks/sonar-agentic.sh

Then wire it to the PostToolUse event for the file-writing tools in .claude/settings.json:

{
    "hooks": {
      "PostToolUse": [
        {
          "matcher": "Edit|Write",
          "hooks": [
            { "type": "command", "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/sonar-agentic.sh", "args": [], "timeout": 120 }
          ]
        }
      ]
    }
  }

Restart Claude Code so it picks up the new hook. That is the whole thing.

How does each line of the sonar analyze agentic hook script work?

The mechanism only works if you understand two contracts: how Claude Code hands you the event, and how it reads your answer.

Claude Code passes the event as JSON on stdin, not as environment variables. There is no $tool_input_file_path. The variables Claude Code does export are path placeholders - $CLAUDE_PROJECT_DIR, $CLAUDE_PLUGIN_ROOT, and $CLAUDE_PLUGIN_DATA — and none of them carry the event; beyond those, hooks simply inherit the parent environment.

So the first thing every hook does is read stdin and parse it.

jq -r '.tool_input.file_path // empty' reads the event JSON from stdin and pulls out the path of the file Claude just wrote. For Edit and Write that field is tool_input.file_path.
[ -f "$file" ] || exit 0 bails out cleanly if there is no real file to look at (also covers the empty-string case). Exit 0 means "no opinion, carry on."
sonar analyze agentic --depth DEEP --file "$file" --format text runs Vortex on just that one file, using the restored CI context. It exits 51 when it reports issues and 0 when the file is clean. We capture both the output and the exit code. The --depth DEEP is not decoration: a single --file defaults to STANDARD depth, and only DEEP turns on cross-file analysis — taint analysis, at present. Only the file you pass is uploaded; SonarQube evaluates it against the project as of your last CI analysis with your modified file substituted in. You can pass several files with repeated --file flags, or use --staged to pick up whatever git has staged.
If the exit code is 51, we print the findings to stderr and exit 2. On a PostToolUse hook, exit 2 does not undo the edit (the tool already ran), but it does feed your stderr back to Claude as feedback. Claude reads the findings, fixes the code, edits again, and the hook fires again. That is the loop.
Otherwise exit 0. Nothing to say.

The choice of exit 2 matters and is easy to get wrong. Per the Claude Code hooks reference, on most events only exit code 2 blocks or feeds back; exit code 1 is treated as a non-blocking error and the turn just continues. And for PostToolUse specifically, plain stdout on exit 0 goes to the debug log, not to the model - though a valid JSON object printed on exit 0 is still parsed, which is the escape hatch used below. So if you want the findings in front of Claude, stderr plus exit 2 is the reliable path.

Why this gives you CI-grade feedback and not lint noise

sonar analyze agentic is not a local linter. It ships the changed file to SonarQube Cloud, which restores the dependency graph, type information, and quality profile from your last CI analysis and runs the same engine your pipeline runs, then returns findings in seconds. That is why, at DEEP depth, it can catch things a single-file tool cannot, like a tainted value flowing from a request parameter into a SQL sink. The exit-51 convention gives you a clean, deterministic signal to branch on, with no output parsing and no LLM judge in the middle deciding whether your code is fine.

How do I handle sonar analyze agentic errors and exit codes in a hook?

The five-liner fails open: any exit code that is not 51 or 0 (an auth failure, a transient server error, a bad flag) falls through to exit 0, and the edit sails past unverified. For a real guardrail, branch on all three cases and decide whether an analysis failure should fail closed:

#!/usr/bin/env bash
file=$(jq -r '.tool_input.file_path // empty')
[ -f "$file" ] || exit 0

# only analyze source you care about
case "$file" in
  *.py|*.js|*.ts|*.tsx|*.java|*.cs|*.cpp) ;;
  *) exit 0 ;;
esac

out=$(sonar analyze agentic --depth DEEP --file "$file" --format text); rc=$?
case "$rc" in
  0)  exit 0 ;;                                                   # clean
  51) printf '%s\n' "$out" >&2; exit 2 ;;                         # issues: feed to Claude, it fixes
  *)  printf 'SonarQube could not analyze %s (exit %s):\n%s\n' "$file" "$rc" "$out" >&2
      exit 2 ;;                                                   # error: surface it, do not pass silently
esac

If you would rather not interrupt the turn and instead attach findings as advisory context, drop the exit 2 and return an additionalContext payload on exit 0 instead:

printf '{"hookSpecificOutput":{"hookEventName":"PostToolUse","additionalContext":%s}}' \
  "$(printf '%s' "$out" | jq -Rs .)"

Both are valid; the difference is whether a finding stops Claude to fix now or just rides along as a note. Note that additionalContext is capped at 10,000 characters; anything longer is written to a file and replaced with a path and a short preview. Check the "JSON output" section of the hooks docs for the exact decision-control fields your Claude Code version supports.

How do I test a Claude Code PostToolUse hook with SonarQube?

Ask Claude to write something obviously unsafe in a file in your project:

Write a Java method that runs "SELECT * FROM users WHERE id = " + userId

Claude writes the file, the PostToolUse hook fires, and Vortex comes back with a SQL injection finding (javasecurity:S3649, the "database queries should not be vulnerable to injection" taint rule). Claude reads it off stderr and offers to switch to a PreparedStatement. If you see that round-trip, your hook is live. You can sanity-check the command on its own too:

sonar analyze agentic --depth DEEP --file src/UserRepo.java --format text; echo "exit: $?"
# exit: 51  when it finds something, 0 when clean

Bonus: a commit gate with the same primitive

Same idea, different event. A PreToolUse hook on Bash can refuse a git commit while blocker-severity issues are open. Note the flags: sonar list issues requires --project, and severity filtering is --severities (plural):

#!/usr/bin/env bash
cmd=$(jq -r '.tool_input.command // empty')
case "$cmd" in
  git\ commit*)
    n=$(sonar list issues --project my-app --branch "$(git branch --show-current)" \
          --severities BLOCKER --format json | jq '.issues | length')
    [ "${n:-0}" -gt 0 ] && { echo "Blocked: $n blocker issue(s) open" >&2; exit 2; } ;;
esac
exit 0

When should I use sonar integrate claude instead of a custom hook?

If you do not need custom scoping or blocking behavior, sonar integrate claude --project <key> installs the Vortex’s PostToolUse hook (plus secrets-scanning hooks) for you and manages the wiring; re-running it refreshes those artifacts, but updating the CLI binary itself is a separate sonar update, keeps the CLI updated, and manages the wiring. Bring your own hook when you want control over which files, when it blocks, and what your team sees in version control. The primitive is identical either way: a deterministic command at a fixed point in the agent's loop.

Tokenomics of quality: switch sonar list issues to --format toon for measured token savings

Prasenjit Sarkar — Mon, 17 Aug 2026 13:00:00 GMT

Your AI coding bill is, increasingly, a data-formatting problem. Every time an agent pulls your open issues, your quality gate status, or your dependency risks into its context window, it pays tokens for the shape of that data as well as the content. Most of that data goes to the agent as JSON, and JSON is verbose. There is a one-flag fix for the most common case, and it costs you nothing but a keystroke.

sonar list issues can emit its results as TOON instead of JSON:

sonar list issues -p my-org_my-app --format toon

This post measures what that swap saves, shows you how to reproduce the measurement on your own data, and puts it in the larger context of where Sonar is already trimming tokens: Sonar Vortex's Context Augmentation on the way in, and cleaner code itself across the whole session.

What is TOON format and how does it work?

TOON (Token-Oriented Object Notation) is a compact, lossless encoding of the JSON data model, designed specifically for LLM input. It combines YAML-style indentation for nested objects with a CSV-style tabular layout for uniform arrays of objects. A list of issues is exactly that: an array of records with the same fields. That is TOON's sweet spot.

Here is the same three-issue result in each format. First the default, --format json:

{
    "issues": [
      { "key": "AZ1002fQ9x", "rule": "javasecurity:S3649", "severity": "BLOCKER", "type": "VULNERABILITY", "component": "my-org_my-app:src/main/java/com/acme/UserRepo.java", "line": 29, "message": "Change this code to not construct SQL queries directly from user-controlled data.", "status": "OPEN", "effort": "5min" },
      { "key": "AZ1007fQ9x", "rule": "java:S2076", "severity": "BLOCKER", "type": "VULNERABILITY", "component": "my-org_my-app:src/main/java/com/acme/AuthFilter.java", "line": 61, "message": "Make sure that constructing this OS command is safe here.", "status": "OPEN", "effort": "30min" },
      { "key": "AZ1013fQ9x", "rule": "java:S1481", "severity": "MINOR", "type": "CODE_SMELL", "component": "my-org_my-app:src/main/java/com/acme/OrderService.java", "line": 140, "message": "Remove this unused local variable.", "status": "OPEN", "effort": "5min" }
    ],
    "paging": { "pageIndex": 1, "pageSize": 500, "total": 3 }
  }

Now --format toon:

issues[3]{key,rule,severity,type,component,line,message,status,effort}:
  AZ1002fQ9x,"javasecurity:S3649",BLOCKER,VULNERABILITY,my-org_my-app:src/main/java/com/acme/UserRepo.java,29,Change this code to not construct SQL queries directly from user-controlled data.,OPEN,5min
  AZ1007fQ9x,"java:S2076",BLOCKER,VULNERABILITY,my-org_my-app:src/main/java/com/acme/AuthFilter.java,61,Make sure that constructing this OS command is safe  here.,OPEN,30min
  AZ1013fQ9x,"java:S1481",MINOR,CODE_SMELL,my-org_my-app:src/main/java/com/acme/OrderService.java,140,Remove this unused local variable.,OPEN,5min
paging:
  pageIndex: 1
  pageSize: 500
  total: 3

Same data. The field names are declared once in the header ({key,rule,severity,...}) instead of repeating on every record, and the braces, quotes, and repetition collapse into one row per issue. Crucially, the [3] length and the field header give the model an explicit schema to validate against, so this is not a lossy shortcut like flattening to CSV.

How much does TOON reduce token usage compared to JSON?

I generated a representative 25-issue result (the fields sonar list issues returns: key, rule, severity, type, component, project, line, message, status, effort, totals, paging, and next fields like flows and impacts) and encoded it three ways. Character counts, which are tokenizer-independent and easy to reproduce:

Format	Characters	vs default
`--format json` (pretty, the default)	9,655	baseline
JSON, minified	7,372	−24%
`--format toon`	4,909	−49%

So TOON is about half the size of the default JSON and a third smaller than even minified JSON, by character count, on this payload.

Characters are not tokens, though, and this is where TOON does better than a simple size ratio suggests. Because its structure is so regular (one header, then uniform rows), it tokenizes efficiently. The TOON project's own benchmark suite, counted with the GPT-5 o200k_base tokenizer, reports for uniform tabular datasets (the same shape as an issues list):

−60.7% tokens versus pretty JSON and −36.9% versus compact JSON on the 100-row uniform employee records dataset.
−41.7% versus pretty JSON on the 100-repository GitHub dataset.
Across 244 retrieval questions on four models, TOON scored 72.2% accuracy versus JSON's 71.4% while using 42.6% fewer tokens. Claude Haiku 4.5 was one of the four models, and TOON scored marginally higher there too (65.6% vs 63.5%).

The honest headline: for an issues list, expect roughly a third to a half fewer tokens than JSON, depending on whether your baseline is minified or pretty and which tokenizer your agent uses. And you are not trading comprehension for size; the accuracy held or improved.

A note on method. The character numbers above are mine, measured on a representative payload. The token percentages are from the TOON project's published benchmarks (o200k_base). I could not run a tokenizer in my sandbox to produce a Sonar-specific token count, which is exactly why the next section shows you how to get the real number for your data.

Measure it yourself

The TOON CLI has a --stats flag that prints the token savings for any JSON you feed it. Point it at real Sonar output:

# Grab your issues as JSON (the default)
sonar list issues -p my-org_my-app --severities BLOCKER,CRITICAL --format json > issues.json

# Convert to TOON and print the token-savings report
npx @toon-format/cli issues.json --stats

Then, once you have seen the number, wire the compact form straight into whatever consumes it:

sonar list issues -p my-org_my-app --format toon

Two flag facts worth knowing: sonar list issues require --project (-p), and --format accepts json (default), toon, table, and csv. Use a table when a human is reading, toon when an agent is.

When should you use JSON instead of TOON for LLM input?

TOON is not a universal win, and saying so keeps you honest with your own FinOps stakeholders. Its advantage comes from uniform, tabular data. For deeply nested or non-uniform structures, compact JSON can actually use fewer tokens. An issues list is uniform, so it lands squarely in TOON's favor; a deeply nested config blob would not. When in doubt, run it through --stats and let the number decide.

The bigger picture: three places Sonar trims the token bill

The reason this matters beyond one flag is that Sonar's research reframed the cost problem. In a controlled 540-run study, cleaner codebases used 7.2% fewer input tokens and 8.5% fewer output tokens with no drop in task completion. The mechanism is the quotable part: what drives the cost is not how much the agent writes, it is how much it has to look at. Format the world compactly and give the agent less to wade through, and the bill drops.

That single idea shows up in three places, and --format toon is the cheapest of them:

On the way in: Sonar Vortex Context Augmentation. Instead of letting the agent blind-read entire files to build a mental model, Vortex injects only the relevant guidelines, architecture, and semantic-navigation results before the agent writes. Sonar reports this cuts token consumption by up to 36%, largely by replacing broad file reads with precise, structured context.
Across the whole session: cleaner code. The 540-run result above. Verified, gate-passing code is simply cheaper to operate on, run after run.
On the way out: compact tool results. When the agent reads your issues or dependency risks, --format toon is the same "same information, fewer tokens" move applied to Sonar's own output — sonar list issues and sonar analyze dependency-risks both accept it. It is a one-line change with no downstream cost, because TOON is a lossless representation of the JSON your scripts already parse.

Context Augmentation trims the input side; TOON trims the tool-result side; clean code trims the whole session. They stack. If you are trying to put a number on "our agent spend is a code-quality problem," this is the flag you can ship this afternoon while the larger work lands.

How to get started reducing token usage with Sonar and TOON

Switching sonar list issues to --format toon cuts the size of the data your agent ingests by roughly a third to a half versus JSON, with equal or better comprehension, and you can prove the exact token figure on your own data with npx @toon-format/cli --stats. It is the smallest, most reversible entry into the tokenomics-of-quality story, and it points straight at the bigger levers: Context Augmentation on the input side and clean, verified code across the session.

Claude Code hooks and how Sonar Vortex verifies AI code inside the loop

Prasenjit Sarkar — Mon, 17 Aug 2026 13:00:00 GMT

An agent deleted someone's home folder. Again.

This story is becoming all too familiar: A coding agent runs rm -rf, a tilde expands to the wrong path, and twenty years of files are gone. The agent apologizes in flawless prose. The files do not come back. When it happens, experienced engineers reach for a hook, not a better prompt.

This article is a hands-on tour of how this process typically works. First we build hooks by hand in Claude Code. The event model, the exact JSON contract, and two working scripts you can drop into a repo today. Then we follow the same mechanism into production, because Sonar Vortex's agentic analysis isn't a different idea bolted onto your agent. It is this idea, a deterministic check wired into a fixed point in the agent's loop, applied to the thing that actually breaks the code the agent writes.

Why a hook, and not a better prompt

The uncomfortable admission behind the whole "harness" conversation is that you cannot instruct your way to safety. You can write "never delete files without asking" in the README. You can put it in CLAUDE.md, in capitals. It still isn't a guarantee.The agent will comply most of the time, which is precisely the problem, because "most of the time" is not a safety property. A model is a probabilistic system that samples its next move from a distribution. Capability is climbing fast; reliability on the long tail is not climbing with it. An assistant that nails 90% of tasks and fails strangely on the other 10% is useful as an assistant and a liability as an unattended autonomous system.

A hook is the opposite. It is deterministic code that runs every single time, at a known moment, whether or not the model thought to ask for it. You are wrapping a system you can't fully trust in a layer you wrote yourself. That is the entire idea, and it is why four competing harnesses (Claude Code, Codex CLI, Cursor, Gemini CLI) converged on the same primitive inside a year. When the field agrees on something that fast, it's not a fad. It's the shape of the problem.

Claude Code is the canonical implementation, so we'll use it throughout.

What are Claude Code hooks and how do they work?

A hook is a command wired into the agent's loop at a fixed event. The agent is about to do something: submit your prompt to the model, call a tool, finish its turn. Before or after that moment, your command runs. It receives a JSON description of what's happening on stdin, and it answers in one of two channels: an exit code, or a JSON object on stdout. That answer can allow, deny, or block the action; it can feed information back to the model; it can quietly fix or log things after the fact.

Claude Code exposes 30 of these events. The ones you'll use most:

Event	Fires	Typical use
`SessionStart`	When a session starts, resumes, or clears	Inject project context the model should always have
`UserPromptSubmit`	When you submit a prompt, before the model sees it	Scan or enrich the prompt; block on policy
`PreToolUse`	Before any tool call executes	Allow / deny / ask; the primary guardrail point
`PostToolUse`	After a tool call succeeds	Verify results, format, feed findings back to the model
`Stop`	When the agent finishes responding	Gate "done": run tests, block completion if they fail
`SubagentStop`	When a subagent finishes	Same, for delegated work
`Notification` / `PreCompact` / `SessionEnd`	On notifications, before compaction, at session end	Observability, archival, cleanup

Everything below lives in three of these: PreToolUse for prevention, PostToolUse for verification, and SessionStart for context. Those three carry the Guide and Verify story.

The contract: stdin in, exit code or JSON out

Every hook is just a program. Configuration lives in .claude/settings.json (project) or ~/.claude/settings.json (user). The structure is an event name, a list of matcher groups, and the commands to run for each match:

{
    "hooks": {
      "PreToolUse": [
        {
          "matcher": "Bash",
          "hooks": [
            { "type": "command", "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/guard-bash.sh" }
          ]
        }
      ],
      "PostToolUse": [
        {
          "matcher": "Edit|Write|MultiEdit",
          "hooks": [
            { "type": "command", "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/verify-edit.sh", "timeout": 120 }
          ]
        }
      ]
    }
  }

The matcher is matched against the tool name. "Bash" matches exactly; "Edit|Write" is a regex that matches either of the two file-writing tools; "*" matches everything. $CLAUDE_PROJECT_DIR expands to the repository root so your hook paths don't depend on the working directory.

When the event fires, Claude Code pipes a JSON object to your command's stdin. A PreToolUse payload for a shell command looks like this:

{
    "session_id": "abc123",
    "transcript_path": "/Users/you/.claude/projects/.../transcript.jsonl",
    "cwd": "/Users/you/project",
    "hook_event_name": "PreToolUse",
    "tool_name": "Bash",
    "tool_input": { "command": "rm -rf ~/", "description": "clean up" }
  }

For an Edit, tool_input carries file_path, old_string, and new_string; for a Write, file_path and content. The field you'll reach for constantly is .tool_input.file_path, the file the agent just touched. (Shapes evolve between versions; run claude --debug to see the exact payload your version emits before you write jq against it.)

Your hook answers on two channels:

Exit code. 0 means success; for most events, Claude Code will then parse structured JSON from stdout if you printed any. 2 is a blocking error: the action is denied (or, for PostToolUse, flagged) and whatever you wrote to stderr is fed back to the model as feedback. Any other exit code is a non-blocking error: the action proceeds and stderr is surfaced as a warning.
JSON on stdout. For fine-grained control, print a JSON object. The important part is hookSpecificOutput. For PreToolUse it carries a permissionDecision of "allow", "deny", or "ask", with a permissionDecisionReason. For PostToolUse, SessionStart, and UserPromptSubmit it carries additionalContext, a string injected into the model's context.

Two channels, one principle: exit code 2 is the blunt "no," JSON stdout is the precise "here's exactly what to do and why." Guardrails tend to use the exit code. Context injection uses JSON.

Warm-up: The guardrail from every disaster thread

Here is the canonical example: a PreToolUse hook that inspects shell commands and refuses a recursive rm whose target includes a slash, a tilde, or $HOME.

.claude/hooks/guard-bash.sh:

#!/usr/bin/env bash
set -uo pipefail

input=$(cat)
cmd=$(printf '%s' "$input" | jq -r '.tool_input.command // empty')

# Deny recursive rm that targets a home/root path.
if printf '%s' "$cmd" | grep -Eq 'rm[[:space:]]+(-[a-zA-Z]*r[a-zA-Z]*[[:space:]]+)+.*(/|~|\$HOME)'; then
  cat <<'JSON'
{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "Recursive delete of a home/root path was blocked by policy. Narrow the target or delete specific files."
  }
}
JSON
  exit 0
fi

exit 0

The agent proposes rm -rf ~/. The hook fires before the command runs, matches the pattern, and returns deny. Claude Code never executes it. The model is told no, told why, and moves on. No guessing involved: the same input produces the same decision every time.

This is both genuinely useful and genuinely limited. The pattern is deliberately blunt: it will also catch deletes you meant to run, and a determined agent can phrase a destructive command to slip past it. A regex denylist catches the failure you already imagined. It does nothing about the one you didn't.

The higher-value move: Verify what the agent writes

Deleting your home folder is the dramatic failure. The common one is quieter: the AI agent writes code that looks right, passes a glance, and carries a hard-coded credential, an injection sink, a null-dereference, or a subtle break of an architectural boundary. That code doesn't announce itself. It flows into a pull request and, often, through review.

PostToolUse is the natural place to catch it, because it fires immediately after every Edit and Write, while the change is fresh and the agent is still in the loop, long before CI. The pattern: read the file that just changed, analyze it, and if the analysis finds something serious, exit 2 with the findings on stderr. On PostToolUse, exit 2 doesn't undo the edit that already ran; it feeds your stderr back to the model, which then fixes the code before doing anything else.

A first cut might shell out to whatever linter you have:

#!/usr/bin/env bash
set -uo pipefail
input=$(cat)
file=$(printf '%s' "$input" | jq -r '.tool_input.file_path // empty')
[ -z "$file" ] || [ ! -f "$file" ] && exit 0

# e.g. ruff for Python, eslint for JS/TS, etc.
if ! output=$(ruff check "$file" 2>&1); then
  echo "Lint failed for $file. Fix before continuing:" >&2
  echo "$output" >&2
  exit 2
fi
exit 0

This works, and for style and simple bugs it's fine. But lean on ruff as your safety layer and the cracks show quickly. A fast, file-oriented linter like ruff checks each file mostly in isolation, so it won't follow tainted data from an HTTP handler through three files into a SQL string, and it doesn't model your architecture, so it can't tell you the agent just made the domain layer import the web layer. Cross-file tools do exist (a type checker like tsc, a linter like clippy), but they verify types and language rules, not security taint or architectural constraints. And whatever you pick, its rule set is yours to curate and keep current, and its false positives train the agent (and you) to ignore it. You've wired up a real guardrail on a foundation built to check syntax and style, not to reason about security and design.

That gap, a deterministic hook at the right moment but shallow analysis behind it, is exactly what Sonar Vortex fills.

What is Sonar Vortex and how does it work with AI coding agents?

Sonar Vortex sits inside the agent's coding loop and does two things: it guides the agent with project-specific context before it writes, and it verifies every change in real time with SonarQube's analysis engine, the same engine teams already trust in CI. The code verification half is called agentic analysis, and the reason it belongs in this article is that, on Claude Code, it is delivered as a PostToolUse hook. It's the verify-edit.sh pattern above, except the thing behind the hook is a full static-analysis engine with your project's real context, not a single-file linter.

The interesting engineering is how it gets CI-level precision at inner-loop speed. Agentic analysis works in two phases. During a normal CI analysis, SonarQube collects and stores the context a precise analysis needs (dependencies, compiled artifacts, type hierarchies, import graphs, build configuration), tagged by project key and branch. Then, when the agent edits a file, agentic analysis restores that stored context on demand and analyzes just the changed file against it. You get the accuracy of a full scan, with the same type-aware rules and quality + profiles as CI, without re-scanning the whole project on every keystroke.

Analysis runs at two depths, and the difference matters here. STANDARD analyzes each file on its own and is the default for a single file, which is what the per-edit hook above triggers: cheap enough to sit in the inner loop after every change. DEEP adds cross-file taint tracking and can surface multi file findings and trace data flows, following tainted input across files into a sink, and is the default for a change set, so you reach it through a CLI command like sonar analyze agentic --staged or an end-of-turn verification pass (the kind the CLAUDE.md directive tells the agent to run once its edits are done). Standard keeps the per-edit loop fast; deep is where the cross-file security analysis happens.

That closes the loop. The agent writes code. The PostToolUse hook runs agentic analysis with full context. Findings, with rule keys and severities, come back into the loop. The agent fixes them and the hook re-runs. Code that would have failed the quality gate gets corrected before it ever reaches a pull request, instead of bouncing back from review days later.

Hands-on: Wire it into Claude Code

There are three setup paths. The fastest is the official plugin, which installs and configures everything for you.

Path A: The SonarQube plugin (recommended). From inside Claude Code:

/plugin install sonarqube@claude-plugins-official

Restart Claude Code (or /reload-plugins), then run the guided integration skill from a session opened in your project:

/sonarqube:sonar-integrate

That skill installs the SonarQube CLI if it's missing, authenticates you (sonar auth login opens a browser and stores a user token in your OS keychain), and runs sonar integrate claude, which writes the hooks and MCP configuration into your project's .claude/ directory. Prerequisites: a SonarQube Cloud organization, Node.js (the SessionStart hook needs it), and a container runtime (Docker, Podman, or nerdctl) to run the MCP server image.

On the next start you'll see the SessionStart hook confirm what's live:

SessionStart:startup says: SonarQube plugin initialised.

       sonarqube-cli: ✓ found

       SonarQube hooks: ✓ Secrets Detection, Agentic Analysis

Read that line closely, because it's the whole thesis of this article restated by the tool itself. sonar integrate claude installs a small family of hooks:

a UserPromptSubmit hook and a PreToolUse hook for secrets detection: they scan your prompts and any file the agent is about to read or write, and block operations that would expose a credential;
a PostToolUse hook for agentic analysis (SonarQube Cloud, project-level installs) that runs analysis on your changes after edits, with no further wiring; and
the SonarQube MCP server, so the agent can pull projects, issues, and rules, plus a project-scoped context-augmentation skill for the guide half.

Every deterministic guarantee Sonar Vortex adds to Claude Code rides on the exact primitive we built by hand.

Path B: The CLI directly. If you'd rather not use the plugin, install the CLI and run one command from your repo:

curl -o- https://raw.githubusercontent.com/SonarSource/sonarqube-cli/refs/heads/master/user-scripts/install.sh | bash

sonar auth login

sonar integrate claude --project <YourProjectKey>

Same result: the agentic-analysis hook and secrets hooks are installed and bound to your project key. Under the hood the verification step runs:

sonar analyze agentic --file src/app.ts     # analyze a single file
sonar analyze agentic --staged              # analyze staged changes

Two details worth knowing for scripting. sonar analyze agentic exits with code 51 when it reports issues and 0 when clean, a documented signal you can branch on.

The exit code gives you a clean signal to branch on, with no fragile output parsing. The case that's easy to get wrong is the last one: 0 means clean, 51 means issues were found, and anything else means the CLI itself failed (auth, a server error, a bad flag), which should surface loudly instead of falling through to a silent pass:

#!/usr/bin/env bash
# .claude/hooks/verify-edit.sh: run SonarQube agentic analysis after an edit
set -uo pipefail

input=$(cat)
file=$(printf '%s' "$input" | jq -r '.tool_input.file_path // empty')
[ -z "$file" ] || [ ! -f "$file" ] && exit 0

case "$file" in
  *.py|*.js|*.ts|*.tsx|*.java|*.cs|*.cpp) ;;
  *) exit 0 ;;   # only analyze source we care about
esac

report=$(sonar analyze agentic --file "$file" --format text 2>&1)
status=$?

case "$status" in
  0) exit 0 ;;                          # clean: nothing to do
  51)                                   # issues reported: block and feed them back
    {
      echo "SonarQube agentic analysis reported issues in $file."
      echo "Fix them before continuing:"
      echo "$report"
    } >&2
    exit 2 ;;                           # exit 2 surfaces stderr to the model
  *)                                    # auth, server, or command error: do not pass silently
    {
      echo "SonarQube analysis could not run for $file (exit $status); code was NOT verified:"
      echo "$report"
    } >&2
    exit 1 ;;                           # non-blocking warning; use exit 2 to fail closed instead
esac

That last branch is a real design choice: exit 1 surfaces the failure as a non-blocking warning and lets the turn continue, while exit 2 would fail closed and make the agent stop until analysis works again. (The managed integration installs its own equivalent; this is the shape of what it does, useful if you want to customize behavior.)

Path C: The MCP server directly. If you want the analysis and context tools available to the agent explicitly, including the context-augmentation tools for the Guide phase, configure the MCP server in Claude Code's .mcp.json:

{
    "mcpServers": {
      "sonarqube": {
        "command": "docker",
        "alwaysLoad": true,
        "args": [
          "run", "-i", "--rm", "--pull=always",
          "-e", "SONARQUBE_URL",
          "-e", "SONARQUBE_TOKEN",
          "-e", "SONARQUBE_ORG",
          "-e", "SONARQUBE_PROJECT_KEY",
          "-e", "SONARQUBE_TOOLSETS",
          "-v", "/ABSOLUTE/PATH/TO/YOUR/PROJECT:/app/mcp-workspace:rw",
          "sonarsource/sonarqube-mcp"
        ],
        "env": {
          "SONARQUBE_URL": "https://sonarcloud.io",
          "SONARQUBE_ORG": "<YourOrganizationKey>",
          "SONARQUBE_PROJECT_KEY": "<YourProjectKey>",
          "SONARQUBE_TOOLSETS": "cag,analysis"
        }
      }
    }
  }

Export your token in the shell first (export SONARQUBE_TOKEN="<YourUserToken>"). The canonical agentic-analysis tool the model calls is run_advanced_code_analysis (parameters: projectKey, branchName, filePath, fileScope), which requires the local filesystem mount you see above. Two Claude-Code-specific gotchas: the context-augmentation (`cag`) tools only work with a locally running MCP server plus that mount (the Cloud-hosted MCP server doesn't expose them); and because those tools fire automatically from their descriptions, they have to be loaded from the first turn. Claude Code's tool search lazy-loads MCP tools by default, so the `alwaysLoad: true` shown above forces just the Sonar server's tools to load eagerly at startup. Setting `ENABLE_TOOL_SEARCH=false` achieves the same thing but is a blunter instrument: it disables deferral for every MCP tool you have configured, not only Sonar's.

Guide → Verify → Solve, mapped to events

Sonar frames these stages as the Agent Centric Development Cycle: a continuous Guide → Verify → Solve loop. Read through the hook lens, each pillar maps to an event:

Pillar	Event	Delivery
Guide	Inject coding guidelines, architecture, dependency health, and semantic navigation before the agent writes	Context augmentation via the installed skill + CLI/MCP tools (`get_guidelines`, `get_current_architecture`, `check_dependency`, …)
Verify	Analyze the changed file with full CI context; return findings	Agentic analysis via the `PostToolUse` hook (`sonar analyze agentic` / `run_advanced_code_analysis`)
Solve	Fix the issues found, then re-verify	The agent fixes in-loop; SonarQube's Remediation Agent and AI CodeFix handle PR and backlog issues

Guide sets the agent up to get it right the first time. Verify catches what slips through anyway. Solve closes it out. The reason the loop holds together is that each stage is a deterministic step at a fixed point, not a hope pinned on the model's good behavior.

Sonar reports the payoff across its testing and research: in its own Vortex benchmarks, up to 36% lower token consumption and 92% fewer issues, resting on a measured 3.2% false-positive rate; and separately, its State of Code survey finds teams using SonarQube are 44% less likely to experience outages caused by AI-generated code. The false-positive number is the load-bearing one: an in-loop check the agent learns to trust is worth far more than a noisy one it learns to route around.

What are the security risks of Claude Code hooks?

The mechanism that lets you customize an agent's behavior lets an attacker customize it, too. Hook definitions live in files inside the repository, so a malicious repository can ship its own. This is not hypothetical. In 2025, Check Point Research showed that a SessionStart hook planted in a project's config could execute before Claude Code's trust prompt fired: an initialization-order flaw, not a race, with the trust check simply running too late in the load sequence. That turned merely opening a cloned repo into remote code execution (CVE-2025-59536, since patched; a companion flaw, CVE-2026-21852, exfiltrated API keys through the same project-load path). Your safety layer is also your largest new attack surface.

Good implementations are paranoid about this, and the patches above are why. Claude Code gates a project's configuration behind a trust prompt the first time you open an untrusted folder, and the read-only /hooks menu lets you inspect every configured hook and see which settings file it came from. But note a sharp edge: hook definitions are hot-reloaded, so a direct edit to a settings file mid-session is normally picked up automatically by the file watcher rather than frozen at startup. That is exactly why you should treat your .claude/ hooks as security-sensitive code: pin them in version control, review changes in PRs, keep your tooling patched, and don't trust an untrusted repo's agent config unexamined. If a harness offers hooks without that posture, the hooks are the vulnerability, not the fix.

Note the shape of Sonar Vortex's own secrets protection here: a PreToolUse hook that refuses to let the agent read or write a file that would leak a credential, and a UserPromptSubmit hook that scans what you send. That's the guardrail pattern from the top of this article, pointed at a real threat: deterministic prevention, not a polite instruction.

How do Claude Code hooks fit into a broader AI agent safety strategy?

Hooks are a band of determinism wrapped around a core that will never be fully deterministic. That band is genuinely valuable (it's why this primitive spread across every major harness in a year), but a band is not a box. Pair it with real isolation: run the agent in a sandbox, a container, or a git worktree, somewhere the blast radius is a copy and not your actual home directory. Let the PreToolUse hook catch the rm -rf you thought of, let agentic analysis catch the vulnerability you didn't, and let the sandbox catch the failure nobody modeled.

The through-line of the whole "harness" conversation is that the model was never the product. The loop around the model is the product: the permissions, the sandbox, the hooks, the review gates, the analysis engine wired into the inner loop. All the boring machinery that decides what a guess is allowed to become. As models get more capable and more autonomous, that machinery isn't overhead. It's the job.

Your secrets are leaking to AI coding agents (and how to stop it)

Taylor Luttrell-Williams — Mon, 17 Aug 2026 13:00:00 GMT

AI coding agents prove useful in a number of ways, among them: they read everything. Your source files, configs, environment variables, and even the errors in your terminal, are all fodder for agentic action. An agent consumes this information to better understand the task at hand, then transmits the relevant portions to a model to inform its response. That long reach is central to the value that these agents provide, but also raises a problem, because everything might include your secrets.

As a blunt example, earlier this month, a security researcher captured xAI's Grok Build coding agent quietly uploading developers' entire Git repositories to a cloud storage bucket. A canary API key and database password placed in a .env file showed up verbatim and unredacted in the transmitted traffic (Cybernews, The Next Web). But oftentimes it doesn’t take a dramatic bug to expose a secret; in reality, most leaks are far less conspicuous.

How a secret reaches the model

Secrets can reach a model in a number of ways, but we’ll focus on the two worst offenders. Sometimes you hand over a secret yourself, pasting, for example, a failing API call into the chat (key and all) to ask why it keeps returning a 401. That path is at least visible. The other is quieter than a breach: to build context, the agent reads the files sitting in your project, and that often includes a .env:

# .env — sitting in your project root, read as "context"
DATABASE_URL=postgres://app:S3cr3t-Pa55@db.internal:5432/prod
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
OPENAI_API_KEY=sk-proj-3f9a...redacted

Here, nothing malicious has happened. The agent did its job, but those values are now part of the prompt it sent to a model provider and, as a result, that prompt can get stored: in the provider's logs, and often in the logs of whatever gateway sits between you and the model (frequently in plain text). In this case, nobody typed the key into a chat box; it rode along with the context.

While the first example can be attributed to human oversight, the second is more subtle (and insidious) because it results from the default behavior of a helpful tool doing exactly what you asked of it.

Why secrets are now harder to contain

A secret committed to Git at least sits in one or more places that you can locate and scrub. Once it has traveled through an agent, however, it's scattered across systems you don't own. Rotating a key, for example, closes the door moving forward, but does nothing to address the months of prompt history already sitting in provider and gateway logs, and you can't simply grep someone else's data retention.

Attackers have noticed this and are taking action. Our team recently analyzed a series of Shai-Hulud attacks, including Mini Shai-Hulud, the first in-the-wild supply chain attack built to persist through AI coding agent sessions. It hunts for more than 80 environment variables and more than 130 file paths, including ~/.aws/credentials, ~/.ssh/, and ~/.npmrc, plus database strings and wallet files. For bad actors, the agent's context window has become a target worth attacking.

And even for secrets you can actually find and fix, remediation is a different matter altogether. The clock can be unforgiving as the median time to remediate one leaked secret in a public repository is 94 days, according to the Verizon 2025 Data Breach Investigations Report. Three months is more than enough time for an automated scanner, for example, to locate and abuse a leaked secret.

Catch secrets before they leave the prompt

As the modern software development lifecycle becomes increasingly reliant on agentic workflows, it’s now imperative that secrets are detected at the earliest possible point, before they can travel onward: as you type, before you commit, before the agent ships your context to a model, and again when a PR is opened. Detection must live where the secret is still local and still yours.

One principle stands above the rest here: catching a secret shouldn't depend on the model that's about to transmit it. Detection instead needs to run in a dedicated scanner, separate from the agent, that matches the prompt and files against known secret patterns and returns a plain block-or-allow. A secret is stopped by a rule, not by the model's judgment.

Where SonarQube stands at every door

Secrets detection from SonarQube sits at each point that a secret could potentially slip out, running the same detection engine everywhere: covering 450+ secret patterns across 248 cloud services, with a false-positive rate under 5%.

SonarQube for IDE flags a secret the moment you write it, before it ever leaves your machine.
The SonarQube CLI and SonarQube agent plugins push secrets detection into the agent loop itself, scanning locally at roughly 100 ms per file so your flow isn't interrupted. What gets covered depends on the agent: the prompt you submit, the files the agent reads, or both. When a secret is caught before that prompt or file read goes through, it's blocked on your machine and never reaches the model. The plugins cover Claude Code, GitHub Copilot CLI, Codex, Cursor, Antigravity, and more.
SonarQube Cloud and SonarQube Server catch anything that reaches the repository, flagging secrets in PR analysis and allowing a quality gate to block the merge.

Next steps

Select the environment where your agents run and place a gate there. For terminal-driven workflows, install the SonarQube CLI with the plugin for your preferred agent so that prompts and file reads are scanned locally, then back it with a quality gate in SonarQube Cloud or Server so that nothing slips through at the PR level.

AI coding agents supercharge productivity, enabling developers to ship code faster than ever, but without zero-trust, multi-layered verification, your secrets are vulnerable to leakage. SonarQube provides verification at every step of the software development lifecycle, from prompting to PR. SonarQube secrets detection puts a door in front of your agents that your secrets can't pass through, so you ship fast without mailing credentials to systems you can't audit or control.

Claude Opus 5: An evaluation review & metrics benchmarks

Prasenjit Sarkar — Mon, 17 Aug 2026 13:00:00 GMT

Claude Opus 5 is Anthropic's latest flagship, released on July 24. Anthropic describes it as delivering frontier intelligence at half the price of Claude Fable 5, and calls out one capability in particular: Opus 5 is unusually good at verifying its own work and catching logical flaws while it plans.

That's an interesting claim to test with algorithmic analysis, so we ran it through Sonar's LLM evaluation framework against the same Java benchmark we use for every model.

The short version: correctness improved a lot. Bug density, vulnerability density, and cognitive complexity per line fell, while code smell density, overall issue density, and cyclomatic complexity rose. There's also a volume story underneath it that changes what verification looks like in practice.

What was measured

Model: Claude Opus 5 Thinking (adaptive thinking mode)

Baseline: Claude Opus 4.8 Thinking

Language: Java

Benchmark: 4,441 tasks (158 HumanEval, 386 MBPP, and 3,897 ComplexCodeEval tasks)

Analyzer: SonarQube systematic code analysis. Density metrics are per 1,000 lines of code (kLOC); category breakdowns are per million lines (mLOC).

Two terms worth defining first:

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 works. Both help indicate how much logic reviewers and testers will need to reason through.

Opus 4.8 is the baseline here, since it's the release Opus 5 directly follows. If you read our Opus 4.7 write-up, the refreshed leaderboard now reports 82.72% for 4.6, 83.66% for 4.7, and 82.9% for 4.8. Those three releases remained within one percentage point of each other.

The figures below use the leaderboard's August 14, 2026 refresh. The bug, vulnerability, and code smell category mappings are identical for the two models, so the category comparisons are direct. Headline metrics use the leaderboard's bug, vulnerability, and code smell measures, while the severity tables use reliability, security, and maintainability impact measures, so the two sets of measures are not expected to reconcile exactly.

Key metrics at a glance

Metric	Opus 4.8 Thinking	Opus 5 Thinking
Lines of code (total)	391,456	916,813
Comment-line density	6.9%	10.5%
Cyclomatic complexity per kLOC	228.40	237.82
Cognitive complexity per kLOC	146.40	132.29
Bug density per mLOC	672	576
Vulnerability density per mLOC	314	251
Code smell density per kLOC	16.76	19.69
Overall issue density per kLOC	17.74	20.52
Functional skill (pass rate)	82.9%	88.6%
Missing completions	1.22%	88.6%

What is Claude Opus 5's functional pass rate?

88.6%. That's the number that makes this evaluation interesting.

Across the 544 HumanEval and MBPP tasks with executable tests, Opus 4.8 achieved an 82.9% pass result. Opus 5 achieved 88.6%, a gain of 5.7 percentage points on the same tasks. ComplexCodeEval contributes to the code analysis but not to the functional pass rate. To put that in context, the three Opus releases before this one all landed between 82.72% and 83.66%. This is a step, not a drift.

Missing completions also improved, from 1.22% to 0.83%. The model finishes what it starts more reliably than its predecessor did.

Roughly one in nine solutions in the 544-task test-backed subset still doesn't pass its tests. Better odds than the model before it, and still a ratio that needs something downstream to catch it.

Does Claude Opus 5 generate more code than Opus 4.8?

Here's the change that shapes everything else. Opus 5 generated 916,813 lines of code across the benchmark. Opus 4.8 generated 391,456. That's 2.3 times more code for the same 4,441 tasks.

It also used 122,650 functions, up from 48,734. So the function count grew faster than the line count. More code, more functions, each one slightly tighter. That pattern points toward more decomposition rather than simple sprawl.

Comment lines went from 6.9% to 10.5% of code plus comment lines. In absolute terms that's 107,517 comment lines, up from 29,024. For scale, the two GPT-5.6 variants we evaluated this month came in at 1.5% and 0.9%. Opus 5's comment-line density is 7 to 12 times higher than those results.

For anyone maintaining this code later, that provides more inline context and more signposts, as long as the comments remain accurate.

Complexity

Cognitive complexity is 132.29 per kLOC, down from 146.40. That's a 10% reduction.

Cyclomatic complexity moved slightly the other way, from 228.40 to 237.82 per kLOC, a 4% increase.

Neither complexity measure moved much once normalized. Cognitive complexity is down 10%, cyclomatic up 4%. Given 2.3× more code and 2.5× more functions, shifts of that size say less about how the model writes than about what it wrote this time. Complexity density is roughly flat.

Bug density and severity improvements in Claude Opus 5

Bug density is 576 per mLOC, down from 672. A 14% reduction, and it happened while output volume more than doubled.

Bug category	Opus 4.8	Opus 5
BLOCKER	66	41
HIGH	33	28
MEDIUM	286	241
LOW	291	265

All four severity levels improved. BLOCKER reliability impact issues fell from 38%, from 66 to 41 per mLOC. High-severity findings came down from 33 to 28. Medium from 286 to 241, and Low from 291 to 265.

That’s the cleanest reliability result. BLOCKER is the highest severity tier, and it moved in the right direction alongside every tier below it.

The category breakdown shows where the overall reduction came from:

Bug category	Opus 4.8	Opus 5
Concurrency / threading	105	205
API contract violation	123	57
Resource / stream leaks	97	63
Type safety / casts	100	51
Exception handling	66	32
Null / data value	56	91
Performance / structure	46	38
Control flow mistake	43	21
Pattern / regex	18	16
Data structure	3	2
Uncategorized	15	0

Nine of the 11 rows improved. Exception handling dropped 52%, from 66 to 32 per mLOC. API contract violations more than halved. Control flow mistakes fell 51%. Resource leaks and type safety issues also came down.

Concurrency and threading nearly doubled, from 105 to 205 per mLOC, and became the largest bug category by a clear margin. Null and data-value findings also increased, from 56 to 91 per mLOC.

That's a familiar pattern. Concurrency was also the top bug category in all three GPT models we evaluated this month, and the reasons are inherent. Threading bugs are hard to reproduce, they depend on the environment they run in, and they show up as intermittent failures rather than clean ones. They are easy to miss in code review, which makes testing and analysis especially important.

What security vulnerabilities does Claude Opus 5 generated code contain?

Vulnerability density is 251 per mLOC, down from 314. A 20% reduction.

The security-impact severity profile is where this gets notable:

Security impact severity per mLOC	Opus 4.8	Opus 5
BLOCKER	77	19
HIGH	151	195
MEDIUM	36	5
LOW	82	32

BLOCKER security-impact issues went from 77 to 19 per mLOC. That's a 75% reduction. MEDIUM-severity findings dropped 86%.

HIGH severity findings rose, up 29%. BLOCKER, MEDIUM and LOW also came down, so three of the four tiers improved and the most severe band thinned out considerably.

The category breakdown uses the same rule mapping for both models:

Vulnerability category	Opus 4.8	Opus 5
Cryptography misconfiguration	43	103
Insecure system resource handling	92	82
Inadequate error handling (I/O)	33	24
Hard-coded credentials	59	14
Certificate validation omissions	15	11
Injection attack	18	7
XML external entity (XXE)	23	4
Path traversal / injection	20	0
Web API security misconfiguration	10	2
Uncategorized	0	4
Total density	314	251

XML external entity findings fell from 23 to 4 per mLOC, hard-coded credentials dropped from 59 to 14, and injection findings declined from 18 to 7. Path traversal and injection findings fell from 20 to zero in this snapshot.

Cryptography misconfiguration moved in the other direction, from 43 to 103 per mLOC, and is now the largest vulnerability category.

Either way, it's the category to point automated checks at first. Crypto misconfiguration includes weak algorithms, insecure key sizes, and random number generators used in unsafe ways, which automated analysis can surface before review.

How maintainable is Claude Opus 5 generated code?

Code smell density is 19.69 per kLOC, up from 16.76. A 17% increase, and one of the metrics in this evaluation that moved in a worse direction.

Maintainability impact severity per mLOC	Opus 4.8	Opus 5
BLOCKER	41	75
HIGH	2,197	2,332
MEDIUM	6,782	6,170
LOW	7,196	10,629

MEDIUM-severity maintainability-impact issues came down 9%. LOW-severity findings went up 48%, and that's where most of the increase lives.

The category view shows this isn't a broad shift. It's concentrated:

Code smell category	Opus 4.8	Opus 5
Collection / generics parameter type	3,929	8,901
Regex / pattern / string format	2,549	3,270
Naming / style / documentation	925	1,601
Design / framework best practices	3,196	2,195
Dead / unused / redundant code	1,819	994
Cognitive computational complexity	1,443	790
Control / conditional logic	1,055	507
Assignment / field / scope visibility	1,150	834
Deprecation / obsolete API	547	321
Uncategorized	133	264

Four rows went up. Six came down, four of them by 40% or more.

Collection and generics issues more than doubled, from 3,929 to 8,901 per mLOC, and it's now the dominant smell category by a wide margin. These are raw types where parameterized generics belong, and collection handling that sidesteps type safety. In Java they carry a real cost: they suppress compiler warnings, make refactoring harder, and can hide the kind of bug a properly typed implementation would have caught at compile time.

Naming and documentation smells increased 73%, which is worth reading alongside the comment density result. More annotation overall, more findings on how some of it is written.

Most other named categories moved in the other direction. Design and framework issues fell 31%. Dead code fell 45%. The cognitive complexity smell dropped 45%, which lines up neatly with the cognitive complexity metric coming down.

How does Claude Opus 5 code volume affect total findings

The density results are mixed. Bug density fell 14%, vulnerability density fell 20%, and cognitive complexity fell 10%. Code smell density rose 17%, overall issue density rose 16%, and cyclomatic complexity rose 4%. Comment-line density increased from 6.9% to 10.5%.

Absolute counts are a different picture, because there's 2.3 times more code.

Total findings	Opus 4.8	Opus 5
Bugs	263	528
Vulnerabilities	123	230
Code smells	6,559	18,056
All issues	6,945	18,814

Bugs roughly doubled, and vulnerabilities increased 1.9 times. Code smells rose 2.8 times, and since smells are about 96% of all findings, total issues came in at 2.7 times the 4.8 figure. The increase reflects 2.3 times more code together with higher code smell and overall issue density, even though bug and vulnerability density fell.

Both readings are true, and the gap between them is entirely the 2.3× volume multiplier. Density asks how clean the code is per unit written; absolute counts ask how much work exists. Neither answers the other's question, and substituting one for the other produces a specific error. Cite the density improvement to argue review load is unchanged and you'll under-resource by roughly a factor of three. Cite the absolute counts to argue the model writes worse code and you'll be wrong about bugs and vulnerabilities, which improved on a per-line basis.

The caveat sits underneath both: density is a fair comparison only if the volume itself is neutral. If Opus 5 writes 2.3× more code for the same task, that verbosity is a quality signal in its own right, and dividing by it flatters the result. Density is the right measure for comparing models on equivalent output. It's the wrong one for deciding whether the extra output was warranted.

A note on tokens

Input tokens were effectively identical across both runs at about 2.07 million, which is what you'd expect from the same benchmark. Output was not. Opus 4.8 produced 6.00 million output tokens; Opus 5 produced 21.71 million. That's 3.6 times more output for 2.3 times more code.

What does this mean for teams using Opus 5?

The correctness gain is the headline and it's a real one. An 88.6% pass result across the 544 HumanEval and MBPP tasks with executable tests, after three releases that all landed between 82.72% and 83.66%, is a genuine step forward. And it arrived alongside lower bug density, lower vulnerability density, lower cognitive complexity, and better commenting. Models don't usually improve on that many axes at once.

Anthropic's own framing, that Opus 5 is strong at verifying its own work, is consistent with what we see. Exception handling findings dropped 52%. BLOCKER security-impact issues dropped 75%. Control flow mistakes fell 51%. Every reliability severity tier came down.

Three places to point verification effort.

Concurrency is first. At 205 per mLOC it's the largest bug category and it nearly doubled from 4.8. If what you're generating is concurrent by nature, prioritize testing and analysis for threading issues alongside code review.

Cryptography configuration is second. At 103 per mLOC it's the largest vulnerability category. It's also well-covered by automated analysis, so this is a solvable problem rather than a standing tax on reviewer time.

Collections and generics is third. At 8,901 per mLOC it dominates the smell profile, and it's the kind of issue that's cheap to fix at generation time and expensive to unpick after a codebase has grown around it.

And then there's volume. Opus 5 writes 2.3 times more code than the model it replaces, with more comments and smaller functions. Bug density, vulnerability density, and cognitive complexity improved per line, while code smell density, overall issue density, and cyclomatic complexity worsened. That's the tradeoff to plan for, and it's a manageable one when the verification layer is automated rather than manual.

Three takeaways:

Correctness took a real step. 88.6% versus 82.9% across the same 544 HumanEval and MBPP tasks with executable tests, after three releases that stayed within one percentage point of each other.
The severity results include a strong security gain. BLOCKER security-impact issues dropped 75% to 19 per mLOC, every reliability severity came down., BLOCKER included, from 66 to 41 per mLOC. Bug and vulnerability density are both down.
Volume is the thing to plan for. 2.3 times more code means 2.7 times the total findings, even with lower bug and vulnerability density. Verification effort rises with code volume as well as functional correctness.

Opus 5 achieved a higher functional pass rate and lower bug density, vulnerability density, and cognitive complexity than the model it replaces, while producing more code with higher code smell density, overall issue density, and cyclomatic complexity. That doesn't remove the need for verification. It changes where verification should point, and it makes the case for pointing it automatically.

Full evaluation results for Claude Opus 5, along with every other model we've measured, are on the Sonar LLM Leaderboard.

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.