Pysa

Pysa is a free, MIT-licensed Python tool for tracing potentially unsafe data flows through code. It follows data from configured sources to dangerous sinks, such as request input reaching an `eval` call. Users define sources, sinks, features, and rules in `taint.config`, and add code models in `.pysa` files. Pysa also includes models and rules for built-in and common Python libraries, plus ways to describe sanitizers that remove taint from parameters or return values.

It analyzes the target repository and configured `search_path` directories, and can handle codebases with millions of lines. It requires Python 3.9 or later and relies on type information from Pyrefly. Installation uses `pip install pyre-check` in a Python virtual environment. Pyre supports the Language Server Protocol, with a VSCode extension that connects to a running server. Results can be ingested with SAPP for viewing and filtering in a web interface, or surfaced in GitHub's Security code scanning UI through a GitHub Action. Pysa is self-hosted and available for Linux, macOS, and Windows.

Pysa offers configurable taint analysis, library models, and CI reporting for Python repositories. Its analysis scope and memory needs are practical constraints, and its repository status should be considered: Pyre was archived in June 2026, with Pysa moved to its own repository.

Pysa suits Python developers and security teams looking to trace tainted data in repositories, including through CI. Teams should be able to provide adequate memory and configure the code paths they want analyzed.

Pysa is a free, open-source static security analyzer for Python. It is best suited to teams that want to trace potentially unsafe data through their own code and tailor those checks to application-specific flows. Its focused taint analysis and CI reporting are compelling, provided the team can work within its source-visibility and memory constraints.

Overview

Pysa tracks data from defined sources to dangerous sinks, such as user-controlled request data reaching an eval call. That makes it useful for reviewing how input moves through an application, not just spotting isolated risky patterns. The repository says Pysa can analyze codebases with millions of lines, but the quickstart cautions that analysis may freeze on similarly sized projects when memory is insufficient. Scale is therefore possible, not effortless.

Its view is limited to the target repository and directories configured in search_path. Dependency source outside those paths is invisible, which can leave flows across external packages unresolved. When Pysa cannot access a function's source, it assumes the return value retains the input's taint; that conservative assumption can produce false positives and add review work.

Key features

Models tuned to Python code

Teams 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, offering a starting point while still requiring teams to describe application-specific behavior. Sanitizer models can mark parameters or return values as removing taint, which helps represent where data is made safe rather than treating every flow as equally risky.

Editor and CI workflow

Pyre supports the Language Server Protocol and has a VSCode extension that connects to a running server. For automated checks, a GitHub Action can run Pysa and surface results in GitHub's Security code scanning UI. The quickstart also uses SAPP to ingest results and provides a local web interface for viewing and filtering issues. These paths make Pysa workable in developer and CI routines, though the documented filtering trade-off matters: default SAPP filters aim for higher-signal results and may miss some findings in exchange for fewer false positives.

Requirements and maintenance

Pysa requires Python 3.9 or later and relies on type information from Pyrefly. It can be installed with pip install pyre-check in a Python virtual environment. The Pyre repository was archived on June 26, 2026, and Pysa moved to its own repository; teams choosing it should account for that project transition when evaluating maintenance risk.

Pricing

Pysa is free and open source under the MIT license, with no paid tier or seat charge described. The Free plan costs nothing and provides Python static analysis installed with pip. That makes it an accessible option for individual developers and teams able to host and operate their own analysis; the trade-off is that resource needs, model configuration, and result handling remain part of the team's workflow.

Platforms

Pysa is self-hosted and runs on Linux, macOS, and Windows, with extension support. Its analysis target is source code, and CI/CD support is available through the GitHub Action. This suits teams that want findings inside repository workflows rather than a hosted scanning service.

Who it's for

Pysa is a strong fit for Python teams that need configurable taint analysis, can include relevant source in their configured paths, and have enough memory for repository-scale runs. It is less suitable when important flows depend on source code outside the repository and search paths, or when a team needs analysis that avoids conservative false positives without ongoing tuning.

Pros and cons

• Configurable taint analysis: Teams can model their own sources, sinks, sanitizers, and rules, making checks adaptable to application-specific risks.
• Useful workflow options: GitHub code scanning integration, VSCode support, and SAPP's local issue interface offer several ways to act on results.
• Dependency blind spot: Code outside the repository and configured search paths is not analyzed, limiting visibility into cross-package flows.
• False-positive and false-negative trade-offs: Missing function source can lead to conservative taint assumptions, while default SAPP filtering may suppress some findings to improve signal.
• Memory demands and project transition: Large analyses can freeze on machines without enough memory, and Pysa's move from the archived Pyre repository is a maintenance consideration.

Alternatives

Browse static application security testing software for more options. Consider MobSF instead for a free, open-source option with Android, iOS, API, web, Linux, and self-hosted platforms. Puma Scan has a free community plan and a paid End User plan at $299 a year, so it may suit readers comparing free and annual-license options. Skylos offers local CLI scans without login on its free plan, plus a cloud allowance of 1 project, 10 stored scans, and 7-day history. Snyk Open Source may fit teams seeking software composition analysis, with its free plan covering 5 projects and access to Snyk Open Source. Dawnscanner is a free, MIT-licensed Ruby security scanner that runs locally from the command line. Horusec is another free, open-source option, under Apache License 2.0, with CLI and platform components. Microsoft DevSkim offers a free MIT-licensed library, CLI, and IDE extensions. NodeJsScan is a free, self-hosted option for Docker or local setup.

Verdict

Choose Pysa if your team needs configurable Python taint analysis and wants to bring findings into CI or a local review interface without paying a license fee. Its main advantage is the ability to model application-specific flows; its main reason to look elsewhere is the combination of bounded source visibility, tuning trade-offs, memory demands, and the recent repository move.