Dynamic analysis

What it means

Dynamic analysis means examining software while it is running. You send it input, watch what it does, and judge the behaviour: the responses, the errors, the files it touches, the calls it makes. The program is treated as a thing that acts, not a text to be read. Results are judged by what happened, not by what the author intended.

For web security this usually means sending requests to a live copy of the app and checking what comes back. It sees the real system with its real settings, and with the proxies, caches and configuration around it, which is something reading the code can only guess at.

Why it matters

Many flaws only exist in the running system. A setting in production, a proxy in front of the app, a framework that behaves differently than the code suggests. Dynamic analysis finds these because it looks at the result, not the intention, and a working request is hard to argue with.

Its limit is reach. It can only test what it can get to, and it cannot tell you which line of code is at fault. That is why it is paired with static analysis or with testing that has the source in view.

How it shows up

The common form is DAST: a tool that crawls and probes a running web app. Others watch a program from inside while tests run, as in IAST, or fuzz inputs to trigger crashes. A manual tester using a proxy is doing dynamic analysis too.

Check what it needs: a reachable test copy, valid accounts, and time. Poor results usually mean poor access, such as a scanner that never got past the login screen. The best use of the output is a finding with proof attached, since a list of suspicious responses still has to be sorted by a person.