# Find Security Bugs: a SpotBugs plugin that reads Java bytecode for vulns

> The OWASP plugin that adds security detectors, taint analysis and hardcoded-secret checks on top of SpotBugs, across Java, Kotlin, Groovy and Scala.

**find-sec-bugs/find-sec-bugs** — The SpotBugs plugin for security audits of Java web applications and Android applications. (Also work with Kotlin, Groovy and Scala projects)

- Repository: https://github.com/find-sec-bugs/find-sec-bugs
- Website: https://find-sec-bugs.github.io/
- Stars: 2,448 · Forks: 488
- Language: Java
- License: LGPL-3.0
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/find-sec-bugs-find-sec-bugs

## A plugin rather than a scanner of its own

The framing in the README is one sentence: Find Security Bugs is the SpotBugs plugin for security audits of Java web applications. That matters more than it sounds. SpotBugs already reads Java bytecode and finds correctness and reliability defects, so this project inherits that analysis engine, that reporting format and the existing integrations, then contributes detectors for vulnerability classes SpotBugs does not model.

The repository description widens the target to Android applications and adds Kotlin, Groovy and Scala projects, which is why the repository carries a separate Kotlin sample module. The topic list is more revealing still: `taint-analysis`, `cwe`, `bytecode`, `static-analysis` and `owasp`. This is dataflow work on compiled classes, not pattern matching over source text.

The licence is LGPL and the project lives under the OWASP name with a Slack channel for discussion. It has 2447 stars, 486 forks and 116 open issues. The last commit to the default branch was 2026-03-26 and the most recent tagged release is version 1.14.0, published in June 2025.

## Taint analysis is the substance behind the detectors

The contribution notes in the README single out taint analysis for injections as the work that needed major refactoring, credited to David Formánek. That is the part of the project worth understanding, because it is what separates this from a list of regex checks.

A taint detector follows a value from where it enters the program to where it is used. A path traversal finding means a parameter was marked tainted at some entry point, carried through one or more calls, and reached a file or stream API. Getting that right requires a model of which sources are dangerous, which sinks are dangerous, and which intermediate calls preserve or launder the taint label, and that model is the hard engineering.

The release history shows the model being extended rather than repeatedly rewritten. Version 1.13.0 added taint propagation for character types in the `java-lang.txt` and `scala.txt` configuration files, and handled string building through `invokedynamic` concatenation on JDK 8 and above. Version 1.14.0 switched garbage-collector bookkeeping to `SoftReference` so a value already collected is not treated as live. Those are the kinds of changes that only make sense once real flows are being followed.

## Detectors added after real incidents

Version 1.12.0 is named Preventing the next Log4Shell, and the reasoning in the release notes is worth reading. Log4j2 was vulnerable to JNDI and LDAP injection, and the note says a small signature issue in Find Security Bugs meant a warning about the risks of `Context.lookup()` might have been possible. That is a candid account of a security tool having a gap in exactly the class of bug it exists to find.

The same release added detectors for `MODIFICATION_AFTER_VALIDATION` and `NORMALIZATION_AFTER_VALIDATION`, which are mass assignment problems: state changed after a bean validation check ran, so a field the validator never saw gets through. It also added Vert.x OAuth2 and CSRF handlers to the known API list.

Version 1.13.0, nicknamed Lucky 13, brought Java 21 support and closed issues where Java 17 was not working and where a Spring entity leak detector crashed on array types. Version 1.14.0 moved the build to JDK 11, added support for the `jakarta` namespace and upgraded SpotBugs to 4.8.3. Reading those three releases in order tells you what breaking a security scanner actually costs when the JDK moves.

## How the samples are laid out and what they reveal

The repository tree is unusually telling, because most of it is test material rather than library code:

```
findsecbugs-samples-java/
findsecbugs-samples-java11/
findsecbugs-samples-jsp/
findsecbugs-samples-kotlin/
findsecbugs-samples-deps/
```

Every finding a detector reports has to be reproducible, so each sample module holds deliberately vulnerable code plus dependencies needed to trigger it. The Java 11 and Kotlin modules exist because detectors that work on one language version or one JVM bytecode level routinely stop working on another, and the only way to know is to keep them under test.

The rest of the tree follows the same logic. `findsecbugs-plugin/` holds the detectors themselves, `cli/` suggests command-line use, `findsecbugs-test-util/` provides assertions for the test fixtures, and `website/` builds the documentation site. Alongside them are `CHANGELOG.md`, `CONTRIBUTING.md` and `SECURITY.md`, so the project has the administrative surface of a mature OWASP effort.

## Where it runs, and where the documentation stops

The README's integration story is three screenshots: Eclipse, IntelliJ and Android Studio, and SonarQube. That is the whole list of supported environments as far as the README goes, and it is enough to establish the intended usage pattern, which is a SpotBugs run you already have in your build rather than a separate security tool you schedule.

What the README does not do is teach you to configure anything. There is no sample Maven or Gradle invocation, no list of enabled detector categories, no guidance on filtering false positives and no mention of how the plugin behaves in a large multi-module build. That material sits on the project website, and the per-detector descriptions with their CWE references live at h3xstream.github.io, linked from the contributions section. The README explicitly points readers there, but it is worth knowing that adopting this means leaving the README.

The people behind it are named, which is unusually useful context for a security project. Philippe Arteau and Tomáš Polešovský lead it, the latter from Liferay, and GoSecure has funded development since 2016, covering new detectors and research into vulnerability classes. Detector quality here depends on ongoing research rather than on volume of code.

## Conclusion

Find Security Bugs earns its place by doing one narrow job properly: it does not replace SpotBugs, it loads detectors into it, so security findings arrive in the same report, the same Eclipse and IntelliJ panels and the same SonarQube import that a team already runs. The taint analysis for injection is the substantial piece, and the samples tree shows how seriously that is tested across Java, Kotlin, JSP and Java 11 variants. Where it is thin is documentation and detector-level guidance, since the README names contributors and screenshots but leaves configuration to the website. The concrete starting point is version 1.14.0 with SpotBugs 4.8.3, and the detector list at h3xstream.github.io/find-sec-bugs/bugs.htm is where the CWE mappings live.

## FAQ

### What does Find Security Bugs check for that SpotBugs does not?

It adds vulnerability-class detectors on top of SpotBugs, including taint analysis for injection paths, hardcoded passwords and cryptographic keys, mass assignment problems such as MODIFICATION_AFTER_VALIDATION, and framework-specific patterns for Spring, Play and Vert.x. SpotBugs still does the underlying bytecode analysis and reporting.

### Is Find Security Bugs still maintained?

The repository is not archived. The last push to the default branch was 2026-03-26 and the newest release is version 1.14.0 from June 2025, which upgraded SpotBugs to 4.8.3, moved the build to JDK 11 and added jakarta namespace support. There were 116 open issues.

### How do I configure Find Security Bugs in a Maven or Gradle build?

The README does not include a build configuration example, so this is answered on the project website rather than in the repository documentation. The practical path is to add the findsecbugs-plugin artefact to your existing SpotBugs plugin list and then choose detector categories on the project site.

### What is the difference between SpotBugs and Find Security Bugs?

SpotBugs analyses Java bytecode for correctness and reliability defects. Find Security Bugs is an LGPL-licensed plugin that runs inside SpotBugs and contributes detectors for security issues, including taint analysis across injection paths, plus the framework-specific and cryptographic checks SpotBugs does not model.

## Sources

- [find-sec-bugs/find-sec-bugs on GitHub](https://github.com/find-sec-bugs/find-sec-bugs)
- [License: LGPL-3.0](https://github.com/find-sec-bugs/find-sec-bugs/blob/master/LICENSE)
- [Project website](https://find-sec-bugs.github.io/)
- [README](https://github.com/find-sec-bugs/find-sec-bugs/blob/master/README.md)
- [Releases](https://github.com/find-sec-bugs/find-sec-bugs/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/find-sec-bugs-find-sec-bugs