A null-pointer dereference that only fires when a downstream API times out. Static analysis will not find it. The code path is reachable, the types line up, no rule fires. You need the API to actually time out, in a running process, for the bug to show itself.
Now the opposite. A hardcoded AWS key sitting in a config file that no test ever imports. Dynamic analysis will never execute that line, so it never sees the key. Static analysis reads the file on disk and flags it in milliseconds.
These two examples are the whole argument. Static analysis inspects code as text and structure without running it. Dynamic analysis observes the program as it executes. They catch different bug classes, and the bug class each one misses is exactly the one the other was built to find.
What static analysis sees
Static analysis parses your source into an abstract syntax tree and reasons about it. It never runs the program. That constraint is also its superpower: it can examine every line in the repository, including code paths that no test exercises and branches that almost never run in production.
It is strong on:
- Whole-codebase coverage. Dead code, unreachable branches and untested error handlers all get read. Execution-based tools only see what runs.
- Secrets and dangerous APIs. Committed credentials,
eval, unparameterised SQL,innerHTML, CORS wildcards. Text patterns with clear signatures. The OWASP source code analysis tools reference catalogues the category. - Speed and determinism. No build, no runtime, no environment to stand up. Thousands of files in seconds, and the same input always gives the same output.
- Structure. Circular dependencies, complexity, duplication, import graphs. These are properties of the code as written, not of the code as run.
Implera's scoring engine is built on this foundation. We covered the reasoning in what is deterministic code analysis.
What dynamic analysis sees
Dynamic analysis runs the program and watches what happens: memory access, network calls, actual control flow, real inputs hitting real code. Fuzzers, profilers, runtime sanitisers and dynamic vulnerability scanners all live here.
It is strong on:
- Behaviour that depends on state. Race conditions, memory leaks, use-after-free, deadlocks. None of these exist in the text; they exist in the timeline of execution.
- Real data flow. A SQL injection that survives three layers of helpers can be confirmed by sending an actual payload and watching the query that lands at the database.
- Performance under load. Where the time actually goes, which query runs 400 times, which allocation grows without bound. A profiler measures the running system; no parser can.
- Zero false positives on what it finds. If a dynamic tool triggers a crash, the crash is real. It happened.
Where each one fails
Static analysis cannot judge runtime context. Is this particular eval safe because its input is guaranteed trusted? The parser cannot know. It flags all of them or none, and false positives accumulate until developers learn to ignore the tool.
Static analysis cannot see emergent behaviour. Two functions that are each correct in isolation can deadlock when they interleave. There is no line to point at.
Dynamic analysis only sees what runs. Coverage is its ceiling. The error handler nobody tests, the feature flag nobody flipped, the platform branch that only fires on Windows: invisible. A dynamic tool reporting "no issues" means "no issues on the paths I executed", which is a much smaller claim than it sounds.
Dynamic analysis is expensive to set up and slow to run. You need a buildable, runnable system, representative inputs and an instrumented environment. A fuzzing campaign runs for hours or days, not seconds.
Dynamic findings can be hard to reproduce. A race condition that surfaces once in ten thousand runs is real, but pinning it down is its own project.
| Static analysis | Dynamic analysis | |
|---|---|---|
| Runs the code | No | Yes |
| Coverage | Every line on disk | Only paths executed |
| Speed | Seconds | Minutes to hours |
| False positives | Common | Rare |
| Best at | Secrets, structure, dead code | Races, leaks, real data flow |
| Determinism | High | Variable |
The honest comparison
Neither tool dominates. They fail in opposite directions. Static analysis over-reports (it flags things that turn out to be fine) and reads everything. Dynamic analysis under-reports (it only finds what it manages to execute) and is certain about what it does find.
The practical consequence: static analysis is the right default for continuous, every-commit feedback because it is fast, cheap and complete across the tree. Dynamic analysis is the right tool for the high-stakes properties static analysis structurally cannot reach, run less often because each run costs more.
Most of the security debate frames this as SAST versus DAST, but the same split applies to performance (linters vs profilers) and correctness (type checkers vs fuzzers). Same shape every time: read the code, or run the code.
How to combine them
- Static analysis on every commit. Secrets, dangerous APIs, complexity, dependency vulnerabilities, structure. Fast and deterministic enough to gate merges on. This is where most teams get the highest return per pound spent, and it pairs naturally with the per-PR vs nightly split.
- Dynamic analysis on a schedule or before release. Fuzzing on parsers and untrusted-input boundaries, profiling on hot paths, sanitisers in the test suite for memory-unsafe languages. Slower, deeper, less frequent.
- Map findings to the right layer. A secret is a static finding. A memory leak is a dynamic one. Do not expect either tool to cover the other's territory, and do not trust a clean report from one as evidence about the other.
For the specific patterns static analysis catches well, see security patterns every developer should know.
The bottom line
Static analysis reads the code. Dynamic analysis runs it. The gap between "what the code says" and "what the code does" is exactly where bugs hide, and you need a tool on each side of that gap.
Use static analysis for breadth, speed and gating. Use dynamic analysis for the runtime behaviour static analysis cannot see. Treating either as a complete picture is the mistake.
