# analysis-tools-dev/static-analysis: A Curated Index of Static Analysis Tools, Not an Analyzer > The repository is a data-driven catalogue of linters, SAST scanners and formatters across dozens of languages, rendered into README.md and a JSON API by a small Rust tool in ci/. It is useful for picking a tool, not for running one. **analysis-tools-dev/static-analysis** — ⚙️ A curated list of static analysis (SAST) tools and linters for all programming languages, config files, build tools, and more. The focus is on tools which improve code quality. - Repository: https://github.com/analysis-tools-dev/static-analysis - Website: https://analysis-tools.dev - Stars: 14,817 · Forks: 1,513 - Language: Rust - License: MIT - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/analysis-tools-dev-static-analysis ## What the repository actually is, and who it is for This is not a static analyzer. It is a curated list, and the README opens with a warning that you should not edit it directly: the source of truth lives in data/tools/ and the README is generated. The stated focus is tools that improve code quality, such as linters and formatters, across all programming languages, build tools and config files. The official website, analysis-tools.dev, is built on top of this repository and adds rankings, user comments and resources like videos for each tool. The audience is therefore narrow and specific. If you are starting a project in a language you do not know well and need to find a linter, this saves you a search. If you maintain a platform team and want a machine-readable inventory of analyzers to cross-reference against your CI pipeline, the generated JSON API is the useful artifact. If you want something that reads your source tree and reports findings, you are in the wrong repository entirely, and the README never suggests otherwise. ## How the data flows from YAML to README and JSON The repository layout makes the pipeline visible. There is a data/ directory holding tags.yml, tools/ and collections/, a ci/ directory containing a Cargo workspace, and a Makefile that wires the two together. The render target is the whole mechanism: ```bash cargo run --manifest-path ci/Cargo.toml --locked -p render -- --tags data/tags.yml --tools data/tools --collections data/collections --md-out README.md --json-out data/api ``` One binary, named render, reads the tag definitions, the per-tool YAML files and the collections, then writes two outputs: README.md and a JSON tree under data/api. The --locked flag means the build uses the committed lockfile, so a contributor's local run matches CI. A second target, render-skip-deprecated, passes --skip-deprecated and uses cached deprecation data instead of making GitHub requests. That second target is the interesting design detail. Deprecation status is not stored statically in the YAML; the renderer fetches it, and the skip variant exists so you can render without network access. The README's symbol legend confirms the semantics: the warning symbol means the tool was not updated for more than one year or its repository was archived, and the information symbol means the community does not recommend the tool for new projects, linking to the discussion issue. Deprecation here is partly a live property of the upstream project, not a frozen editorial judgement. ## Installing and rendering the list locally There is no package to install. The project is consumed by cloning it and running the Rust renderer, which requires a Rust toolchain; the repository pins one in rust-toolchain.toml. The Makefile's help target prints the available commands, and the default target is help, so running make with no arguments is safe. To produce the README and the JSON API from the YAML sources: ```bash make render ``` The command shells out to cargo run with the arguments shown earlier, so you should see Cargo compile the render workspace on first run, then the process exit after writing README.md and the data/api directory. If you want to avoid the network calls that resolve deprecation status, use the cached path instead: ```bash make render-skip-deprecated ``` For contributors, the Makefile also exposes check, clippy, fmt, fmt-check, test and clean, all of which operate on the manifest at ci/Cargo.toml. The clippy target runs with --all-features and -D warnings, which means lint warnings fail the build rather than being reported and ignored. If you only want to browse tools, none of this is necessary: the README is committed and readable on GitHub, and analysis-tools.dev presents the same data with rankings and comments. ## The contribution bar, and why entries disappear CONTRIBUTING.md sets explicit criteria: at least six months of history, 20 GitHub stars, and more than one human contributor. The README repeats them and adds a blunt instruction: do not submit tools before they qualify, and pull requests with verified criteria failures will be closed, with resubmission welcome once the criteria are met. That is a deliberate trade-off. A six-month age floor and a two-person minimum filter out single-author weekend projects and abandoned experiments, which is the point. But it also means a genuinely good tool written by one person is invisible here regardless of quality, and a tool that has two contributors but poor design passes. The star threshold is a proxy for attention, not correctness. The README also states that star counts are part of the entry criteria, which is a statement about admission, not a claim about the tool's merit; treat any list entry as meeting a floor, not as an endorsement. The warning symbol is the one signal that actively argues against adoption, and it is applied automatically when a repository is archived or has gone more than a year without an update. ## What it cannot tell you, and when to look elsewhere The list records that a tool exists, what language it targets, and whether it is proprietary or stale. It does not record detection quality, false-positive rates, runtime cost on a real codebase, or how well the tool integrates with a given CI system. Nothing in the repository layout suggests any of that is measured. A tool marked as current and community-recommended can still be a poor fit for your project, and the list will not warn you. The symbol legend is also coarse. The warning fires on either of two conditions, an archived repository or no update for more than a year, and the README does not distinguish between them in the rendered output. A mature, feature-complete tool that intentionally stopped changing looks the same as an abandoned one. If that distinction matters to you, you have to open the linked repository and check for yourself. The obvious alternative is to go directly to a language-specific roundup, such as the linter documentation maintained by a language community, or to a hosted platform that runs the analyzers for you rather than listing them. The difference in approach is that this repository is a static, editorially gated index with a machine-readable export, while a hosted platform executes tools against your code and reports results. Neither replaces the other. This one is for choosing; those are for running. If you need a decision made for you rather than a candidate set, the list will frustrate you. ## Maintenance cost, licensing and the generated-file rule The repository is MIT-licensed, and the LICENSE file sits at the top level. That covers the list content and the renderer. It does not cover the tools being listed: each entry points at its own project with its own licence, and the README marks proprietary software with the copyright symbol. A few entries in the README carry that symbol, including Polyspace for Ada, SPARK and Astrée. Do not read the MIT licence at the top of this repository as covering anything but this repository. The upgrade cost is low by design. The renderer is a Rust workspace under ci/ with a pinned toolchain in rust-toolchain.toml and a lockfile, invoked with --locked, so builds are reproducible. The maintenance burden falls on contributors rather than consumers: adding a tool means editing a YAML file under data/tools/, not the README, and the README's first line says so in capital letters. If you fork the repository and edit README.md directly, your changes will be overwritten the next time anyone runs make render. That is the single most common way to misuse this project. For consumers who only read the output, there is nothing to upgrade. The JSON API under data/api is regenerated on the project's own schedule; the last push to the repository was on 2026-09-21. ## Conclusion Adopt this repository if you need a vetted starting point for choosing linters or SAST tools across many languages, or if you want the generated JSON API as input to your own tooling. Do not adopt it expecting an analyzer: nothing here inspects your code. Before relying on it, verify that the specific tool you pick is not marked with the warning symbol for being unupdated for more than a year or archived, and check CONTRIBUTING.md's criteria (six months of history, 20 GitHub stars, more than one human contributor) against the entry. The repository itself is MIT-licensed, but each listed tool carries its own licence, and the copyright symbol marks proprietary entries that are not open source at all. ## FAQ ### What is analysis-tools-dev/static-analysis? It is a curated list of static analysis tools, linters and formatters for all programming languages, build tools and config files, with a focus on tools that improve code quality. The README is generated from YAML sources in data/tools/ by a Rust renderer in ci/, and the analysis-tools.dev website is based on the same repository. ### Does this repository run static analysis on my code? No. It is an index of tools, not an analyzer. The README lists tools and links out to them, and the renderer only reads YAML files and writes README.md and a JSON API; nothing in the repository inspects a source tree. ### How do I render the README and JSON API from the YAML sources? The Makefile's render target runs the render package from ci/Cargo.toml with --tags data/tags.yml, --tools data/tools, --collections data/collections, --md-out README.md and --json-out data/api. A render-skip-deprecated target does the same using cached deprecation data instead of making GitHub requests. ### What do the warning and information symbols next to a tool mean? The warning symbol means the tool was not updated for more than one year or its repository was archived. The information symbol means the community does not recommend the tool for new projects, and it links to the relevant discussion issue. ### What are the criteria for adding a tool to the list? CONTRIBUTING.md requires at least six months of history, 20 GitHub stars and more than one human contributor. The README states that pull requests with verified criteria failures will be closed, and that a tool can be resubmitted once the criteria are met. ### What is the difference between static and dynamic analysis? The repository does not define either term; it catalogues static analysis tools and points to a sister project, awesome-dynamic-analysis, for the other category. The listed tools examine code without executing it, which is the distinction the split implies, but the README itself does not explain it. ## Sources - [analysis-tools-dev/static-analysis on GitHub](https://github.com/analysis-tools-dev/static-analysis) - [Issues](https://github.com/analysis-tools-dev/static-analysis/issues) - [License: MIT](https://github.com/analysis-tools-dev/static-analysis/blob/master/LICENSE) - [Project website](https://analysis-tools.dev) - [README](https://github.com/analysis-tools-dev/static-analysis/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/analysis-tools-dev-static-analysis