Pysa

Pysa is a Python-focused static analyzer that follows potentially unsafe data through an application. It best suits security-minded Python teams that can maintain their own analysis configuration and CI environment. Its strongest fit is configurable, self-hosted taint checking; teams with opaque dependencies or limited build memory should be cautious.

Overview

Pysa traces values from declared sources to dangerous sinks, such as request data reaching an eval call. That data-flow view can expose vulnerabilities spanning multiple functions, rather than only matching isolated code patterns. The project says it can analyze codebases with millions of lines, but large analyses still depend on adequate machine memory.

Scanning covers the target repository and directories named in search_path. Source for dependencies outside those paths is not analyzed, which can hide behavior at package boundaries. Pysa requires Python 3.9 or later and currently depends on type information from Pyrefly.

Key features

Tunable taint rules

Teams define sources, sinks, features, and rules in taint.config, then add code-specific models in .pysa files. Built-in models for Python's standard and common libraries provide a foundation, while custom models let a security team represent its own frameworks. Sanitizer definitions can mark return values or parameters as clean, so legitimate validation points can be reflected in the analysis.

Developer and findings workflow

Pyre supports the Language Server Protocol, and its VSCode extension connects to a running server. The documented workflow sends Pysa output to SAPP, whose local web interface supports viewing and filtering findings. That combination is practical for teams that want findings close to code and a separate triage view, but it adds services to operate.

Automation

A GitHub Action runs Pysa in CI and publishes results in GitHub's Security code scanning interface. Its default SAPP filters favor higher-signal output, a useful way to reduce alert volume that can also miss some true issues. Pysa is self-hosted and distributed under the MIT license. The Pyre repository was archived on June 26, 2026; Pysa has moved to its own repository, so teams should track that separate project for ongoing maintenance.

Pricing

There are no seat charges or usage quotas attached to this plan. It fits individuals and organizations able to run and maintain their own Python tooling. In exchange for the zero price, you provide the infrastructure, configuration work, model maintenance, and result triage; there is no hosted service tier described for teams that want those responsibilities managed.

Platforms

Pysa is available as an extension and runs on Linux, macOS, Windows, and self-hosted deployments. Installation starts with pip install pyre-check inside a Python virtual environment. CI use is supported through the GitHub Action, while the editor path is centered on VSCode and a running server.

Who it's for

Pysa is a strong choice for Python application teams with security engineers who can write taint models, include relevant source directories, and operate CI and local findings services. It is particularly appropriate when tracing user-controlled input to high-risk operations is more valuable than broad language coverage.

Look elsewhere if your risk analysis depends heavily on third-party code that cannot be added to search_path, if build machines have tight memory limits, or if you need a managed scanner rather than self-hosted components. Unavailable function source can lead Pysa to assume returned data remains tainted, creating false positives that require model tuning.

Pros and cons

• Pro: Source-to-sink tracking targets exploitable data flows, including input reaching calls such as eval.
• Pro: Custom configuration, library models, and sanitizer annotations let teams adapt checks to their own frameworks.
• Pro: GitHub Actions and Security code scanning provide a direct CI reporting path.
• Pro: Free MIT-licensed software avoids subscription cost and supports self-hosting.
• Con: Dependencies outside configured search paths are invisible, limiting cross-package analysis.
• Con: Missing function source can produce false positives; high-signal filtering may instead trade toward false negatives.
• Con: Insufficient memory can freeze analysis on projects of similar scale, adding infrastructure planning to adoption.

Alternatives

Skylos is worth choosing when you want a freemium option with local CLI scans plus a cloud project, stored scans, and history. Snyk Open Source fits teams seeking hosted software-composition analysis with a free monthly plan and paid collaboration tier. Horusec provides a free Apache-licensed CLI and platform for a broader self-hosted security workflow. MobSF is the better match for Android and iOS application testing. Puma Scan offers a free open-source community edition alongside a paid annual end-user license. Semgrep Code is preferable when you need hosted code and supply-chain scanning with repository and contributor limits on its free edition. Flawfinder is a free GPL-licensed option for its supported scanning approach. Microsoft DevSkim suits teams wanting a free MIT-licensed library, CLI, and IDE extensions. Browse the Static Application Security Testing Software directory for more choices.

Verdict

Choose Pysa if you want no-cost, self-hosted Python taint analysis that can be tailored to application-specific sources, sinks, and sanitizers and enforced in GitHub CI. Choose another tool when dependency visibility, managed operation, predictable memory use, or lower tuning overhead matters more than deep control of Python data-flow rules.