Home / Knowledge hub / DAST
Knowledge hub
DAST
Tools that attack a running application from the outside.
What it means
DAST stands for dynamic application security testing. It means tools that attack a running application from the outside without reading its source. They crawl whatever they can reach, send known bad input, and report what comes back looking wrong.
SAST is the opposite arrangement, reading code without running it. Most teams end up with both, because the two fail in different directions.
Why it matters
A scanner is good at what an anonymous visitor can reach: exposed pages, missing headers, obvious injection points, software announcing its own version. It tests what you actually deployed, configuration included, which beats reading a repository and hoping production matches.
Work out what a clean scan means before you show one to a customer. It means the automated checks that ran found nothing on the paths they reached, using the session they held. That is useful and narrow. The distance between it and we tested this application is where the unpleasant surprises live, so ask which paths were covered and with which logins.
How it shows up
The blind spots stay the same from tool to tool. One session means a scanner cannot compare what two roles are allowed to see, and that is where the serious access control flaws sit. It does not know what your product is for, so a stacked discount reads as a valid response. It will not reach anything behind a multi-step flow it cannot complete.
Cyberlop runs beside a scanner, logged in as each role, on the classes one session cannot reach. Our business-logic module ships on 4 January 2027, so today we say so rather than imply it. Where we differ.
Questions people ask
DAST, answered
SAST or DAST, which should we buy first?
If you ship a web application and have neither, start with the one that tests what is live. It sees your real configuration and produces fewer findings that turn out to be unreachable.
Add code analysis when your team is large enough that review no longer catches the obvious patterns. The two answer different questions, so neither replaces the other.
Can a scanner test an API, or does it need a web page to crawl?
Most can, if you give them a schema or a recorded set of requests. Without one they guess, and they guess badly on anything that is not linked from a page.
The practical test is coverage. Ask for the list of endpoints the scan actually exercised and compare it with your route table.
Can it test the part behind the login?
Usually yes, with credentials configured, and this is worth doing because most of your application lives there.
One caution. A scanner holds one session at a time. It can test what that account can do, but it cannot tell you what a different role could reach, because it never signs in as two people at once.
Our scan came back clean. Are we secure?
You are clean on the checks it runs, on the paths it reached, with the login it had. That is a real result and a narrow one.
Nothing in a scan covers authorisation between roles or business logic. Those need a tester who knows what your product is for, which is why a clean report is a sentence rather than an assurance.
Is a scan enough when a customer's questionnaire asks for a penetration test?
Usually not. Most questionnaires mean human-led testing with an agreed scope and a written report, and a scan output is not that.
Say which you did. Sending a scanner PDF labelled as a pentest is the kind of thing that turns one awkward question into five.
Sources
Where this comes from
Related
Terms that sit next to this one
SAST
Tools that read your source code without ever running it.
IAST
An agent inside a running app that watches where input travels.
Black-box testing
Testing an app from outside, with no access to the source code.
False positive
A reported issue that turns out not to be real.
Authorization
Deciding what a proven user is then allowed to do.
Your scanner found nothing. Now what?
We run beside your scanner, logged in as each role, on the classes one session cannot reach. You get proof for each finding rather than a rule name. Ask us where the overlap ends.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.