Vulkro vs SonarQube
Both are called gates. They measure different things.
SonarQube measures a codebase: complexity, duplication, coverage and a gate on the code that just changed, across a large language set. Vulkro follows a value: a request parameter from the endpoint that accepts it to the sink that trusts it, along with the dependencies, secrets and configuration around it. A quality platform with a security tab and a security engine are not the same product, and the useful question is which one answers the question you have. No same-corpus head-to-head run exists between the two, so nothing on this page is a score.
- No head-to-head run exists
- A different job, not a worse tool
- Scans run on your machine
- Complexity is scored in both
01 / The short answer
Which question are you trying to answer
This is what most readers came for, so it goes first. For once the honest answer is usually both, and section 06 says how to divide the work.
Choose SonarQube if
The question is how healthy the codebase is
- The problem you are solving is maintainability: complexity, duplication, dead code and consistency across a codebase many people touch.
- You want test coverage tracked over time and a gate on the code that just changed, with history a whole team reads.
- Your languages sit outside the set Vulkro parses. SonarQube analyses far more languages, and that gap is large.
- You want one platform for code health that an organisation can standardise on, self-hosted or hosted.
- You want a dashboard with ownership, trends and per-branch history, rather than a verdict on one commit.
Choose Vulkro if
The question is whether input can reach a dangerous call
- You need to know whether a value from a request reaches a sink that trusts it, not whether a function is hard to read.
- You want an inventory of your endpoints and an authorization check on each one, because a route nobody mapped is a route nobody checked.
- You want dependency CVEs, committed secrets, infrastructure configuration and container layers in the same pass as the code review.
- You want the review on the developer machine before the push, with no server to stand up and no code leaving the laptop.
- You want the same verdict twice on the same commit, so a merge gate can be left switched on.
These two columns are not competing for one slot. A team that cares about both code health and exploitable paths needs an answer to both questions, and no single tool on the market is the best answer to each.
02 / The architectural difference
A platform that measures a codebase, and an engine that follows a value
The unit of work is the distinction. One is a project and its history. The other is a path from an entry point to a sink.
SonarQube’s unit is the project over time. A server holds the issues, the ratings, the coverage numbers and the history; scanners feed it; and the gate is defined on what changed since the last analysis. That model is what makes holding new code to a standard work in practice. The value compounds as history accumulates, and the dashboard is as much the product as any individual rule.
Vulkro’s unit is a path. A scan builds a route inventory and a call graph, then asks whether a value that entered at an endpoint reaches a sink that trusts it, and prints the hops it followed to get there. A finding is not a rating on a file: it is a claim about one route, with a file and a line at every step, which is what makes it arguable. Cross-file taint runs in Python, JavaScript, TypeScript and Go for up to four hops. Java taint is same-file only, so a Java result set is narrower than a Python or Go one on the same codebase. History exists but is local: the scan database sits on your machine, and no server is required to get a result.
The two products genuinely overlap in exactly one visible place. Vulkro scores every parseable function for cognitive complexity using the metric SonarSource published, and routes those findings into a separate non-security bucket so they can never inflate a security roll-up. That single overlap is the entire size of Vulkro’s quality story, and it is a rounding error beside what SonarQube does in that category.
Security rules exist on their side too. The dataflow-based injection rules are part of the commercial editions rather than the community build, so which security analysis you actually get depends on the edition you licensed. That is worth checking against their own edition comparison rather than against a page written by a competitor.
- 01
checkout.py:214request handlersourceorder_id read from request.args, no type or format check
- 02
services/orders.py:88helperpassed through lookup_order(order_id) unchanged
- 03
db/query_builder.py:41query builderconcatenated into the WHERE clause with an f-string
- 04
db/session.py:57sinksinkcursor.execute(sql) runs the assembled statement
4 hops resolved. No sanitiser between the source and the sink.
03 / Measured, or not measured
There is no SonarQube number on this page
No same-corpus head-to-head run exists, and the corpus would be the wrong instrument for one anyway.
Three tools have a committed head-to-head row against the benchmark corpus. SonarQube is not one of them. Every claim below is about architecture and capability, which is a different kind of statement from a score and is labelled as one.
Adding a row would settle less than it looks. That corpus catalogues security bugs: a file, a line and a class, each pinned to independent documentation. Most of what SonarQube reports is not a security finding at all, so scoring it there would measure the fraction of its output that happens to overlap with our question and count the rest as a miss. The result would flatter us and tell a reader nothing about whether the tool is good at its own job.
Comparing a quality platform to a security engine on a security corpus is the same error as scoring a security engine on maintainability. This page does neither. What is measured about Vulkro is published separately, with the method, the scoring rules and the misses: the result and the boundary around it and the full methodology.
04 / Where SonarQube wins
What SonarQube does better
Specific, and without a recovery clause. Most of this list is not a gap Vulkro intends to close, because it belongs to a different product.
- The entire maintainability category
- Complexity, duplication, dead code, naming and consistency, plus a debt model that turns all of it into something a team can plan around. Vulkro emits complexity findings and nothing else in this category. This is not a gap being closed: it is a different product.
- Language breadth
- SonarQube analyses many more languages than the five Vulkro parses. If your codebase is C#, Ruby, PHP, Kotlin or Swift, Vulkro reads none of that source, and no framing makes that acceptable to a team that ships in one of them.
- Test coverage
- Coverage reports are imported, tracked over time and can be gated on. Vulkro does not read a coverage report at all, and has no view of what your tests touch.
- A gate on new code
- Holding new code to a standard while leaving the existing backlog alone is a genuinely good idea and it is theirs. Vulkro has a narrower version: findings can be restricted to lines changed against a git ref, so the exit code reflects only what this change introduced.
- A shared dashboard and real history
- A server the whole team reads, with trends, ownership and per-branch history. Vulkro keeps history in a scan database on the machine that ran the scan, which is a deliberate consequence of having no server, and it is less useful to a large team.
- Editor feedback across that same breadth
- Their IDE integration covers the wide language set the analysers do. Vulkro has an editor path too, but only for the languages it parses.
- It may already be deployed
- If your organisation has standardised on it, that is a genuine advantage and adding a second tool is a genuine cost. Say that out loud during an evaluation rather than pretending the switching cost is zero.
- A community build you can run and read
- There is a community edition whose source is published, so you can inspect the analysis you are running. Vulkro’s engine is closed. What this project publishes instead is the benchmark method, the scoring rules, the misses, and the evidence behind each individual finding.
05 / Coverage
Capability against capability
No measurement appears in this table. It sets out what each tool is built to do, and several rows are plainly theirs.
| What you are asking | Vulkro | SonarQube |
|---|---|---|
| Maintainability and code smells | One family: cognitive complexity and deep nesting, kept in a non-security bucket. | The core of the product, across a large rule set. |
| Test coverage | Not read. | Imported from your test runner and tracked over time. |
| Duplication | Not measured. | Measured and reported per project. |
| Endpoint inventory | Routes extracted per framework, then checked for missing authorization. | Not part of the model. Issues are reported per file and per rule. |
| Taint from request to sink | Cross-file up to four hops in Python, JavaScript, TypeScript and Go. Java taint is same-file only. | Dataflow-based injection rules are part of the commercial editions rather than the community build, so what you get depends on the edition you licensed. |
| Dependency CVEs | In the same scan, matched offline against a checksummed bundle on your disk. | Dependency analysis is a separate part of their line. Check what your edition includes. |
| Committed secrets | A provider rule set runs in the same pass as the code review. | Secret detection rules ship in their analysers too. |
| Infrastructure as code and container images | Terraform, Kubernetes, Compose, Helm and Dockerfiles, plus the packages inside a built image. | Infrastructure-as-code analysers ship in their line too. |
| Languages read as code | Python, JavaScript, TypeScript, Go, Java (5) | Many more, and that is a real gap rather than a rounding error. |
| Where it runs | One binary on your machine or your runner. No server, and no code leaves. | A server plus scanners, self-hosted or hosted. The server holds the history. |
| History and trend | Local, in the scan database on the machine that scanned. | Central, shared, and one of the main reasons to run it. |
| Salesforce (Apex, Lightning, Flow, org metadata) | Read by Vulkro for Salesforce, which is this same review pointed at a Salesforce build. | Apex analysis exists in their ecosystem through third-party plugins rather than in the base product. |
| Severity | Finding | CWE | Rule |
|---|---|---|---|
| CRIT | SQL injection in order lookupcheckout.py:214 | CWE-89 | VULK-1042 |
Dataflow pathVULK-1042
4 hops resolved. No sanitiser between the source and the sink. | |||
| HIGH | Missing authorization on invoice downloadroutes/invoice.ts:47 | CWE-639 | VULK-2117 |
| HIGH | SSRF via user-supplied URLproxy-handler.ts:23 | CWE-918 | VULK-1180 |
| MED | Hardcoded API token committed to the repositoryconfig/stripe.js:9 | CWE-798 | VULK-3304 |
Read the language row honestly before you decide. Vulkro parses five languages and states the limit for each, and a file in any other language is counted in the inventory and skipped rather than analysed.
06 / Running both
The usual answer, and who owns which category
These two occupy different slots in the same pipeline. The work is deciding the boundary once, not choosing a winner.
If SonarQube is already deployed, keep it. The overlap is small enough that removing it to make room would cost you the maintainability half of your quality signal and buy nothing in return.
The arrangement that works: SonarQube keeps the quality gate on new code and the history a whole team reads. Vulkro runs on the developer machine and in the pre-merge check, where the question is whether this change opened a path from an endpoint to a sink. Vulkro writes SARIF, so its findings can land in the same security tab as everything else, and its exit code is the gate for the CI lane.
Decide one thing up front: which tool owns which category, so the same issue is not filed twice by two systems with different severities and two different owners. The clean split is maintainability there, and security paths plus supply chain here. Complexity is the one row that genuinely appears on both sides, so pick a single owner for it and switch the other off.
# only findings on lines this branch changed $ vulkro scan . --gate-vs origin/main --min-confidence high SECURITY FINDINGS 1. [HIGH] Missing authorization on a changed route PATCH /api/orders/:id updates a record the caller is never checked against. ↳ routes/orders.ts:74 # the gate is the exit code, so CI parses nothing $ echo $? 1