UnboundCompute Security

SAST vs DAST vs IAST, what is the difference?

SAST vs DAST vs IAST, what is the difference?

Written by

UnboundCompute

in

If you have shopped for application security tools, you have run into the alphabet soup of SAST, DAST, and IAST. The sast vs dast question is the one most teams start with, but IAST sits in the middle and changes the answer. This post gives plain definitions for all three, shows what each catches and misses, and is honest about where they fall short.

The short version of sast vs dast vs iast

The three tools differ by where they stand and what they can see.

  • SAST (Static Application Security Testing) reads your source code without running it. It looks for dangerous patterns in the text of the program.
  • DAST (Dynamic Application Security Testing) tests the running app from the outside, like an attacker with no source code. It sends requests and reads responses.
  • IAST (Interactive Application Security Testing) watches from inside the running app. An agent sits in the process and sees both the incoming request and the line of code that handles it.

SAST: reading the source code

SAST parses your code and models how data flows through it. It traces a value from where it enters, such as a request parameter, to where it gets used, such as a database query or an HTML response. If tainted input reaches a dangerous function without being cleaned, SAST flags it.

Here is the kind of flow SAST is good at spotting:

name = request.args.get("name")
query = "SELECT * FROM users WHERE name = '" + name + "'"
db.execute(query)

The user controls name, it lands in a SQL string with no escaping, and SAST follows that path from input to sink.

What SAST catches

  • Injection patterns: SQL, command, and template injection where input flows into a sink.
  • Hardcoded secrets, weak crypto calls, and unsafe deserialization.
  • Bugs on code paths that are hard to reach with traffic, since SAST reads every branch whether or not it runs.

What SAST misses

  • Anything that depends on configuration or the live environment. A query that looks unsafe may sit behind a parameterized layer SAST cannot model.
  • Logic that lives in a framework, a stored procedure, or a third party library the scanner does not parse.

DAST: testing the running app from outside

DAST treats the app as a black box. It crawls the pages, finds inputs, and throws payloads at them to see how the app reacts. If a request returns a database error or a reflected script, DAST records a finding.

A simple DAST probe for reflected cross site scripting looks like this:

GET /search?q=<script>alert(1)</script> HTTP/1.1
Host: acmenotes.example

If that <script> tag comes back in the HTML response unescaped, the app is reflecting raw input and DAST flags it.

What DAST catches

  • Real behavior of the deployed app, including server config, headers, and TLS settings.
  • Reflected and stored injection, broken authentication flows, and missing security headers.
  • Issues that only show up once everything is wired together.

What DAST misses

  • Code paths it never reaches. If the crawler does not find a form or an API route, that route is never tested.
  • The exact line of code at fault. DAST tells you the app misbehaved, not where in the source to fix it.
  • Bugs that need a valid login or a specific account state the scanner cannot reproduce.

IAST: watching from inside while the app runs

IAST puts an agent inside the running process, often through the language runtime. As traffic flows through the app, the agent sees the request, follows the data through the code that executes, and watches it reach a sink. It is dynamic like DAST, but with the inside view DAST lacks. So it can say something precise: this request reached this query on this line with this tainted value. That pairing is its main advantage.

What IAST catches

  • Injection and input flaws confirmed against code that actually ran, so fewer guesses.
  • The specific file and line, which makes the fix faster than with DAST alone.
  • Flaws deep inside libraries, since the agent watches data move through them at run time.

What IAST misses

  • Code that is never exercised. IAST only sees paths that real traffic or tests drive, so coverage depends on how thoroughly the app is used during testing.
  • Languages and runtimes the agent does not support, since instrumentation is tied to the platform.
  • Bugs outside the instrumented process, such as flaws in a separate service.

Side by side: sast vs dast vs iast

  • SAST. Sees source code, does not run the app. Strong on coverage of every branch. Weak on run time and config reality.
  • DAST. Sees outside behavior, runs the app, needs no source. Strong on real deployed behavior. Weak on pointing to the exact code.
  • IAST. Sees inside the running app, needs runtime access. Strong on precise, confirmed findings. Weak on coverage of paths that never run.

Where false positives come from

Each tool gets noisy for its own reason.

  • SAST flags a path that looks dangerous but is safe, because it cannot see that a value was validated in a way it does not model, or that the path is dead code.
  • DAST reads a response and guesses. A database error in the page can be a leftover string, not proof of injection, so it raises a finding that is not real.
  • IAST is usually the quietest, because it confirms a finding against code that ran. Even so, it can mistake a safe sanitizer for a missing one if it does not recognize the cleaning function you use.

The cost is real. Every wrong alert is time a developer spends ruling it out, and a backlog of noise trains teams to ignore the tool.

The honest limit: none of them understand business logic

Here is the part the vendor pages skip. All three look for known shapes of bugs. None understands what your app is supposed to do.

Pattern matchers find the bug they were told to look for. They do not ask whether a user who can read invoice 41 should be able to read invoice 42.

Consider GET /api/invoices/42 where the logged in user only owns invoice 41. Nothing in that request is malformed. No script tag, no SQL, no broken header. SAST sees clean code, DAST sees a normal 200 response, and IAST sees a safe query running. They all agree the request is fine, and they are all wrong, because the app forgot to check who owns invoice 42. This is broken access control, one of the most common serious bugs in real apps, and the scanners miss it because there is no pattern.

For more on this gap between pattern matching tools and real reasoning about an app, read scanners vs research.

So which one do you need?

For most teams it is not one tool but a stack. SAST runs early on every commit and catches obvious sink bugs before they ship. DAST runs against a deployed build and shows how the real app behaves. IAST rides along with your existing tests and gives precise findings on the paths your traffic touches. They overlap, and that overlap is fine, because each one fails in a different place.

What none of them replaces is a tester who reads the app’s logic and asks whether its assumptions hold. That assumption testing is exactly the kind of work an autonomous researcher is built to do, looking past fixed payload lists to the rules an app quietly trusts. Read how we think about it on our about page.

More posts