Skip to content

Commit d0953fb

Browse files
committed
update
1 parent a70e939 commit d0953fb

2 files changed

Lines changed: 60 additions & 0 deletions

File tree

‎fundamentals/ast_vs_taint.md‎

Lines changed: 59 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,59 @@
1+
---
2+
title: AST-Based or Taint Analyse
3+
short_title: AST vs Taint Analyse
4+
---
5+
6+
7+
8+
## AST-based Analysis versus Taint Analysis for SAST in Python
9+
10+
Static Application Security Testing (SAST) for Python commonly relies on two complementary techniques:
11+
1. **AST-based pattern matching** and
12+
2. **taint analysis**.
13+
14+
Understanding their strengths, limitations and trade-offs is essential when selecting or configuring tools to check Python code on weaknesses.
15+
16+
## What is AST-based analysis?
17+
18+
AST-based analysis parses Python code into an Abstract Syntax Tree (AST) and matches patterns against known insecure constructs. Typical detections include:
19+
20+
- Calls to dangerous built-ins such as `eval()`, `exec()`, or `compile()`
21+
- Insecure use of the `subprocess` module (for example with `shell=True`)
22+
- Hard-coded secrets, weak cryptographic algorithms, or unsafe serialisation (`pickle`, `yaml.load`)
23+
- And other local code patterns that can be recognised from the shape of the code alone
24+
25+
Because the technique works directly on the syntax tree produced by Python’s standard `ast` module, it is fast, deterministic and highly trustworthyfor finding security weaknesses in Python code.
26+
27+
## What is taint analysis?
28+
29+
30+
31+
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.
32+
33+
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?”*
34+
35+
## Key observations from a Python security perspective
36+
37+
The following points apply when applying either technique to Python:
38+
39+
* 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.
40+
* 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.
41+
* No method is perfect. Every approach has distinct advantages and disadvantages; the appropriate choice depends on context, risk appetite, performance constraints and maintenance capacity.
42+
* No open-source or commercial SAST scanner is ideal for every Python codebase. Tool authors must continually balance maintainability, usability, performance and the breadth of defect types that can be detected statically.
43+
44+
## Comparison: AST-based checks versus taint analysis
45+
46+
| Aspect | AST Checking | Taint Analysis |
47+
| ------------------------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
48+
| **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. |
49+
| **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. |
50+
| **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. |
51+
| **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. |
52+
| **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. |
53+
| **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. |
54+
55+
## Summary
56+
57+
* **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.
58+
* **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.
59+

‎toc.yml‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -22,6 +22,7 @@ project:
2222
- file: fundamentals/isolated_mode.md
2323
- file: fundamentals/ai_security.md
2424
- file: fundamentals/vulnerabilityscanning.md
25+
- file: fundamentals/ast_vs_taint.md
2526
- file: fundamentals/sast_vs_vulnerabilityscan.md
2627

2728

0 commit comments

Comments
 (0)