Alternatives to SonarQube that are not Semgrep or CodeQL?

I run security tooling for a fintech SRE team, ~300 devs, Java/Python monorepos on Kubernetes. We replaced SonarQube three years back after one too out-of-memory incidents.

**Target audience:** DeepSource targets the mid-market sweet spot. Pricing is tiered per active committer, starts around $15/month for the on-prem license. For 100 devs, expect $12k-18k/year.
**Integration effort:** API is clean REST, hooks into our GitLab CI in about a day. The monorepo config was a single YAML at root; it handles path exclusions well. Their scanner image is ~400MB, way lighter than Sonar's.
**False-positive rate:** For Java, we tuned it down to ~8% FP after the first month. Python had more noise initially, around 15%, but their rule tuning interface is decent.
**Where it breaks:** It's not great for legacy branch analysis on huge repos (>5GB). Our initial scan took 4 hours; incremental scans are fine. Support is responsive but you'll wait 2-3 business days for on-prem patches.

If commercial is fine and you need API-first, DeepSource is my pick. Tell us your average commit volume and whether you need custom rule authoring; if you do, check out CodeScene.

DeepSource's API is solid for automation, but their on-prem support was shaky when we tried it. Their container would constantly phone home for rule updates, which our air-gapped clusters didn't love.

For a truly self-contained option, check out MegaLinter. You can wrap the open-source core into your own runner image and hit it via the CLI/API. It's basically a unified layer over linters (including SAST tools), so you can pick just the security analyzers you need. Java/Python monorepo was fine, config lives in a single `.mega-linter.yml`. The false-positive rate is... well, it depends on the underlying linters you enable, but you have direct control to turn rules off.

The trade-off is you're managing the pipeline glue yourself. If that's okay given your RevOps setup, it's lighter than SonarQube and avoids the Semgrep/CodeQL integration headaches.

DeepSource's on-prem support is the dealbreaker. Their container constantly phones home, which defeats the purpose of a self-hosted install if you're in a locked-down environment.

MegaLinter is just a wrapper. You'll end up managing the pipeline glue and the underlying linter versions yourself. That's a config management headache waiting to happen, not a "low overhead" solution.

Have you looked at SpotBugs with the Find Sec Bugs plugin for Java? It's old but reliable. For Python, Bandit. You can run them via a simple script and feed results into your API. The false positive rate is entirely up to your rule tuning, and there's zero vendor lock-in.

Wait, three years out from SonarQube and you're still seeing initial scans take four hours? That's not light, that's just a different flavor of heavy. The 400MB scanner image is a nice improvement until you realize you're trading Sonar's OOM kills for DeepSource's mandatory phone-homes and multi-day support latency for patches.

You mention their on-prem license, but you're glossing over the operational cost of that "clean REST API" when it's dialing out from your locked-down environment. If the vendor's container can't survive a week without checking for rule updates, your air-gapped deployment is a time bomb. It's not truly self-hosted, it's vendor-hosted with extra steps inside your firewall.

Also, an 8-15% false positive rate after a month of tuning is what you're calling decent? That's still a significant tax on developer time to triage noise. For 300 devs, you're trading Sonar's memory problems for a constant background drain of engineering cycles. The real cost isn't the $15 per committer, it's the recurring config drift and the wait for external fixes.

You're right about the operational cost being more than just licensing. The phone-home requirement for rule updates creates a hidden maintenance burden in locked-down environments. We ran into this with another tool that required a weekly check-in; when the vendor's update server had an outage, our scanners threw authentication errors and blocked CI pipelines until we could deploy a pinned rule set.

That 8-15% false positive rate after tuning does represent a constant triage tax. It's often framed as a tuning success, but it still means one in ten findings is noise a developer must process. Over a large team, that adds up to real productivity loss, which isn't reflected in the per-committer price.

A truly self-contained alternative needs an update mechanism you fully control, like a private artifact repository for rule packs.

Take a look at Trivy for SAST. It's mainly known for container scanning, but its language scanning for Java and Python is getting solid. The CLI is clean for automation, you can run it as a sidecar in your CI, and the rule updates are just pulling a new container image - no phone-home. False positives aren't zero, but I found its default rules for Java cleaner than some dedicated tools.

Big plus: it's free and self-contained. For a monorepo, you just point it at the root. The trade-off is it's not as feature-rich for SAST-specific tuning as something like Sonar, but that's the point if you want something lighter, right?

Trivy's SAST is a bolt-on feature that's still playing catch-up. Calling its Java rules cleaner than dedicated tools is a stretch. Their own docs treat it as a secondary capability.

The bigger issue is you're swapping one problem for another. Trivy's update model means you're pulling a new container for every rule tweak, even if it's just toggling a single check off for your codebase. It's free, but you pay in operational rigidity.

If you treat it as a simple scanner you'll never tune, fine. But if you need to manage false positives actively, that image update cycle gets old fast.