Gadriel vs. SonarQube: One Local Tool vs. a Quality Server, Across Six Goat Apps

The short version

SonarQube is a genuinely strong, mature product. It is a code-quality and security platform — reliability, maintainability, code smells, coverage gating, and a central team dashboard — with real taint analysis and security hotspots on languages like Python and JavaScript. On code quality it does things Gadriel deliberately does not do, and we give it full credit for that.

But it is a different kind of tool, deployed a different way. SonarQube is server-hosted: you run a multi-gigabyte Elasticsearch + web + compute-engine server and a separate scanner, then wait for results. In this battery it was also run source-only, with no build step, which limits what it can see — most sharply on Java (dvja), where SonarQube's security depth genuinely needs compiled bytecode and it returned nothing. That is an honest operational caveat, not a Gadriel detection win. Gadriel, by contrast, is a single local command with no server, does the whole job in one pass — SAST + SCA + secrets + container + config + API + AI/LLM — learns per-codebase, and runs fully offline. This write-up lays out where they are peers, where SonarQube leads, and where Gadriel leads — plainly.

How Gadriel works: one local pass

The comparison only makes sense once you see the shape of Gadriel's pipeline. Unlike SonarQube — a server you provision, a scanner you invoke, an analysis you poll — Gadriel is one local command that runs everything in a single pass and hands you results.

The default scan is the deterministic pass: AST/taint SAST, SCA with OSV CVE lookup, secrets, container/IaC, config/AI-runtime, and OpenAPI checks all run together, offline, and emit findings tagged with confidence tiers — alongside the SBOM, the 10-framework compliance reports, and a static HTML bundle. This is the story of this comparison. Gadriel also ships an optional Tier-2 pass (off by default) that uses a host LLM to both re-check the gating SAST findings and hunt for the access-control bugs taint rules miss; it is a bonus box, not the basis of the numbers below.

flowchart LR
  R[Source repo] --> T1
  subgraph T1[Default scan — deterministic, one local pass]
    direction TB
    S1[SAST taint/AST]:::c --- S2[SCA + OSV CVE]:::c --- S3[Secrets]:::c
    S4[Container / IaC]:::c --- S5[Config / AI-runtime]:::c --- S6[API / OpenAPI]:::c
  end
  T1 --> OUT[Findings + confidence tiers + SBOM SPDX/CycloneDX<br/>+ 10-framework compliance + static HTML report]
  T1 -.-> T2[Tier-2 optional — host-LLM verification<br/>off by default]
  T2 -.-> OUT
  classDef c fill:#eef,stroke:#88a;

The findings, times, and comparisons below are all from Gadriel's default scan — the deterministic one-pass output, with the optional verification pass left off.

What we tested

Six open-source "goat" applications — apps deliberately packed with known, exploitable bugs so the ground truth is knowable in advance. Every scan was a genuine first-time run on a repository Gadriel was never trained or tuned on, measured on the same machine (July 2026).

Versions: Gadriel 1.2.1; SonarQube Server 26.7 (Community Build), run source-only (no build step).

Cross-repo scoreboard

Gadriel figures are from the July 2026 live re-run (offline, first-time). SonarQube figures are from each per-repo scan.

(Gadriel counts are the default-scan output; SonarQube totals include its own code-quality volume. The dvja "0" reflects SonarQube's documented need for a Maven build — stated, not scored.)

The Gadriel Tier-2 column is the verify half of the optional Tier-2 pass (--tier2, off by default) re-checking each repo's Medium-confidence gating-eligible SAST findings: 19/19 confirmed, 0 refuted across the six repos. Tier-2 also hunts for access-control bugs the rules miss (+25 advisory own-code adds — see the coverage table below). It's a bonus, not the basis of this comparison — every other number here is from the default scan.

Every scan also emitted an SBOM (SPDX 2.3 + CycloneDX 1.5), 10-framework compliance reports, and a static HTML report bundle — with no server running.

Optional: Gadriel Tier-2 (your own LLM)

Gadriel ships an optional AI pass — Tier-2, enabled with --tier2 (or GADRIEL_TIER2 / [tier2].enabled), off by default — and it does two things. First it verifies: it adversarially re-checks the gating SAST findings the default scan raised (refute or confirm). Second it hunts: it semantically reads the source for the vuln classes deterministic taint rules structurally miss — IDOR/broken-object-authz, missing or broken authorization, and forgeable/unsigned-token auth — and surfaces them as advisory, review-flagged findings (never build-gating). Its distinguishing property is bring-your-own-LLM: it borrows the host agent's already-running model (Claude in Claude Code, GPT in Cursor, or a local Ollama model), so Gadriel makes no API call of its own — no vendor model to buy, no code egress, no second bill, and it works air-gapped.

Run across these six repos, the verify pass confirmed 19/19 of the Medium-confidence gating-eligible findings (0 refuted), and the hunt pass surfaced +25 advisory access-control/broken-auth issues the deterministic rules can't reach — taking own-code coverage from 37 → 62. This is a bonus tier, not the basis of the scoreboard — every per-repo number below is from the default scan.

Own-code coverage: default scan vs. +Tier-2

Advisory, non-gating. The +hunt column is what Tier-2's LLM surfaced for review beyond the gating SAST findings — access-control and broken-auth bugs that are a missing check, not a tainted data-flow to a sink, so rule-based taint analysis structurally cannot see them.

The +25 span IDOR/broken-object-authz (CWE-639), missing function-level authz (CWE-862), missing authentication (CWE-306), forgeable/unsigned-token auth (CWE-256/330/565/640/287), and — on the SAST-thin Java repo — the critical PingAction command-injection (CWE-78) and path-traversal (CWE-22). Standout: dvja, where the default scan found 1 code bug and Tier-2 recovered the command-injection plus a product IDOR, a forgeable admin-cookie, and a forgeable reset-token (account-takeover chain).

Tool coverage matrix (structural — what each tool does at all)

Counts aside, the two tools cover different ground. This matrix is about capabilities, not scores — and it's kept honest: SonarQube's home turf is deep code-quality and maintainability breadth plus source security on well-supported languages, which is real and which Gadriel deliberately does not attempt.

SonarQube's genuine leads are the top two rows: it is a first-class code-quality platform with a central team dashboard, and it does source-level security taint analysis on languages like Python and JavaScript. Where Gadriel differs is the rest of the column — dependency CVEs, secrets, container, config, API, AI/LLM risk, offline operation, and an SBOM per scan — all from one local command with no server.

On the self-verification row: the differentiator is delivery, not detection superiority. SonarQube's own AI add-on (its AI CodeFix/AutoFix) calls its own cloud model — a second vendor, a second bill, and code leaving your box. Gadriel's Tier-2 reuses the LLM you already run and stays local.

Repo by repo

pygoat — Python / Django

pygoat is stuffed with the worst-case bugs: eval RCE, pickle and yaml unsafe deserialization, command injection, and SQL injection. Gadriel returned 38 findings (20 security-risk) in ~3.7s, including 18 SAST hits across those critical/high injection and deserialization patterns, plus container (10), SCA (3), secrets (5), and config (2). This is Gadriel's strongest repo. Marquee catches, verified in the re-scan: pickle RCE L1-072 (main.py:36), command injection L3-017 (mitre.py:233), SQLi L3-054 (views.py:162), yaml/deserialization L3-016/020/035, a hardcoded key L4-115, and the committed secret SECRET-486 (settings.py:25).

SonarQube reported 150 issues — but they were Django configuration and code-quality warnings (CSRF disabled, debug flag, cookie settings). Those are worth fixing, and quality breadth is Sonar's home turf. But its free/source-only run did not surface the code-execution or injection flaws — the deeper taint tracing that would catch them is a paid feature. Where they differ: Gadriel's one-tool security breadth (code + libs + secrets + container + config) vs. SonarQube's quality dashboard.

django.nV — Python / Django 1.8.3

Built around OWASP A1–A10 on an end-of-life framework. Gadriel returned 12 findings (8 security-risk) in ~14.4s — 7 SAST including a critical SQL-injection sink CODE-W1-L3-014 (views.py:183, the Python formatted-SQL fix) and a critical command injection L3-017 (misc.py:33), plus an open-redirect L1-821 (views.py:387), the vulnerable Django 1.8.3 dependency SCA-056 from requirements.txt, and the hardcoded SECRET_KEY SECRET-486. Every view here is unauthenticated and the SQLi + cmd-injection have a clean request→sink taint path.

SonarQube reported 126 issues, but only 14 were classified security — the other 112 were maintainability/reliability "bugs." That volume is real and useful for quality, and Sonar's 14 security items did flag genuine Django config weaknesses (a peer area). Where SonarQube leads: code-quality/maintainability breadth Gadriel doesn't target. Where Gadriel leads: SCA on the old framework and insecure config (pickle serializer, MD5) that Sonar's source-only pass didn't check.

vulpy — Python / Flask

vulpy's paired bad/+good/ trees let us measure precision, not just recall. Gadriel returned 5 findings (2 security-risk) in ~2.5s — a critical formatted-SQL-injection hit CODE-W1-L3-014 (bad/libuser.py:12, the Python formatted-SQL fix, firing live), plus debug=True (L4-115) and an auth-over-HTTP issue (L4-145) — and it fired only on request-reachable injectable queries in bad/, with zero findings inside the hardened good/ tree.

SonarQube reported 93 issues (46 security hotspots, 47 bugs) — all configuration/quality warnings; it did not detect the SQL injection. Sonar's hotspots (hard-coded credential, CSRF, debug) are legitimate review prompts (peers there). But on the actual injectable queries, Gadriel leads — with the precision to leave the safe code alone.

govwa — Go / MySQL

Gadriel returned 11 findings (8 security-risk) in ~3.0s — a critical Go formatted-SQL injection CODE-W1-L2-002 (function.go:41, the Go formatted-SQL fix, now firing live) plus a second high injection path (database.go:24), weak MD5 hashing L1-313 (user.go:160), vulnerable Go deps (SCA), and four container issues.

SonarQube reported 26 (22 quality bugs, 4 "vulnerabilities"). It earned genuine credit for spotting the hardcoded MySQL password in docker-compose.yml — a real find. But it missed the Go SQL-injection flaw. Honest note: govwa also has template.HTML reflected XSS that neither Sonar's free tier nor Gadriel led on; a dedicated OSS SAST caught more, and Go XSS is an area Gadriel is actively improving.

dvja — Java / Spring / Struts2

This is the honest one. SonarQube returned 0 findings — not because the app is clean, but because SonarQube's Java rules run against compiled bytecode and this was a source-only run with no Maven build. That is a documented SonarQube requirement. Read correctly: with a proper build and its server running, SonarQube is a capable Java security-and-quality tool. The "0" is an operational-fit caveat, not a detection loss — and we don't score it as a Gadriel win.

Gadriel scanned the source as-is, no build, and returned 15 findings (6 security-risk) in ~5.3s — one JPQL SQL-injection code bug CODE-W1-L1-1004 (ProductService.java:48, critical), three vulnerable-dependency findings (the out-of-date Apache Struts library, SCA-006/008, tied to RCE advisories), and ten container-hardening issues. But candidly: dvja has ~18 own-code bugs and Gadriel caught only one in source. Java SAST depth is Gadriel's weakest area; here its value is the dependency + container + one-tool story, not code-bug breadth.

NodeGoat — JavaScript / Express / Mongo

Gadriel returned 14 findings (7 security-risk) in ~5.2s — the marquee eval() code-injection bug CODE-W1-L1-001 (contributions.js:32, critical) plus a second injection in Gruntfile.js:165 (L1-008), an open-redirect CODE-W1-L1-1696 (index.js:72), the committed TLS private key SECRET-001 (artifacts/cert/server.key), plus npm SCA, container, and config checks.

SonarQube reported 37 (15 "vulnerability", 22 "bug") and clearly did real JavaScript analysis — it leads on raw JS code-warning volume, and Gadriel's JS SAST depth is still maturing. But SonarQube Community structurally can't scan npm dependencies, detect the committed key, or check the container — which is where two of this repo's most serious problems live. Tier-2's hunt pass also surfaced a fifth advisory finding here — a missing-authorization check on an admin route — one more than the other repos' flat +4, reflecting NodeGoat's larger authenticated surface area. Gadriel leads on breadth and the two highest-impact catches; SonarQube leads on JS code-warning count.

Where Gadriel clearly wins

1. No server to run. SonarQube needs an always-on, multi-gigabyte server (and often a build) before it can begin. Gadriel is one small command that returns results in seconds and exits.
2. Breadth in one tool. SAST and SCA and secrets and container and config and API and AI/LLM risk — in a single pass. SonarQube covers code quality + some source security; it does not do dependency CVEs, secrets, or container/config in the free tier.
3. Learning per-codebase. Decisions are remembered per-codebase so the next scan is more accurate, and an optional AI verification pass can re-check gating findings when you want it. SonarQube tracks open/closed status but does not learn to be more accurate from your feedback.
4. Audit-ready by default. An SBOM (SPDX + CycloneDX) and 10 compliance frameworks (EU AI Act, NIST AI RMF, SOC 2, HIPAA, PCI-DSS, OWASP LLM Top 10, CMMC, ISO 42001, and a Cyber-Insurance readiness checklist) come out of every scan.
5. Offline / local. Gadriel runs entirely on your machine and works air-gapped. For regulated or IP-sensitive teams, that's decisive.

Where Gadriel still trails or differs (honest)

• Code quality is SonarQube's job, not Gadriel's. Reliability, maintainability, code smells, coverage gating, technical-debt tracking across a large codebase in a central team dashboard — SonarQube does this deeply and Gadriel deliberately does not. If quality gating is what you want, that's Sonar's lane.
• With a proper build, SonarQube's Java security depth improves. The dvja "0" is a source-only/no-build artifact; a compiled run changes the picture. We won't pretend otherwise.
• Java SAST recall is Gadriel's weakest area. On dvja, Gadriel caught 1 of ~18 own-code bugs. Its Java code-analysis depth trails its Python and Go coverage.
• JavaScript SAST breadth is still maturing. Gadriel catches eval and the committed key but misses some JS code patterns Sonar's engine surfaces.
• Category breadth in Python (IDOR, @csrf_exempt, template | safe XSS) and Go XSS (template.HTML) are known gaps.

The optional Tier-2 pass already addresses part of this: its bring-your-own-LLM semantic hunt surfaces the IDOR / missing-authorization / broken-auth family as advisory (review-flagged, non-gating) findings — this round it added +25 such own-code issues Tier-1 alone missed. That's advisory, not gating, and it doesn't touch the deterministic Java/JS SAST-breadth gap, which is still real and being improved.

These are tracked in Gadriel's detection backlog as the next benchmark-driven fixes.

The benchmark → fix flywheel

This is a practice, not a slide. When a repo surfaces a real Gadriel miss that a peer scanner catches, we root-cause it and ship a documented fix. This round, the Python and Go formatted-SQL-injection recall gaps — the classic "...".format(user) / "..." % user → cursor.execute shape that the provenance engine couldn't reach cross-file — were closed with narrow, source-optional matcher heuristics that stay precise on parameterized queries. Both shipped: Gadriel's Go formatted-SQL-injection detector (Go) and Gadriel's Python formatted-SQL-injection detector (Python). They were unit-tested and re-validated live — both fire on govwa and vulpy/django.nV in the fresh run above.

Honest evaluation: where Gadriel is strong, where it's weak, and what Tier-2 closes

Laid out plainly, on own-code security:

• Strong (default scan): injection — SQLi, OS-command, code/eval — especially on Python and Go, where Gadriel's deterministic taint analysis is a peer of the best rule-based scanners in this battery.
• Honestly weak (default scan): two things. (a) Java and JavaScript SAST breadth — dvja bottoms out at 1 own-code bug, NodeGoat at 4. (b) the access-control family — IDOR, missing/broken authorization, forgeable-token auth — which is structurally invisible to AST taint rules, because the bug is a missing check, not a tainted data-flow reaching a sink. No rule-based scanner in this set reaches it.
• What the optional Tier-2 (your own LLM) closes: exactly those two gaps. It surfaced +25 measured, advisory IDOR/authz/broken-auth findings — including the dvja command-injection + IDOR + account-takeover chain the default scan alone reduced to a single code bug.
• Net, on own-code coverage: with Tier-2 on, Gadriel + Tier-2 reaches the own-code access-control layer SonarQube doesn't reach — 62 own-code items surfaced, spanning injection and the access-control family.

Read that honestly, and keep the guardrails:

• Tier-2 adds are advisory, not gating. They are surfaced and flagged for review, capped low-severity; they never fail a build. The added access-control coverage is surfaced, not enforcement.
• This own-code lead is own-code only. SonarQube still leads code-quality and maintainability breadth — its home turf, a central team dashboard, deep smell/reliability/technical-debt tracking — and with a proper Maven build its Java security depth improves (the dvja "0" is a source-only/no-build caveat, not a detection loss). Gadriel does not displace that.
• The Tier-2 differentiator is delivery, not detection superiority. Versus SonarQube's own AI add-on (its AI CodeFix/AutoFix), the win is BYO-LLM: your Claude/GPT/local Ollama, one local command instead of a provisioned server, no vendor cloud call, no egress, no extra bill — not a claim of better raw detection than its cloud model.

The bottom line

Be fair to SonarQube: it is an excellent, mature code-quality-and-security platform. For a team that wants a central server, quality gates, maintainability tracking, and taint-based source security (especially with a proper build), it earns its reputation — and it does real things Gadriel doesn't attempt.

Gadriel's fit is different: security-first, the whole job in one pass (code + libraries + secrets + containers + config + APIs + AI/LLM risk), delivered by a single local tool with no server, that learns per-codebase, works offline, and ships an SBOM plus 10 compliance frameworks with every scan. Across these six repos it caught the genuinely dangerous, hackable flaws — Go and Python SQL injection, eval RCE, unsafe deserialization, committed keys, vulnerable dependencies — while being honest about where its Java and JavaScript SAST depth is still catching up. Security is the sharpest edge of the comparison here, but it's one of eight pillars Gadriel validates in every scan — compliance, safety, operational, FinOps, coherence, teamwork, and bias run in the same pass. If you want a security program you can run anywhere in seconds, that's the difference.

Test details: six first-time scans of repositories Gadriel was never trained on — adeyosemanputra/pygoat, nVisium/django.nV, fportantier/vulpy, 0c34/govwa, appsecco/dvja, OWASP/NodeGoat. Gadriel 1.2.1; SonarQube Server 26.7 (Community Build) run source-only, with no build step, which limits its results — most sharply on Java (dvja), where SonarQube's Java rules require compiled bytecode and it therefore returned 0 (a documented requirement, not a judgment that the app is safe). Gadriel timings are wall-clock of an offline scan; all figures measured on the test machine, July 2026. Gadriel finding counts are the default-scan output; SonarQube totals include its code-quality volume.