Quick Verdict
Semgrep and SpotBugs address Java static analysis from opposite architectural directions. SpotBugs (the successor to FindBugs) works on compiled Java bytecode, detecting bug patterns, correctness issues, and - with the FindSecBugs plugin - security vulnerabilities at the JVM bytecode level. Semgrep works on Java source code, matching patterns using an AST representation and tracing data flows across files using its Pro engine.
This architectural difference is the most important thing to understand about this comparison. SpotBugs sees your code after compilation, with full type resolution and JVM-level information. Semgrep sees your code before compilation, with source-level pattern matching and cross-file taint tracking. Neither approach is strictly superior - they detect different categories of issues, and the tools are more complementary than competitive.
The comparison matters for Java teams because both tools appear prominently in Java security and quality tooling discussions. SpotBugs has two decades of Java ecosystem presence and is the community standard for JVM bytecode analysis. Semgrep has grown rapidly as the programmable SAST standard for teams that need custom rules and multi-language support. Understanding where each tool excels determines whether you need one, the other, or both.
Choose SpotBugs (with FindSecBugs) if: you need Java-specific correctness bug detection (null pointer dereferences, resource leaks, concurrency bugs, serialization issues), already compile your code in CI, want free and open-source analysis with no configuration overhead, and are specifically focused on Java or JVM languages.
Choose Semgrep if: you need cross-file taint analysis for injection vulnerabilities, want custom organization-specific security rules, work across multiple languages beyond Java, need Spring Boot or Spring Security framework-specific rules, or want AI-powered triage to reduce false positive noise.
The optimal setup for most Java teams: Run SpotBugs with FindSecBugs on compiled bytecode for correctness and API-misuse detection, and run Semgrep on source code for cross-file taint tracking, framework-specific rules, and custom organizational checks. These tools detect fundamentally different issue categories with minimal overlap.
At-a-Glance Comparison
| Category | Semgrep | SpotBugs |
|---|---|---|
| Analysis target | Java source code (AST) | Compiled Java bytecode (.class, .jar) |
| Type | Multi-language programmable SAST | Java/JVM bytecode bug pattern analyzer |
| Languages | 30+ (Java, Kotlin, JS, TS, Go, Python, etc.) | Java, Kotlin (partial), Groovy (partial), Scala (partial) |
| Security focus | Built-in via rulesets and taint analysis | Requires FindSecBugs plugin |
| Correctness bugs | Limited - pattern-based only | Extensive - null pointers, resource leaks, concurrency |
| Custom rules | Yes - YAML, mirrors Java syntax | Very limited - requires writing Java detector code |
| Cross-file taint tracking | Yes (Pro engine, paid tier) | No |
| Framework-specific rules | Yes - Spring, Hibernate, Jakarta EE | Partial - via FindSecBugs patterns |
| AI triage | Yes - Semgrep Assistant (paid tier) | No |
| Build requirement | None - runs on source files | Requires successful compilation |
| CI/CD integration | Native - any CI, GitHub Actions built-in | Maven plugin, Gradle plugin |
| Pricing (free tier) | OSS CLI free; full platform free for 10 contributors | Completely free and open source |
| Paid pricing | $35/contributor/month (Team tier) | No paid tier - always free |
| Maintained by | Semgrep, Inc. (commercial) | Community (SpotBugs GitHub org) |
| License | LGPL-2.1 (OSS) / commercial (Pro) | LGPL-2.1 |
| SARIF output | Yes | Yes |
| IDE integration | VS Code extension, IntelliJ plugin | IntelliJ, Eclipse, NetBeans plugins |
| SCA / dependency scanning | Yes - Semgrep Supply Chain (Pro) | No |
| Secrets detection | Yes - Semgrep Secrets (Pro) | No |
| Multi-module projects | Yes - source-level cross-file analysis | Yes - can scan all bytecode, but no cross-method taint |
What Is SpotBugs?
SpotBugs is the community-maintained successor to FindBugs, a Java bytecode analysis tool that has been part of the Java ecosystem since the early 2000s. When FindBugs development halted around 2016, the open-source community forked it as SpotBugs and has continued development to support modern Java versions through Java 21, improved bytecode parsing for lambda expressions, streams, records, and sealed classes, and better IDE integrations.
SpotBugs works by analyzing compiled Java bytecode (.class files or packaged .jar archives). It reads the bytecode, reconstructs a control flow graph, and runs hundreds of built-in bug detectors against it. The detectors look for well-defined anti-patterns at the bytecode level. This bytecode-level approach gives SpotBugs access to type-resolved information - it knows the exact types of method parameters, return values, and field accesses in ways that source-level tools must sometimes approximate.
SpotBugs bug categories cover a broad set of Java-specific concerns:
- Correctness (C): Null pointer dereferences that cannot occur, infinite loops, incorrect use of equals(), bit operations with signed integers, method calls on potentially null references
- Bad Practice (B): Non-serializable fields in serializable classes, dropping exceptions, incorrect implementation of equals/hashCode/compareTo contracts
- Performance (P): Unnecessary object creation, inefficient collection usage, string concatenation in loops
- Dodgy code (D): Dead code, unused return values from non-void methods, redundant comparisons, confused use of null return values
- Multithreaded Correctness (M): Synchronization on non-final fields, double-checked locking without volatile, methods that should be synchronized
- Malicious Code Vulnerability (V): Returning references to mutable arrays from public methods, public static mutable fields
Note the conspicuous absence of security categories in this base list. For security-focused analysis, SpotBugs requires the FindSecBugs plugin - a separately installed plugin that adds over 130 security bug patterns covering OWASP Top 10 categories including SQL injection, XSS, path traversal, LDAP injection, XXE, insecure deserialization, weak cryptography, and hard-coded credentials.
SpotBugs integrates tightly with the Java build ecosystem. The Maven plugin (com.github.spotbugs:spotbugs-maven-plugin) and Gradle plugin (com.github.spotbugs) both run as part of the standard build lifecycle. IDEs including IntelliJ IDEA, Eclipse, and NetBeans have SpotBugs plugins that show findings inline in the editor.
The core limitation of SpotBugs is the absence of cross-method, cross-class taint tracking. SpotBugs can detect that a method calls Statement.execute() with a string argument, but it cannot determine whether that string originated from an HTTP request parameter that traveled through three service classes to reach this point. This structural limitation means SpotBugs and FindSecBugs miss the majority of real-world injection vulnerabilities in layered enterprise Java applications following standard MVC or hexagonal architecture patterns.
What Is Semgrep?
Semgrep is a multi-language programmable static analysis engine. Originally developed at Facebook and now maintained by Semgrep, Inc., it takes a source code pattern matching approach fundamentally different from SpotBugs. Rather than analyzing compiled bytecode, Semgrep parses Java source files into an AST and matches patterns expressed in YAML using syntax that mirrors the Java code being analyzed.
Semgrep's Java support spans the full modern Java language including generics, lambdas, streams, records, sealed classes, and annotations. The Semgrep registry includes Java-specific rulesets covering OWASP Top 10 for Java, Spring Security misconfigurations, Hibernate and JDBC injection patterns, deserialization vulnerabilities, XXE via Java XML parsers, and Crypto API misuse.
Semgrep operates across three tiers:
Community Edition (free, open source): The core Semgrep engine under LGPL-2.1. Single-file and single-function analysis. Includes the community registry with 2,800+ rules across all supported languages. Runs as a CLI requiring no login or cloud connection.
Team tier ($35/contributor/month, free for up to 10 contributors): The full Semgrep AppSec Platform. Adds cross-file dataflow analysis via the Pro engine, taint tracking, Semgrep Assistant (AI-powered triage), 20,000+ Pro rules, centralized dashboards, Semgrep Supply Chain (SCA with reachability analysis), and Semgrep Secrets (credential detection with live validation).
Enterprise (custom pricing): SSO/SAML, custom deployment options, advanced compliance reporting, dedicated support, and SLAs for large organizations.
For Java specifically, Semgrep's most meaningful advantage over SpotBugs is the Pro engine's cross-file taint tracking. A taint rule specifies sources - where untrusted data enters the application (Spring @RequestParam, @PathVariable, @RequestBody, servlet request.getParameter()) - and sinks - where that data would be dangerous (JDBC execute(), Hibernate createNativeQuery(), Runtime.exec(), ObjectInputStream.readObject()). Semgrep traces taint from sources to sinks across any number of intermediate classes, method calls, and module boundaries, flagging confirmed injection paths while reducing false positives on paths where data is internally controlled.
For a detailed review of Semgrep's capabilities and pricing structure, see our Semgrep review.
Feature-by-Feature Breakdown
Java Security Rule Coverage
The security coverage of these two tools differs substantially in depth, especially for applications following standard Java enterprise architecture patterns.
SpotBugs plus FindSecBugs provides solid coverage of well-known vulnerability patterns. FindSecBugs adds over 130 security bug detectors including injection detection for SQL, XSS, LDAP, and command injection; cryptographic API misuse (weak algorithms, predictable random, hard-coded IV); insecure deserialization patterns; XXE via JAXP XML parsers; path traversal via file operations; and Spring-specific patterns like missing @EnableWebSecurity or overly permissive CORS configurations. This coverage addresses the OWASP Top 10 reasonably well for the patterns it can detect at the bytecode level.
Semgrep extends security coverage into cross-file data flow detection. Beyond the pattern-based detection that SpotBugs and FindSecBugs provide, Semgrep's taint tracking catches injection vulnerabilities that span multiple classes - the category of vulnerability most common in real enterprise Java applications that follow layered architecture patterns.
Consider a typical Spring Boot application:
// UserController.java
@RestController
public class UserController {
@Autowired
private UserService userService;
@GetMapping("/users")
public List<User> searchUsers(@RequestParam String query) {
return userService.findUsers(query); // user input enters here
}
}
// UserService.java
@Service
public class UserService {
@Autowired
private UserRepository userRepository;
public List<User> findUsers(String searchTerm) {
return userRepository.search(searchTerm); // taint propagates through service
}
}
// UserRepository.java
@Repository
public class UserRepository {
@Autowired
private JdbcTemplate jdbcTemplate;
public List<User> search(String term) {
String sql = "SELECT * FROM users WHERE name LIKE '%" + term + "%'";
return jdbcTemplate.query(sql, new UserRowMapper()); // SQL injection sink
}
}
SpotBugs with FindSecBugs sees three compiled class files. It may flag the string concatenation in UserRepository.search() as a potential SQL injection - but it cannot confirm whether term derives from user input or from an internal caller with a safe constant value. The result is likely a low-to-medium confidence finding that requires manual investigation of the call chain.
Semgrep's taint tracking traces @RequestParam String query as a tainted source in UserController, follows it through the userService.findUsers() call in UserService, and confirms it reaches the JDBC query() call in UserRepository - producing a high-confidence, confirmed SQL injection finding with the full call chain shown in the report.
Bug Pattern and Correctness Detection
This is the category where SpotBugs is genuinely stronger than Semgrep, and it addresses real categories of Java bugs that Semgrep cannot effectively detect.
SpotBugs excels at Java-specific correctness bugs that manifest at the bytecode level. These include:
- Null pointer dereferences: SpotBugs models nullability through bytecode analysis, identifying paths where null is returned from a method and then dereferenced without a null check. False positive rates are relatively low because bytecode provides precise type information.
-
Resource leaks: SpotBugs tracks
CloseableandAutoCloseableobjects through bytecode control flow, flagging cases where streams, connections, or file handles may not be closed on all execution paths including exception paths. -
Concurrency bugs: SpotBugs detects unsynchronized access to fields that are accessed from multiple threads, double-checked locking implemented incorrectly (without
volatile), and lock acquisition ordering issues that could lead to deadlocks. -
Serialization correctness: SpotBugs checks serialization compatibility - non-serializable fields in
Serializableclasses, missingserialVersionUID, and classes that implementExternalizableincorrectly. -
equals/hashCode contract violations: SpotBugs detects classes that override
equals()but nothashCode(), violating the Java contract that equal objects must have equal hash codes, leading to bugs when used in hash-based collections.
Semgrep's source-level pattern matching cannot reliably detect most of these categories. Detecting resource leaks, concurrency bugs, and nullability issues requires the kind of control flow and data flow analysis across a compiled artifact that bytecode provides. Semgrep's patterns can detect syntactic indicators of these problems - for example, calling .execute() on a variable declared outside a try-with-resources block - but cannot perform the full reachability analysis that makes SpotBugs's detection reliable.
This is the clearest case where SpotBugs provides value that Semgrep cannot replicate.
Custom Rule Authoring
For organizations with internal security policies or proprietary API patterns that require custom static analysis checks, rule authoring capability is critical.
SpotBugs offers extremely limited custom rule authoring. Writing a new SpotBugs detector requires implementing the Detector interface in Java, understanding SpotBugs's visitor architecture for bytecode traversal, packaging the detector as a plugin JAR, and deploying it to the team's build configuration. This is a non-trivial engineering effort that requires understanding both SpotBugs's internal architecture and JVM bytecode. Most Java development teams lack the specialized knowledge to write custom SpotBugs detectors, making customization effectively unavailable without dedicated security engineering resources.
Semgrep's custom rule system is the most accessible in the SAST industry. Rules are written in YAML using patterns that mirror Java source code. A custom rule to detect use of a deprecated internal authentication API looks like this:
rules:
- id: deprecated-internal-auth
patterns:
- pattern: |
$X.authenticate($USER, $PASS)
- pattern-inside: |
import com.example.internal.LegacyAuthClient;
...
message: >
LegacyAuthClient.authenticate() is deprecated and bypasses MFA.
Use com.example.auth.AuthService.authenticateWithMFA() instead.
severity: ERROR
languages: [java]
metadata:
category: security
cwe: "CWE-308"
Any Java developer who can read Java can understand this rule. Writing it takes under 30 minutes for a developer seeing Semgrep for the first time. Deploying it across all repositories in the organization takes minutes by adding it to the shared Semgrep policy. This capability is transformative for organizations that need to enforce internal security standards - ensuring all API clients use the approved authentication wrapper, flagging direct database access that bypasses the auditing layer, detecting use of deprecated cryptography utilities, or encoding compliance requirements as checkable rules.
Analysis Without Compilation
A practical difference that matters significantly in CI/CD pipeline design is whether a tool requires compiled bytecode.
SpotBugs requires a successful compilation. You cannot run SpotBugs analysis until your code compiles. In CI/CD pipelines, this means the security scan runs after the build step - any build failure prevents the security scan from running. In development, it means SpotBugs cannot run on code with compile errors, which is common during active development of new features.
Semgrep runs on Java source files without compilation. This enables several workflow options unavailable with SpotBugs: running security checks as a pre-commit hook before the developer has compiled the code, scanning on PR creation before CI build time is consumed, running in environments where Java build tooling is not configured, and scanning partially complete code for early security feedback.
For teams that want to shift security checks as far left as possible - to the developer's workstation before code is committed - Semgrep's ability to run without a build step is a meaningful practical advantage.
Multi-Language and Polyglot Support
SpotBugs is a JVM-ecosystem tool. It analyzes Java, and through compiled bytecode can partially analyze Kotlin, Groovy, and Scala. It has no awareness of JavaScript, TypeScript, Python, Go, Terraform, or any non-JVM language. Teams with polyglot stacks need separate tools for each non-JVM component.
Semgrep supports 30+ languages with a unified rule engine. Java Spring Boot backend, TypeScript React frontend, Python data pipeline, Terraform infrastructure definitions, Docker configurations, and Go microservices can all be scanned with Semgrep using the same CLI, the same configuration model, and the same centralized findings dashboard. Custom rules written in one language can reference the same organizational severity levels, metadata taxonomy, and policy enforcement approach as rules in other languages. This unification matters for security teams managing multi-language codebases - it eliminates the overhead of learning and maintaining separate tools for each language.
For Java-only teams with no polyglot requirements, this advantage is irrelevant. For teams with a full-stack or microservices architecture, it represents significant reduction in tooling complexity.
Pricing Comparison
SpotBugs Pricing
SpotBugs is completely free. It is an open-source project under the LGPL-2.1 license with no paid tier, no enterprise edition, no usage limits, and no account required. FindSecBugs is similarly free and open source. The SpotBugs Maven and Gradle plugins are free. IDE plugins are free.
The total licensing cost of SpotBugs plus FindSecBugs is zero, for any team size, any codebase size, and any commercial use. The only costs are developer time for initial configuration, filter file maintenance as false positives are identified, and integration work for custom reporting.
Semgrep Pricing
| Tier | Price | What You Get |
|---|---|---|
| Community Edition (OSS) | Free | Open-source engine, 2,800+ community rules, single-file analysis, CLI and CI/CD, no login required |
| Team | $35/contributor/month (free for first 10 contributors) | Cross-file taint analysis, 20,000+ Pro rules, Semgrep Assistant (AI triage), Semgrep Supply Chain (SCA with reachability), Semgrep Secrets, centralized dashboard |
| Enterprise | Custom | Everything in Team plus SSO/SAML, custom deployment, advanced compliance reporting, dedicated support, SLA guarantees |
For complete pricing details, see our Semgrep pricing guide.
Cost Comparison at Different Team Sizes
| Team Size | SpotBugs | Semgrep Community | Semgrep Team |
|---|---|---|---|
| 1-10 developers | $0 | $0 | $0 (free for 10 contributors) |
| 20 developers | $0 | $0 | $8,400/year |
| 50 developers | $0 | $0 | $21,000/year |
| 100 developers | $0 | $0 | $42,000/year |
For teams of 10 or fewer contributors, both SpotBugs and the full Semgrep Team platform are available at zero cost - making the small team decision purely about capability rather than budget. For teams beyond 10 contributors who need Semgrep's Pro engine with cross-file taint analysis, the cost should be evaluated against the risk profile of the application and the cost of missing injection vulnerabilities that single-file analysis structurally cannot catch.
Alternatives to Consider
If neither Semgrep nor SpotBugs alone meets your Java security scanning needs, several alternatives and complementary tools are worth evaluating.
SonarQube is the most widely deployed Java static analysis platform in enterprise environments. It combines code quality metrics (bugs, code smells, duplication, complexity) with security detection covering OWASP Top 10 for Java. SonarQube performs dataflow analysis at the source level, similar to Semgrep but with tighter Java ecosystem integration including Maven and Gradle quality gates. The Community Build is free and self-hosted. SonarQube Cloud offers free analysis for open-source projects and paid plans for private repositories. See our Semgrep vs SonarQube comparison for a detailed breakdown.
Checkmarx is a commercial SAST platform with strong Java and Spring support, deep taint analysis, and compliance reporting. It is positioned for enterprise compliance-driven security programs (PCI DSS, HIPAA, SOC 2) and provides more extensive reporting and remediation guidance than open-source tools. Its pricing is significantly higher than Semgrep's Team tier. See our Semgrep vs Checkmarx comparison for details.
Snyk Code provides Java SAST with interfile dataflow analysis powered by the DeepCode AI engine. Snyk Code integrates naturally with Snyk Open Source for dependency vulnerability scanning and Snyk Container for container image analysis - making it compelling for teams that want a unified Snyk platform. Snyk Code has strong Spring Boot coverage and IDE integration for early developer feedback. See our Snyk vs Semgrep comparison for a side-by-side breakdown.
Coverity by Synopsys is a commercial static analysis platform known for very low false positive rates in C, C++, and Java analysis. Coverity performs deep path-sensitive analysis with sophisticated interprocedural tracking. It is typically used in safety-critical and compliance-heavy environments where false positive management is paramount and licensing costs are less constrained. For standard Java web application security, Semgrep or SonarQube provides comparable detection at lower cost.
CodeAnt AI is a broader platform combining AI code review, SAST, secrets detection, code quality metrics, and DORA analytics in a single tool at $24-40/user/month. For Java teams that want to consolidate AI-assisted pull request review with security scanning under one vendor, CodeAnt AI provides a bundled alternative to assembling separate tools. It is not as deep as Semgrep for custom taint rules or as battle-tested as SpotBugs for JVM correctness bugs, but reduces the number of tools and vendors a team must manage.
For a broader view of the Java SAST landscape, see our best SAST tools comparison and our Semgrep alternatives guide.
Use Cases - When to Choose Each Tool
When SpotBugs Is the Right Choice
JVM-specific correctness bugs are a priority concern. If your team has experienced or is concerned about null pointer exceptions, resource leaks, concurrency errors, or serialization issues in production - SpotBugs is uniquely capable in this space. No other free tool performs bytecode-level null pointer dereference analysis or resource leak detection with comparable coverage and accuracy for Java. For teams working on Java applications where these correctness bugs cause production incidents, SpotBugs should be part of the CI pipeline regardless of what other tools are used.
The codebase is exclusively Java or JVM languages. If your entire stack is Java, Kotlin, Groovy, or Scala with no polyglot components, SpotBugs's JVM focus is an advantage rather than a limitation. You get purpose-built analysis for your specific platform without the overhead of multi-language tooling.
Zero security tooling budget. SpotBugs plus FindSecBugs provides free OWASP Top 10 coverage for Java at no cost. For projects with genuinely zero budget - open-source projects, internal tools, educational projects, early-stage startups - this is meaningful security coverage without licensing costs.
Teams already running Maven or Gradle builds. Adding SpotBugs to an existing Maven or Gradle build is minimal effort - add the plugin, configure FindSecBugs, and run mvn spotbugs:check or gradle spotbugsMain. If your CI already runs mvn package, adding SpotBugs takes under an hour of configuration work.
Security review of third-party or legacy JAR files. SpotBugs can analyze any .jar or .class file, including compiled libraries where you do not have source code. Semgrep requires source files. For teams conducting security assessments of third-party dependencies or legacy compiled code without available source, SpotBugs with FindSecBugs is the relevant tool.
When Semgrep Is the Right Choice
Java web applications that handle user input. If your Java application is a web application that accepts input from external users via REST APIs, web forms, or GraphQL endpoints - cross-file taint analysis is necessary to detect injection vulnerabilities in layered architectures. Semgrep's Pro engine traces user input from Spring MVC controller parameters through service classes to JDBC, Hibernate, or Elasticsearch queries, catching the injection paths that SpotBugs structurally cannot detect.
Teams using Spring Boot or Spring Security. Semgrep's Spring-specific rulesets detect misconfigurations in Spring Security filter chains, missing authentication annotations, insecure CORS configurations, SpEL injection, and improper use of Spring's data binding - patterns that SpotBugs does not have purpose-built detectors for.
Custom internal security policies. If your organization has specific security requirements - mandatory use of internal authentication libraries, prohibition of direct JDBC in favor of audited data access objects, required use of organization-specific encryption wrappers - Semgrep's YAML rule authoring lets you encode these policies as checkable rules in hours. SpotBugs custom detector development is inaccessible to most Java teams.
Polyglot or microservices teams. If your architecture includes Java services alongside JavaScript frontends, Python data pipelines, Go microservices, or Terraform infrastructure, Semgrep scans all components with the same tool and presents findings in a unified dashboard. SpotBugs covers only the JVM components.
Teams of 10 or fewer contributors who want enterprise-grade scanning. The Semgrep full platform - including cross-file taint analysis, AI triage, 20,000+ Pro rules, and the centralized dashboard - is free for up to 10 contributors. There is no reason for a small Java team to limit themselves to SpotBugs when the full Semgrep platform is available at no cost.
Early-phase development where compilation is not yet stable. Semgrep runs on source files without requiring a successful build. Teams working on new features where the codebase does not compile cleanly can still run Semgrep scans on the source files. SpotBugs is unavailable until the code compiles.
When to Use Both Together
The strongest Java security posture for most teams combines both tools because they detect different categories of issues with minimal overlap:
SpotBugs in the build pipeline (post-compilation): After mvn package or gradle build succeeds, run spotbugs:check with the FindSecBugs plugin. This catches null pointer dereferences, resource leaks, serialization errors, concurrency bugs, and the security patterns FindSecBugs detects at the bytecode level. Configure the Maven or Gradle plugin to fail the build on HIGH severity findings.
Semgrep in source-level CI and pre-commit checks: Run Semgrep on Java source files on every pull request. Configure Spring-specific and OWASP Top 10 rulesets, plus any organization-specific custom rules. In the paid tier, the Pro engine's cross-file taint analysis flags confirmed injection paths. The diff-aware scanning mode ensures only changed files are re-analyzed on PRs, keeping scan times short.
This combination provides both the bytecode-level correctness checking that SpotBugs excels at and the source-level taint tracking that Semgrep excels at - covering the full spectrum of Java security and quality concerns neither tool addresses alone.
The Verdict
SpotBugs and Semgrep are different tools solving different problems in the Java quality and security space. The question is not which one to use - it is understanding which categories of issues each one covers.
SpotBugs (with FindSecBugs) owns the JVM bytecode analysis space. For null pointer dereferences, resource leaks, concurrency errors, serialization issues, and pattern-based security detection at the bytecode level, SpotBugs is the authoritative free option. Every Java team should run SpotBugs as part of their build pipeline. It costs nothing, catches real bugs, and its bytecode-level analysis finds issues that source-level tools cannot reliably detect.
Semgrep owns the programmable source analysis space. For cross-file taint analysis, custom organizational security rules, framework-specific patterns, multi-language coverage, and AI-powered triage, Semgrep provides capabilities that SpotBugs cannot. Java web applications that handle external user input need cross-file taint analysis to detect injection vulnerabilities in layered architectures - and Semgrep's Pro engine provides this.
For small Java teams (1-10 contributors): Use SpotBugs with FindSecBugs in your Maven or Gradle build pipeline for bytecode-level correctness and security checks, and add the free Semgrep Team platform for cross-file taint analysis and framework-specific rules. Both are free at this team size. There is no reason to choose one over the other.
For medium Java teams (10-50 contributors): SpotBugs remains free and should stay in the build pipeline. The decision is whether Semgrep Team at $35/contributor/month is justified for cross-file taint analysis. For Java web applications processing external user input, the answer is yes - injection vulnerabilities in layered architectures represent significant business risk, and cross-file analysis is the only way to detect them reliably.
For larger teams or organizations with compliance requirements: Evaluate SonarQube as a quality gate platform alongside Semgrep for security taint analysis, or consider Checkmarx for compliance-focused deep analysis. Teams wanting consolidated AI-assisted code review alongside security scanning should evaluate CodeAnt AI ($24-40/user/month) or Snyk Code as alternative platforms.
The bottom line: if you write Java, run SpotBugs. If you write Java web applications that handle user input, also run Semgrep. These tools are teammates, not competitors - and together they cover the Java quality and security landscape more completely than either does alone. For a broader picture of where these tools fit in the Java security ecosystem, see our best SAST tools comparison and our Semgrep alternatives guide.
Further Reading
- Checkmarx vs Veracode: Enterprise SAST Platforms Compared in 2026
- Codacy vs Checkmarx: Developer Code Quality vs Enterprise AppSec in 2026
- Codacy vs Semgrep: Unified Platform vs Composable Security Engine (2026)
- DeepSource vs Coverity: Static Analysis Platforms Compared (2026)
- DeepSource vs Semgrep: Static Analysis Tools Compared (2026)
Frequently Asked Questions
Is SpotBugs still actively maintained in 2026?
SpotBugs is maintained but development has slowed considerably compared to commercial tools like Semgrep. The last major release added Java 21 support, but SpotBugs has not added cross-module dataflow analysis, AI-powered triage, or custom rule authoring capabilities comparable to modern SAST platforms. It remains the authoritative open-source Java bytecode analysis tool and is production-ready for its intended purpose - catching well-defined bug patterns in compiled Java bytecode. Teams that need custom organization-specific rules, multi-language support, or cross-file taint tracking will find SpotBugs insufficient and should evaluate Semgrep alongside it or as a replacement.
Can SpotBugs detect SQL injection in Java?
SpotBugs can detect some SQL injection patterns through its companion FindSecBugs plugin, which must be installed separately. FindSecBugs adds OWASP Top 10 coverage including injection detectors that work at the bytecode level. However, SpotBugs and FindSecBugs cannot perform cross-class, cross-module taint tracking the way Semgrep's Pro engine can. If user input arrives in a Spring MVC controller, passes through a service class, and reaches a JDBC call in a data access object, SpotBugs sees isolated bytecode methods and may not connect the flow. Semgrep's taint-tracking mode traces data from annotated sources (HTTP request parameters) to sinks (JDBC execute calls) across all classes and modules, providing significantly higher detection rates for real-world injection vulnerabilities in layered Java applications.
Does SpotBugs work with Gradle and Maven builds?
Yes. SpotBugs has official Maven and Gradle plugins that are widely used. The SpotBugs Maven plugin (com.github.spotbugs:spotbugs-maven-plugin) runs analysis as part of the Maven site lifecycle or on demand. The SpotBugs Gradle plugin (com.github.spotbugs) integrates into Gradle builds similarly. Both produce HTML, XML, and SARIF report formats. The major requirement is that SpotBugs analyzes compiled bytecode, meaning your project must compile successfully before SpotBugs can scan it. This is a meaningful practical difference from Semgrep, which analyzes Java source code directly and does not require a successful build, making Semgrep more accessible in early development phases and broken build scenarios.
What is the difference between FindBugs and SpotBugs?
SpotBugs is the direct successor to FindBugs, which was abandoned by its original maintainers around 2016. When FindBugs development halted, the community forked the project and continued development under the SpotBugs name. SpotBugs added Java 8 through Java 21 support, improved bytecode parsing for modern Java features (lambdas, streams, records, sealed classes), better IDE integration, and continued detector maintenance. If you are using FindBugs today, you should migrate to SpotBugs - FindBugs does not support Java 9+ module syntax, streams, or modern annotation processors correctly. SpotBugs is the actively maintained community standard for Java bytecode analysis, though it has not fundamentally changed its architectural approach from FindBugs.
Can Semgrep analyze compiled Java bytecode?
No. Semgrep analyzes Java source code, not compiled bytecode. This is the fundamental architectural difference between Semgrep and SpotBugs. Semgrep requires .java source files as input and uses a parsed AST representation of the source code to match patterns and trace data flows. SpotBugs requires compiled .class files or .jar archives and works at the bytecode level. The practical implication is that Semgrep can run earlier in the development lifecycle - before compilation, directly on source files - while SpotBugs requires a successful compile step. SpotBugs gains access to type-resolved information from bytecode that source-level tools sometimes must approximate, but Semgrep's taint tracking at the source level provides broader cross-file analysis coverage.
Is FindSecBugs included with SpotBugs by default?
No. FindSecBugs is a separate plugin that must be explicitly added to your SpotBugs configuration. SpotBugs itself focuses on correctness bugs - null pointer dereferences, resource leaks, incorrect API usage, threading errors, and similar non-security issues. Security-focused detection (SQL injection, XSS, path traversal, LDAP injection, cryptographic weaknesses, deserialization issues) requires the FindSecBugs plugin (com.h3xstream.findsecbugs). Without FindSecBugs, SpotBugs provides almost no SAST-relevant security findings. This is an important distinction when comparing SpotBugs to Semgrep for security purposes - the fair comparison is SpotBugs plus FindSecBugs versus Semgrep, not SpotBugs alone.
Does Semgrep support Spring Boot and Spring Security rules?
Yes. Semgrep's registry includes rules specifically for Spring Boot and Spring Security. Spring-specific rules include detection of missing @PreAuthorize or @Secured annotations on controller methods, incorrect Spring Security configuration patterns, CSRF disabled in SecurityFilterChain configurations, insecure CORS configurations in Spring MVC, use of deprecated and insecure Spring cryptography utilities, and Spring Expression Language (SpEL) injection patterns. Framework-aware rules for Spring are available in both the community registry and the Pro rule library, and the Pro engine can trace user input from Spring MVC request mappings (@RequestParam, @PathVariable, @RequestBody) through service layers to JDBC, JPA, and Hibernate calls.
How do SpotBugs and Semgrep handle false positives differently?
SpotBugs manages false positives through a filter XML file (exclude.xml) that suppresses specific bug patterns on specific classes or methods, and through @SuppressFBWarnings annotations in source code. The filter approach requires manually identifying each false positive and creating an exclusion entry - it is effective but requires ongoing maintenance as the codebase grows. Semgrep manages false positives through inline nosemgrep comments for individual suppressions and, in the paid tier, through Semgrep Assistant - an AI-powered triage system that assesses each finding's exploitability and confidence. Semgrep's taint tracking also reduces structural false positives by understanding data flow, reducing cases where a dangerous-looking call is actually safe because the input is internally controlled.
Can I use SpotBugs and Semgrep together in CI/CD?
Yes, and this combination provides complementary coverage that neither tool achieves alone. SpotBugs (with FindSecBugs) excels at detecting Java-specific correctness bugs, concurrency issues, resource leaks, and bytecode-level patterns like incorrect serialization that source-level tools can miss. Semgrep excels at cross-file taint analysis, custom organization-specific rules, multi-language scanning (Java plus JavaScript frontend plus Terraform IaC), and AI-powered triage. Running SpotBugs in the build pipeline after compilation and Semgrep on source files provides both bytecode-level correctness checking and source-level security taint tracking. The tools have minimal finding overlap - they detect fundamentally different categories of issues using fundamentally different analysis approaches.
What is the best Java static analysis tool for a Spring Boot microservices team?
For a Spring Boot microservices team, the recommended stack is Semgrep with Spring-specific rulesets as the primary SAST tool, SpotBugs with FindSecBugs for bytecode-level correctness and security checks, and Snyk Code or OWASP Dependency-Check for dependency vulnerability scanning. Semgrep handles cross-service taint analysis and custom organizational rules - critical for teams where user input flows through API gateways, authentication layers, and service clients before reaching sensitive operations. SpotBugs catches Java-specific issues that source analysis misses: concurrency bugs, resource leaks, serialization problems. For teams that want a single commercial platform covering SAST, SCA, and secrets, Snyk Code plus Snyk Open Source provides strong Java coverage. CodeAnt AI at $24-40/user/month is another option for teams wanting AI-assisted code review bundled with security scanning.
Does SpotBugs support Kotlin or Groovy?
SpotBugs has partial Kotlin support through the Kotlin compiler's ability to generate JVM bytecode that SpotBugs can analyze. However, because SpotBugs works at the bytecode level, it analyzes Kotlin code as compiled JVM bytecode rather than as Kotlin source. This means SpotBugs can detect some issues in Kotlin code that manifest at the bytecode level, but it misses Kotlin-specific patterns, cannot apply Kotlin-aware rules, and produces findings that reference JVM internals rather than Kotlin source constructs. Groovy similarly compiles to JVM bytecode and is partially analyzable. Semgrep, by contrast, has dedicated Kotlin support with source-level pattern matching and Kotlin-specific rules in its registry, making it significantly more effective for Kotlin analysis than SpotBugs.
How does Semgrep pricing compare to SpotBugs for a 50-person Java team?
SpotBugs is completely free - no licensing costs at any team size. For a 50-person Java team, Semgrep Community Edition is also free, providing source-level pattern matching and community rules without cross-file taint analysis. Semgrep Team (which adds cross-file taint tracking, AI triage, 20,000+ Pro rules, and the centralized platform) costs $35 per contributor per month - approximately $21,000 per year for 50 contributors. The business case for Semgrep Team vs SpotBugs free comes down to whether cross-file taint analysis catches vulnerabilities that prevent security incidents. For Java web applications handling external user input, the injection vulnerabilities that cross-file analysis catches are among the highest-impact vulnerability classes. The cost comparison should be made against the cost of a serious injection vulnerability rather than against zero.
Originally published at aicodereview.cc
Top comments (0)