SonarQube vs Semgrep

Where Semgrep wins

Rules a reviewer can read

A Semgrep rule looks like the code it matches, with metavariables where the details vary, so writing one is a normal pull request and reviewing one does not require learning a query language. That is the difference between "we should enforce that nobody calls this deprecated helper" being a Monday-afternoon task and being a project nobody starts. In SonarQube the same custom rule means a plugin, which in practice means it does not get written.

The free path has no branch paywall

The Semgrep CLI with community rules runs in any pipeline, on any number of repositories, at no cost, and it scans whatever diff or ref you point it at. SonarQube's free Community Build analyses a single branch, because branch analysis and pull-request decoration are commercial-edition features and the community plugin that adds them is unsupported by Sonar. For a team that wants free feedback on pull requests, that is a decisive structural difference.

Security depth, priced in parts

Teams at $30 per contributor per month buys Code or Supply Chain, with Secrets at $15, so you pay for the scanners you want rather than for a bundle. The hosted Free tier covers 10 repositories and 10 contributors including cross-file analysis, which is enough for a genuine evaluation on real code. On SonarQube, the comparable security depth lives in the Advanced Security add-on, which is quoted rather than listed.

Nothing to run, or everything to run, your choice

Because the engine is a CLI, Semgrep fits a team that wants zero hosted dependencies as well as one that wants a managed dashboard. SonarQube's free path forces the server on you, and since Community Build lost its Long-Term Active version at the end of 2024, it forces roughly monthly upgrades with no backported fixes.

Where SonarQube still wins

The maintainability half is the thing Semgrep has not built and does not claim: no cognitive-complexity metric, no duplication analysis, no technical-debt estimate, no quality gate expressed in those terms. If what your organisation actually bought SonarQube for was a defensible number to point at in a planning meeting, Semgrep will not replace it. Pairing Semgrep with per-language linters covers the style layer, but the aggregate score and its history do not come back.

Coverage and curation follow from that. SonarQube reads 34 languages on Developer Edition and 40 or more on Enterprise with rules maintained by a vendor whose entire business is those rules; Semgrep's community set is broad but uneven, and the gaps are yours to fill. Treat Sonar's aggregate 3.2 percent false-positive figure as a vendor claim, but the curation effort behind it is real and it is exactly what you take on when you own a ruleset. Finally, on-premises: SonarQube self-hosts at every tier including free, while the Semgrep platform is on-premises only at Enterprise.

Migrating SonarQube to Semgrep

The path most teams take:

1. Inventory first. Split your SonarQube gate into three buckets: security rules, style rules and metric thresholds. Semgrep replaces the first, per-language linters replace the second, and the third usually has no successor, so decide now whether you can live without it.
2. The swap. Add semgrep ci to the pipeline with the community rulesets for your languages, then move your genuinely load-bearing custom checks into a repository-local rules/ directory so they are versioned and reviewed like code. Add ESLint, Ruff, Checkstyle or clang-tidy for the style layer.
3. Run both for one cycle. Two to four weeks side by side on the same pull requests, and expect the two issue lists to overlap only partly. What matters is which findings you would have missed, not which tool reports more.
4. What does not move. The debt model and the history. Complexity scores, duplication percentages, technical-debt estimates, issue decisions and past gate results all stay on the SonarQube instance, and no Semgrep equivalent exists to import them into.