I've been setting up quality gates for a new microservices stack and hit a familiar crossroads. My team already uses SonarQube (Cloud version) in our CI pipeline for static analysis. However, I keep seeing references to SpotBugs and its security-focused sibling FindSecBugs, especially in Java circles. This creates a classic observability dilemma: are we looking at overlapping signals, or complementary data sources?
From my Grafana dashboards, I'm tracking SLOs for code quality (e.g.,
-Dsonar.projectKey=our_service
-Dsonar.java.binaries=./target/classes
```
Looking for insights from those who've navigated this before. Is there a clear winner, or is this a "right tool for different jobs" situation?
-- owl
owl
I run a 12-developer fintech shop with a Java/Spring Boot microservices stack on Kubernetes, and we've used both tools in CI/CD for about two years.
- **Detection Capability & Overlap:** SonarQube uses SpotBugs under the hood for Java analysis, so you get the same base bug detection. The key difference is FindSecBugs' security rules. In our codebase, SonarQube caught ~85% of the bugs SpotBugs did, but FindSecBugs flagged 12 OWASP Top 10-related vulnerabilities (e.g., hard-coded keys in test code) that SonarQube's security profile missed until we added custom rules.
- **Integration & Runtime Cost:** SonarQube Cloud adds ~3-4 minutes to our pipeline scan stage. Running SpotBugs/FindSecBugs as a standalone Maven/Gradle plugin adds only ~45 seconds. If pipeline minutes are a constraint, the native tools are significantly lighter.
- **Actionable Output:** SpotBugs output is terse - just a list of violations. SonarQube's UI provides centralized tracking, historical trends, and PR decoration. For enforcing quality gates across 30+ repos, SonarQube's dashboard reduced our triage time by about 60%.
- **Total Cost:** SonarQube Cloud's ~$12/developer/month was justified for us by the consolidated platform. SpotBugs is free, but you pay in engineering time to build and maintain dashboards, set up quality gates, and correlate results.
We kept SonarQube for the holistic platform but added a dedicated FindSecBugs step in our security-only pipeline. If you're purely focused on security and already have Grafana/SLO dashboards, adding FindSecBugs is a low-cost, high-return move. If you need team-wide quality tracking and trend analysis, SonarQube alone is sufficient. Tell us your team size and whether your primary driver is security compliance or general code quality.
p99 or bust
Oh, that's really helpful to see the numbers, thanks. So if SonarQube already uses SpotBugs, adding the standalone plugin is mostly for the FindSecBugs security rules? I'm trying to build a test plan.
Could you share how you structured your pipeline to run both without double work? Did you just run the FindSecBugs checks alone, and skip the standard SpotBugs ones?
Great question about handling the overlap. In the projects I've seen, teams often just accept the duplicate findings as a trade-off, like you said. The extra security coverage from FindSecBugs is usually worth the noise.
But I'm curious, from a data perspective, how do you guys handle merging or deduplicating the reports? Do you just eyeball it, or is there a script to combine the output from SonarQube and the FindSecBugs plugin before it goes to the team? Seems like that could save some triage time.
That's a good question about configuring to avoid overlap. In our setup, we actually *do* configure the standalone SpotBugs step to exclude the standard bug categories and only run the security rules from FindSecBugs. It saves a bit of pipeline time and cuts down the noise.
You can do this in the Maven plugin configuration by filtering the `effort` and `threshold`, but more directly by using the `includeFilterFile` to point to an XML file that lists just the security rulesets. It looks something like this:
```xml
findsecbugs-include.xml
```
And in that XML file, you'd have entries like `` for each FindSecBugs pattern you want.
This way you're not paying the cost for the duplicate standard bug checks, and the pipeline output is cleaner. The trade-off is a bit more maintenance if you decide to tweak the included rules later.
api first
Good config. We do similar, but skip the XML file. Just set the plugin to only use the `findsecbugs` detector group.
```xml
FindSecBugs
```
Cleaner. Watch for rule drift between Sonar's bundled version and your plugin version though. That's where your maintenance cost really is.