SAST for Python reads your source without running it and flags risky constructs: dynamic code execution, shell commands built from strings, unsafe deserialization, weak hashing and hardcoded passwords. It will not understand your business rules, so treat it as a filter for known bad patterns.
How it works
The documentation for Bandit, a widely used open source Python security linter, describes the approach: parse each file into an abstract syntax tree, run plugins against the nodes, then generate a report. Most Python SAST tools follow that shape, with deeper ones adding data flow tracking from inputs to dangerous calls.
What it typically finds
| Pattern | Why it is risky |
|---|---|
| eval and exec on variable input | Code injection |
| subprocess with shell enabled and built strings | Command injection |
| pickle on untrusted data | Code execution on load |
| yaml load without safe loader | Object construction from input |
| String built SQL | SQL injection |
| MD5 or SHA1 for security use | Weak hashing |
| Literal passwords and tokens | Credential exposure |
Each of these has a safer alternative. See pickle with untrusted data and safe_load versus load.
What it misses
- Logic flaws such as missing authorization checks.
- Vulnerabilities inside dependencies. That is software composition analysis, a different scan.
- Runtime configuration, such as debug mode left on in production.
- Dynamic features like heavy metaprogramming, where static reasoning is limited.
Steps to start
- Run the scanner on the whole repository once and record the baseline count.
- Exclude tests and generated code, but only after reading what is excluded.
- Triage the highest severity and highest confidence findings first.
- Fix or suppress with a written reason. Avoid blanket ignores.
- Run in CI on pull requests and fail only on new high severity findings, so the team is not buried by old debt.
- Pair it with dependency scanning, because most Python projects import far more code than they write.
How Safeguard helps
Safeguard offers dependency scanning and SBOMs, reachability analysis, and autonomous remediation with fix pull requests, which is off by default with every category on Manual. The free scan is the easiest first step.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a finding and look at the code path from input to the risky call.
Quick check
Does SAST find vulnerable Python packages?
No. It analyzes your code. Package vulnerabilities need dependency scanning.
Should I fail the build on every finding?
Not at first. Fail on new high severity findings and work down the old backlog separately.
Sources
- Bandit documentation, home page (fetched 19 October 2026): AST based approach.
Last reviewed: 19 October 2026.
