Pysa

Pysa is a free, open-source static analyzer for Python that traces potentially unsafe data through code. It suits teams that want to define their own security checks and run analysis in a self-hosted workflow. Its focused taint analysis is a strong fit for Python code review, provided teams can manage its visibility limits, tuning needs, and memory demands.

Overview

Pysa tracks data from configured sources, such as user-controlled request input, to dangerous sinks such as an eval call. That focus helps identify risky flows across application code, rather than only isolated suspicious expressions. The repository says it can analyze codebases with millions of lines, but large-scale capability does not guarantee a smooth run: projects of similar size may freeze when the machine lacks enough memory.

Analysis is limited to the target repository and directories included in the configured search_path. Source code in dependencies outside those paths is invisible, which can leave flows across package boundaries unresolved. When Pysa encounters a function whose source it cannot access, it assumes the return value retains the input's taint. That conservative behavior can raise false positives and add review work.

Key features

Configurable models and sanitizers

Teams can define sources, sinks, features, and rules in taint.config, then annotate code with .pysa model files. Prewritten models cover built-in and common Python libraries, giving projects a useful base while still requiring teams to describe application-specific flows. Sanitizer models can mark parameters or return values as removing taint, which helps represent where data is made safe. The flexibility is valuable for codebases with distinct security boundaries, but it also means teams need the expertise and time to maintain meaningful models.

Editor and results workflow

Pyre supports the Language Server Protocol, and its VSCode extension connects to a running server. The documented workflow uses SAPP to ingest Pysa findings and provides a local web interface for viewing and filtering issues. This gives reviewers a way to triage results without relying only on raw output. The GitHub Action can run Pysa in CI and display findings in GitHub's Security code scanning UI; its default SAPP filters favor higher-signal output, with the trade-off that some genuine issues may be missed.

Installation uses pip install pyre-check in a Python virtual environment. Pysa requires Python 3.9 or later and currently relies on type information from Pyrefly.

Pricing

Pysa is open source under the MIT license. The Free plan costs nothing and covers Python static analysis installed with pip. There is no paid tier in this plan structure; users take on the work of configuring and running the tool themselves.

Platforms

Pysa supports Linux, macOS, Windows, extensions, and self-hosted deployment. It analyzes source code and supports CI/CD, making it suited to teams that want findings in their existing development workflow rather than a hosted-only service.

Who it's for

Pysa is best for Python teams that need configurable taint analysis, can maintain source and sink models, and want to keep analysis within their own environment. It is less suitable for teams seeking broad dependency visibility without configuring search paths, or those without enough memory for analysis on a large codebase. Teams with limited capacity to triage false positives should also weigh the default filtering trade-off before adopting it.

Pros and cons

• Configurable taint rules: Teams can model application-specific sources, sinks, and sanitizers instead of being limited to built-in checks.
• Local and CI review options: SAPP offers a local findings interface, while the GitHub Action can surface results in Security code scanning.
• Free and MIT-licensed: Teams can use and self-host the tool without a software charge.
• Bounded code visibility: Dependencies outside configured paths are not analyzed, and inaccessible function source can lead to false positives.
• Operational and coverage trade-offs: Large analyses may freeze on machines with insufficient memory, while higher-signal default filters can trade false positives for false negatives.
• Maintenance status: The Pyre repository was archived on June 26, 2026, and says Pysa moved to its own repository; teams should account for that transition when evaluating maintenance.

Alternatives

For a broader comparison, browse Static Application Security Testing Software.

• Skylos is worth considering for teams that want a freemium option with local CLI scans plus a cloud tier capped at one project, 10 stored scans, and seven-day history on its free plan.
• Horusec is another free, open-source option, with CLI and platform components under Apache License 2.0.
• Puma Scan may suit readers who prefer a free community edition with a paid End User license at $299 a year.
• Semgrep Code is an alternative for teams that want a free edition covering code and supply chain for up to 10 repositories and 10 contributors, with 60 AI credits.
• Snyk Open Source is a different option for software composition analysis, with a free plan capped at five projects.
• MobSF is another free, open-source choice, with its Community Edition licensed under GPL v3.
• Microsoft DevSkim may fit teams seeking a free MIT-licensed library, CLI, and IDE extensions.
• NodeJsScan is a free, self-hosted alternative with Docker or local setup.

Verdict

Choose Pysa if your team needs Python-specific taint analysis, wants control over its models and deployment, and can budget for tuning and resource use. Its strongest reason to choose it is the combination of configurable source-to-sink analysis and a self-hosted CI workflow at no software cost. Look elsewhere if you need dependencies analyzed automatically beyond configured paths, or if the risk of false positives and missed findings would make your review process hard to manage.