Rethinking Python Asserts in SAST
Insights from T-DOSE 2026
Recently I was at the great FOSS conference T-DOSE to learn new tech things and meet great open-minded people. After my talk about Python Code Audit. I had a very interesting discussion about the Python assert statement with some very smart security friends.
But first: if you want to detect the use of Python assert in a codebase on PyPI.org you can just click the link below:
To launch the 100% web version of Python Code Audit.
This version runs locally in your browser with no strings attached. I think it is great and simple way do a quick and good security code analysis on any codebase published on PyPI.org.
For various, especially AI-generated, Python programs you will see a lot of assert statement warnings. The reason Python Code Audit checks on the use of the assert statement is simple: misuse can lead to security vulnerabilities. The assert statement itself is not insecure, but Python Code Audit is created from a zero-trust security perspective. So I think any SAST Python scanner should make you aware if an assert statement is found within the code.
The key reason from a security point of view is that assert statements can be disabled: when Python is run in optimised mode (with the `python -O` or `python -OO` flags, or by setting the `PYTHONOPTIMIZE` environment variable), assert statements are completely ignored.
The special Python `__debug__` built-in variable is also set to False when -O is used. So code that checks if __debug__: will also be removed.
This means that when using `python -O` or `python -OO`, the Python interpreter removes all assert statements from the bytecode. The consequence is that checks where your code depends on assert statements will simply vanish, leaving your application potentially vulnerable.
The nice thing about conferences and seminars is that you can have in-person discussions with people. With an open mind you will learn about each other’s opinions, especially when there is no absolute right or wrong. And in cyber security it is never black and white. Context matters!
Any discussion about why a SAST tool implements a checking rule is good. So regarding the `assert` discussion I got back to my design rationale. I created in Python Code Audit a check because I want a security researcher or security tester to be directly alerted and to investigate the code further in depth. Keep in mind that any SAST tool can only find weaknesses.
A weakness is a flaw, error, poor design choice, or unsafe programming practice in your code that might create security problems under certain conditions.
A vulnerability is a weakness that can be actually exploited by an attacker to compromise the confidentiality, integrity, or availability of your system.
There are some edge use cases thinkable when using `assert` in Python code for production can do no harm, even when code is run using the Python `-O` option.
Use Case #1: Type/State Checking in Hot Loops (Performance Tuning)
You use `assert` to check an internal invariant in a performance-critical loop during development. In production, you deliberately run with `python -O` to remove the check for speed. You accept that if a bug exists, the program might silently corrupt data instead of crashing. This use case is only safe if the corrupted data cannot affect security-critical decisions. In practice, that is very hard to guarantee. From a security perspective, silent data corruption is often worse than a crash.
Use Case #2: Detecting Impossible State Corruption (Fail-Fast)
You use `assert` to check a condition that should literally never be false if your code is bug-free. This is a “programming error detector”, not a runtime guard.
So you could argue for the use of `assert` in production code to check that code is internally consistent.
However, the truth is that almost every running program needs some kind of input from the outside world. And validating all logic will quickly become too complicated to do from a security point of view. So better safe than sorry. Or when you do use `assert` statements in your Python production code, minimally place a marker and a comment with why, so security reviewers at least directly know that you are aware of the possible impact.
Note that preventing code weakness in Python code is only one, but simple, step in designing a good security architecture. In reality you should always practise using the defence in depth principle so that no code weakness can turn into a vulnerability without noticing.
More information: