AST-Based or Taint Analyse - Python Security Handbook

AST-based Analysis vs Taint Analysis for SAST¶

Static Application Security Testing (SAST) for Python commonly relies on two complementary techniques:

AST-based pattern matching and
taint analysis.

Understanding their strengths, limitations and trade-offs is essential when selecting or configuring tools to check Python code on weaknesses.

What is AST-based analysis?¶

AST-based analysis parses Python code into an Abstract Syntax Tree (AST) and matches patterns against known insecure constructs. Typical detections include:

Calls to dangerous built-ins such as eval(), exec(), or compile()
Insecure use of the subprocess module (for example with shell=True)
Hard-coded secrets, weak cryptographic algorithms, or unsafe serialisation (pickle, yaml.load)
And other local code patterns that can be recognised from the shape of the code alone

Because the technique works directly on the syntax tree produced by Python’s standard ast module, it is fast, deterministic and highly trustworthy for finding security weaknesses in Python code.

What is taint analysis?¶

Taint analysis tracks the flow of untrusted data (tainted data) from sources (for example request.args, file reads, environment variables or network input) through assignments, function calls, and transformations to sinks (SQL execution, command execution, HTML rendering, file-system operations, etc.). The analysis flags paths where tainted data reaches a sink without adequate sanitisation or validation.

A taint analyses tries to track the flow of untrusted data (or “tainted” data) though a program to validate if correct preventive measurements to avoid vulnerabilities are taken. In essence, taint analysis answers the question: “Can attacker-controlled input influence a dangerous operation?”

Key observations¶

From a Python security perspective keep in mind the following observations:

Python’s dynamic features—duck typing, late binding, getattr/setattr, decorators, metaclasses, first-class functions, *args/**kwargs, dynamic imports and framework “magic” (Flask/Django/FastAPI request handling, ORMs, dependency injection)—make complete and precise static reasoning difficult. Inter-procedural and cross-file taint tracking is particularly hard to get correct in a generic way.
There is no widely adopted, directly usable open test suite that gives an open unbiased report of SAST capabilities of various Python SAST tools. Research evaluations therefore rely on synthetic benchmarks or limited real-world CVE collections.
No method is perfect. Every approach has distinct advantages and disadvantages; the appropriate choice depends on context, risk appetite, performance constraints and maintenance capacity.
There is no perfect open-source or commercial SAST scanner for every Python codebase. Tool authors must continually balance maintainability, usability, performance and the breadth of defect types that can be detected statically.

Comparison: AST-based checks versus taint analysis¶

Aspect	AST Checking	Taint Analysis
Core strength	Fast detection of security anti-patterns and known unsafe constructs (e.g. `eval`).	Detects data-flow issues (injection families, SSRF, path traversal, etc.) even when source and sink are separated by helpers, modules or framework layers.
Speed / Scalability	Very fast and lightweight; low resource use. Excellent for CI/CD gates.	Slow and resource-intensive, especially for inter-procedural, cross-file or path-sensitive analysis. Large codebases may require aggressive heuristics.
Ease of implementation & rules	Straightforward to maintain custom and general checks.	Complex: requires accurate source/sink/sanitiser definitions, call-graph construction, alias analysis and handling of containers/comprehensions. Customisation is hard.
Coverage of vulnerability types	Strong on dangerous APIs, weak cryptography and custom local patterns. Limited context awareness;	Strong on SQL/command/LDAP/XSS/path injection and (with persistent tracking) second-order issues. Highly effective for classic injection vulnerabilities. Weak on logic or authorisation flaws that lack a clear taint.
Accuracy considerations	Very high, but cannot track data flow across files or complex dynamic objects.	Rules and models are complex to create and maintain. Incomplete modelling easily produces a false sense of security; configuration burden often falls on the user.
Python-specific challenges	Perfect for handling Python syntax and constructs (list/dict comprehensions, decorators, etc.). Not all dynamic Python syntax options can be captured.	Severely challenged by dynamic dispatch, attribute lookup, exceptions, generators, monkey-patching and framework magic. Framework-aware modelling (Django, Flask, FastAPI) is usually required for useful results.

Summary¶

AST-based checking is simple, fast and highly effective at detecting common weaknesses in Python code. Security tools and controls that are based on the ast are simple to maintain and tend to be more effective in practice.
Taint analysis is theoretically more powerful for locating the vulnerabilities that matter most (especially injection flaws). In practice it is complex to implement correctly for general Python code, often slower, requires substantial configuration, and remains incomplete because of the language’s dynamic nature.