If you run a linter on your code today, you have a lot of choices. If you want one that actually looks for security bugs — and is open source — you have far fewer than the ecosystem's size suggests.
We parsed the public analysis-tools.dev catalog (MIT-licensed, 755 tools) to get an actual count instead of a vibe. Here's what fell out.
TL;DR
- Of 755 static-analysis tools in the catalog, 86% are open source — but only 42 are open-source tools whose job is finding security bugs.
- 21 languages that already have an active linting ecosystem (five or more general static-analysis tools each) have zero open-source security scanner. SQL, Shell, PowerShell, Dart, Elixir, Lua, R, Groovy, Clojure and Haskell are on that list.
- Every number here is reproducible from one public dataset. No survey, no vendor list, no "leaders" quadrant.
Why the gap is easy to miss
"Static analysis" and "security scanner" get used interchangeably, and the catalog is full of tools — so it feels like the security-scanner space is crowded. When you split the catalog by what each tool is actually for, the picture changes:
| Slice | Count | Share |
|---|---|---|
| All static-analysis tools | 755 | 100% |
| Open source (any purpose) | 653 | 86.5% |
| Security-focused (SAST) | 69 | 9.1% |
| Open-source and security-focused | 42 | 61% of the security tools |
A general linter tells you a function is too long. A security scanner tells you that a value from request.args reached a SQL string without going through a parameterizer. Both are "static analysis." Only one is looking for the bug that ends up in a CVE. The catalog has 653 of the first kind and 42 of the second.
The 21-language hole
The more interesting finding isn't the total — it's where the 42 aren't.
We took every language that has at least five general static-analysis tools (i.e. a language with a real tooling community, not a niche one) and checked how many have an open-source security scanner. Twenty-one of them have none:
SQL, Shell, Groovy, R, Lua, Dart, PowerShell, Elixir, Clojure, Haskell — and eleven more.
Some of those are load-bearing. Shell and PowerShell run your CI and your production boxes. SQL is where injection lives. Dart ships to phones. If you write those and want an open-source tool that reasons about security specifically, the catalog says you're on your own.
Where the 42 do cluster is unsurprising: Python (13 scanners), Go (12), Java (10), JavaScript (9). The languages with the most security tooling are the ones that already had the most tooling.
How it was measured
Nothing here needs to be taken on faith. The method is three steps against one file:
- License — split proprietary vs. open source using the catalog's license field.
-
Security scope — keep only tools tagged
securityin the catalog taxonomy. - Language coverage — read each tool's language tags and count per language.
The catalog is a single JSON file in a public MIT repo. We publish the parser and the raw counts alongside the study, so you can re-run it and get the same 42 — or disagree with a classification and see exactly which tool moved the number.
# the dataset:
github.com/analysis-tools-dev/static-analysis (data/*.yml)
# our parser + raw counts:
zennoxa.com/research/state-of-oss-sast-2026 -> data.json
Why we bothered
We build a security scanner (Shield), so the honest disclosure is that this map has a self-interested corner. But the count doesn't change based on who's counting — 42 is 42, and the 21-language hole is in the public data whether or not you've heard of us. We'd rather publish the census than a quadrant.
The full breakdown — every language, the license splits, and the reproducible data.json — is here:
→ State of Open-Source SAST 2026
Published by Zennoxa Research. If you think a tool is misclassified, the raw counts are right there — tell us which one.
Top comments (0)