DAST
In application security, DAST is dynamic application security testing: probing a running application from the outside with crafted requests and judging the responses. It has no view of the source code, so it finds what is genuinely reachable, which is both its advantage and its limit.
How it works
The scanner crawls the application to build a picture of routes, parameters and forms, then sends variations of each input and compares responses: an injected string reflected unencoded, a database error, a time delay after a payload designed to cause one, a redirect to a supplied host, a security header absent. Modern scanners drive a real browser so that client-rendered applications are crawled at all, and can be given a specification or a recorded session to reach authenticated areas.
Its structural advantage is that it tests the deployed system. Reverse proxy behaviour, environment configuration, the version actually running and the interaction between components are all in scope precisely because the tool cannot see the source.
What goes wrong
Coverage is the honest weakness, and it is a crawling problem before it is a detection problem. What the crawler never reaches is never tested: multi-step flows that need valid data, functionality behind a role the scanner does not hold, endpoints that only exist in the mobile client, and API routes absent from any page. A run that reports a clean result on forty per cent of the surface is not a clean result.
Then there is the class of defect that has no generic signature. A scanner recognises cross-site scripting because the payload comes back in the page. It cannot recognise that this account should not be able to approve its own expense claim, and it cannot construct the second tenant needed to prove broken object level authorisation. Combined with sessions that expire mid-scan and destructive requests fired at production, this is why a scan report and a test report are different documents.
Where this shows up in an audit
We run automation as reconnaissance, not as the assessment. Its output tells us where the surface is and clears the mechanical findings, and then the hours go where the tool cannot go. When a client already scans, we report the delta: what their tooling found, what it missed, and why, since that is the measurable answer to whether the scanner is enough. Paired with SAST, one half sees all the code and proves nothing, the other proves everything it reaches and reaches part of the application. This is part of what a scanner finds and what it cannot reach.