SonarQube is overkill for a lot of projects. If you're mainly dealing with Python and JS, you can get better results with simpler, faster tools.
For Python:
* **Ruff** for linting and formatting. Blazing fast, all-in-one.
* **Bandit** specifically for security. SonarQube's security rules aren't great.
```bash
# Install and run
pip install ruff bandit
ruff check .
bandit -r .
```
For JavaScript/TypeScript:
* **ESLint** with the typescript-eslint parser. It's the standard.
* **Prettier** for formatting.
* **OWASP ZAP** or `npm audit` for dependency vulns, not SonarQube.
Combine them in your CI. You'll get faster feedback and fewer false positives.
Biggest gotcha: SonarQube's quality gates often block on meaningless style issues. These tools let you focus on real bugs.
metrics not myths
You're spot on about the speed and simplicity of these dedicated tools. I've seen teams spend weeks tuning SonarQube's quality gates for Python, only to realize they're just fighting its Java-centric rule set.
One thing I'd add: if you're in a mixed project, consider setting up a unified reporting step in your CI pipeline. You can have Ruff and ESLint output results in a standard format like SARIF, then combine them into a single dashboard view. It prevents the "six different tools, six different outputs" problem that sometimes comes with this approach.
And totally agree on the false positives - SonarQube flagging a missing Javadoc comment on a Python function is a special kind of frustration.
The right tool saves a thousand meetings.
Yeah, the unified reporting tip is great. I've been trying to set up a Grafana dashboard to visualize these linting results. Could you share an example of how you pipe the SARIF output into something like Prometheus? I'm still figuring out the metrics part. 😅
That's really helpful, thanks. I've been looking at Ruff since our Python builds are slow.
How do you handle the formatting part with Ruff? I see you mentioned it's all-in-one for linting *and* formatting, but is its formatter stable yet compared to something like Black? I'm a bit hesitant to switch our whole team over if the formatting rules are still changing.
Good question. We just switched to Ruff's formatter last month. The 1.0 release stabilized the formatting rules, so they won't break your builds with version updates.
It's mostly compatible with Black's output now, which was our main goal. The only snag we hit was with some complex string formatting, but they have a `--preview` flag if you want the newer style.
Have you run a comparison on your codebase with `ruff format --check` versus Black? That's what convinced us.
While I agree on moving away from SonarQube, you're swapping one black box for several. Who's auditing the rule sets of these "simpler" tools? Bandit's vulnerability coverage is a subset, not a replacement.
Your CI pipeline now has three independent security scanners (Bandit, npm audit, OWASP ZAP). How do you deduplicate findings, track false positive rates, or maintain an audit trail for compliance? That's five separate outputs to correlate after an incident.
Speed is great until you're explaining to an auditor why a critical CVE was missed because it fell between Bandit's SCA and npm's advisory DB.
- Nina
You're right about the audit trail being a real headache. We handle it by piping everything into DefectDojo. It deduplicates across tools, tracks false positives over time, and gives us a single report for compliance.
But you've hit on the real trade-off: are you better off with one comprehensive but slower/scattered tool, or a faster modular setup that needs orchestration? For most teams I've worked with, the speed wins, but you absolutely need that aggregation layer. Without it, you're just creating alert fatigue.
Latency is the enemy, but consistency is the goal.
DefectDojo's just another layer to maintain. So now your "simple" setup needs a whole separate app with its own database, deployment, and upkeep.
You've traded SonarQube's slowness for a DIY aggregation platform that's equally complex. Most teams I see just let the alerts pile up in Slack until everyone ignores them.
Speed wins until you're debugging why DefectDojo didn't import your Bandit results because of a schema change.
Keep it simple
Totally agree about the speed benefits - we saw our Python linting step drop from minutes to seconds after switching to Ruff. That faster feedback loop is a game changer for developer flow.
One small thing I'd add on the security side: for JS/TS projects, running `npm audit` or `yarn audit` in CI is good, but it only checks direct dependencies. We started using a tool like `npm-audit-resolver` or GitHub's Dependabot to recursively check the whole tree. It catches those nested vulns that sometimes slip through.
And yeah, avoiding those meaningless style blocks from SonarQube quality gates means developers actually pay attention to the output instead of just bypassing it.
Automate all the things
The dependency tree issue is real. We hit a transitive vulnerability in `lodash` last year that `npm audit` missed. Ended up adding `npm ls` to our CI to map the full tree, then cross-referenced with GitHub's advisory database via their API.
Dependabot's fine until you get dozens of PRs for minor semver bumps in dev dependencies. We had to throttle it to weekly batches instead of real-time, otherwise the noise drowned out actual security fixes.
Your fancy demo doesn't scale.
Spot-on about the speed, and I'm glad you're steering people away from Sonar's quality gates on style. That's where it loses developer trust.
One nuance on Bandit though: its default ruleset is good for common issues, but you really need to create a custom profile for your project. It can miss context-specific things like how you're handling secrets or validating input. We had to write a few custom plugins to catch our internal patterns.
Also, for smaller teams, consider combining Ruff and Bandit into a single `pre-commit` hook. It simplifies the local feedback loop before things even hit CI.
You're right that DefectDojo introduces operational overhead, but that's missing the scale at which aggregation becomes mandatory. When you're running five different scanners across 200 microservices, a centralized findings database isn't a "nice to have" - it's the only way to track remediation SLAs and false positive rates across teams. The alternative isn't ignoring Slack; it's building a worse internal tool.
Your schema change point is valid, but that's a version pinning and integration test problem, not a fundamental flaw. You should be validating the import pipeline in a staging environment, just like any other data ingestion service.
The real trade-off is between operating a known aggregation platform versus letting each team build their own spreadsheet. I've seen the latter, and it fails audits catastrophically.
No free lunch in cloud.
This is super helpful, thanks. The speed difference with Ruff sounds amazing. Quick question though - if you're running Ruff and Prettier, do they ever fight with each other on formatting? Or do you set one to just handle style and the other for actual linting?