Book 10 · Testing & QualityPage 26 of 36

Static Analysis

In Turkish: Statik Analiz

Updated September 30, 20262 min read

In short

Static analysis is the automated examination of source code without running it, to find bugs, security vulnerabilities, and quality problems early.

What is static analysis?

Static analysis means inspecting a program's source code, or its compiled form, without executing it, in order to find bugs, security vulnerabilities, and code quality problems. Static means the code is examined at rest. The opposite is dynamic analysis, which observes the program while it runs, as tests, profilers, and fuzzers do.

A static analysis tool parses the code into an abstract syntax tree (AST), a tree-shaped representation of its structure, and often builds graphs of how control and data flow through the program. Checks range from simple pattern matching, such as spotting a hard-coded password, to deep analyses such as type checking, detecting possible null dereferences, finding resource leaks, and taint analysis, which tracks untrusted input, such as a value from an HTTP request, to see whether it can reach a SQL query unchecked. Because no tool can decide every property of every program perfectly, each one balances false positives (warnings about problems that aren't real) against false negatives (real bugs it misses).

Static analysis is like an engineer reviewing a building's blueprints for structural flaws before construction starts, instead of waiting to see whether the building stands. It runs in editors, pre-commit hooks, CI/CD pipelines, and code review, so problems surface minutes after they are written. Security-focused static analysis is often called SAST, short for static application security testing.

Static analysis is often confused with linting. Linting is a lightweight kind of static analysis that looks mainly at style and common mistakes, often one file at a time, while deeper static analysis tools follow data across functions and files to find subtle bugs. A compiler's type checker, such as the TypeScript compiler, is also a form of static analysis. None of these replace tests: tests prove what the code actually does for specific inputs, while static analysis reasons about all possible paths but can't know what the program is supposed to do.

Key takeaways

Static analysis examines code without executing it.
It finds bugs, security vulnerabilities, and quality issues early.
Techniques range from pattern matching to data-flow and taint analysis.
Every tool trades false positives against missed bugs.
Linting and type checking are common forms of static analysis.

Example

Problems a static analysis tool reports without running the codepython

def find_user(conn, username):
    # The tool traces "username" (untrusted input) into a SQL string:
    # warning: possible SQL injection, tainted data reaches a query
    query = f"SELECT * FROM users WHERE name = '{username}'"
    return conn.execute(query).fetchall()

def order_total(items):
    total = 0
    for item in items:
        total += item.price
    return totl  # error: undefined name 'totl'

Readers ask

What is the difference between static and dynamic analysis?

Static analysis examines code without running it, so it can reason about all paths but may raise false alarms. Dynamic analysis observes the program while it runs, such as during tests or fuzzing, so it sees real behavior but only for the inputs it tries.

What is SAST?

SAST stands for static application security testing: static analysis focused on security flaws such as injection vulnerabilities, unsafe cryptography, and hard-coded secrets. It is usually run automatically in the CI/CD pipeline.

Is a linter a static analysis tool?

Yes. A linter is a lightweight static analysis tool focused on common mistakes and style, while more advanced analyzers track data and control flow across a whole codebase.