SAST vs DAST vs IAST vs RASP

Four testing approaches that get conflated constantly. What each one actually instruments, what it structurally cannot see, and the order worth adopting them in.

The short answer

All four look for vulnerabilities in your own application code, and they differ almost entirely by vantage point — where the tool sits relative to the running program:

• SAST reads your source or bytecode without running it.
• DAST attacks the running application from outside, knowing nothing about the code behind it.
• IAST watches from inside the running application while something else drives traffic through it.
• RASP is the same instrumentation as IAST, deployed to production, with the option to block a request instead of just recording it.

The useful mental model is not a quality ranking. It is that each tool's coverage is bounded by a different thing: SAST by what the code contains, DAST by what it can reach over HTTP, IAST by what your tests exercise, and RASP by what real users and attackers actually do. Those four bounds barely overlap, which is why mature programs run more than one — and why "which is best" is the wrong question.

How each one actually works

SAST — reading the code

A static analyzer parses your code into an AST or intermediate representation, builds a call graph, and runs taint analysis: it marks untrusted inputs as sources, marks dangerous operations as sinks, and tries to prove whether data can flow from one to the other without passing through a sanitizer. Semgrep, CodeQL and SonarQube all work this way, differing mostly in how expressive their query language is.

The false positives are not sloppiness — they are structural. A static tool has to reason about a program it never runs, so it cannot resolve dynamic dispatch, reflection, or dependency injection with certainty, and it cannot know that a route is unreachable because nothing registers it. Faced with that, it assumes the worst. In exchange you get the one thing no other tool on this list offers: SAST can find a vulnerability in code that no test ever executes. That is most code.

DAST — attacking from outside

A dynamic scanner works in two phases. First it enumerates attack surface, usually by crawling links and forms, or by importing an API specification. Then it mutates parameters and judges the response: a database error string suggests SQL injection, a reflected payload suggests XSS, a timing difference suggests blind injection, and an inbound DNS or HTTP callback to a collaborator host proves SSRF or XXE. OWASP ZAP and Burp Suite's scanner are the reference implementations.

Because it sees only HTTP, DAST tells you a request is exploitable but not why. Triage means tracing the request back to code by hand. The compensating advantage is real: no build integration, no language support matrix, nothing to instrument. Point it at a URL. That is why DAST is almost always the second tool a team adopts, and sometimes the first.

IAST — watching from inside

An IAST agent instruments the application's runtime — bytecode instrumentation through java.lang.instrument on the JVM, the profiling API on .NET, import hooks or monkey-patching on Node and Python. It then propagates taint through the program as it actually runs, and reports when a tainted value reaches a sink. Because it observes a real execution, it can hand you the HTTP request, the stack trace, and the offending line together, which is why its false-positive rate is genuinely low.

The single most misunderstood property of IAST is this: it generates no traffic of its own. It is a passive observer. Something else — your integration suite, a DAST scan, a QA engineer clicking around — has to exercise the code before IAST has anything to say. Which means IAST's real coverage is your test suite's coverage. Buy it with a thin test suite and you have bought an expensive instrument for measuring your QA gaps.

RASP — the production deployment

RASP hooks the same sinks as IAST, in production, and adds a decision: allow or block. That inside-the-process vantage point is what distinguishes it from a WAF. A WAF sees an HTTP request and pattern-matches on it, so it must guess whether ' OR 1=1-- is an attack or someone's surname. RASP can see whether that string actually reached a SQL parser and whether it changed the query's structure — a fact, not a guess.

The honest caveat: most RASP deployments never turn blocking on. In monitoring mode a false positive is a noisy alert; in blocking mode it is an outage for a real customer. Teams that succeed with RASP enable blocking for a narrow set of high-confidence rules and leave the rest reporting.

DAST vs IAST

This is the most-searched pairing, and the framing is usually wrong. They are not competing accuracy tiers — they occupy different roles. DAST is an active attacker with no inside knowledge; IAST is an inside observer that does not attack. The most effective configuration is not either/or: run a DAST scan against an IAST-instrumented build, and the scanner supplies coverage while the agent supplies precision and a line number. Choose IAST alone only if you already have integration tests that meaningfully exercise the app, and accept the per-runtime agent. Choose DAST alone if you need language-agnostic coverage with nothing installed in the app.

IAST vs RASP

Mechanically these are close to the same technology pointed at different problems. IAST runs in pre-production to produce a list of defects for developers to fix. RASP runs in production to make a runtime decision about live traffic. The difference that matters operationally is what you do with the output: IAST findings enter your backlog, RASP events page someone. And RASP is not a vulnerability inventory — it reports on attacks people attempted, which tells you nothing about the flaws nobody happened to probe.

SAST vs DAST

The classic pairing, and genuinely complementary because their blind spots are near-inverses. SAST sees all your code and none of your runtime; DAST sees your runtime and none of your code. SAST finds the injection in an unused admin endpoint; DAST finds the misconfigured header, the expired certificate, the debug route left enabled in staging — none of which appear in source. Running only one leaves a whole category uncovered.

What each one structurally cannot find

This is the part the category diagrams leave out, and it is the part that decides whether adding a tool helps:

• SAST cannot evaluate anything that depends on runtime configuration or deployment. It does not know your environment variables, your reverse proxy, or whether a route is exposed.
• DAST cannot reach what it cannot discover: multi-step workflows, undocumented API parameters, anything behind an authentication flow it fails to handle. Stored XSS is unreliable for it unless the scan revisits the page where the payload surfaces.
• IAST cannot see code your tests never run — which is exactly where untested, unreviewed bugs accumulate.
• RASP cannot find what nobody attacked.
• None of them find vulnerable dependencies. That is SCA, and for most applications it is the higher-yield scan.
• None of them reliably find broken authorization. Whether user A should be able to read record B is a statement about intent, and no scanner has access to your intent — which is why IDOR remains a manual and bug-bounty finding.

Where modern architecture breaks them

Most of these tools were designed against server-rendered monoliths, and the seams show:

• Single-page apps and JSON APIs defeat DAST crawlers. Routes that exist only inside a JavaScript bundle are not discoverable by following links. The fix is to stop relying on the crawler: feed the scanner an OpenAPI specification or a recorded proxy session.
• Serverless breaks agent-based IAST and RASP. Attaching an instrumentation agent to a function with a cold-start budget measured in milliseconds is a poor trade, and there is often no long-lived process to attach to.
• Polyglot services multiply agents. Language-agnostic DAST covers a mixed estate with one deployment; IAST and RASP need an agent per runtime.
• Taint does not survive a network hop. When a tainted value is serialized, sent to another service, and deserialized there, every tool in this comparison loses the connection. Distributed systems are where taint tracking quietly stops working.

An adoption order that works

Roughly in descending order of value per unit of effort:

• SCA first, though it is not on this list. Known CVEs in dependencies are the cheapest real risk to remove.
• SAST in pull requests, tuned narrow. Start with a handful of high-confidence rules. Enabling a full ruleset in CI on day one is how a team learns to ignore security tooling permanently.
• DAST against staging, nightly. Full scans take too long to gate a commit. Run it on a schedule and treat the diff as the signal.
• IAST only once integration tests are real. The prerequisite is test coverage, not budget.
• RASP last, in monitoring mode, and enable blocking only for rules you would stake an outage on.

Four confusions worth clearing up

• "IAST replaces DAST." It cannot — IAST is passive. Remove the scanner and the agent has nothing to observe.
• "RASP replaces a WAF." Different layer and different job. A WAF also handles rate limiting, bot management and volumetric attacks, and it protects infrastructure that has no agent in it. See WAF vs RASP.
• "SCA is a kind of SAST." Both run pre-build, but SAST analyzes code you wrote and SCA inventories code you imported. The findings go to different people and are fixed in different ways.
• "Shift left means SAST." Shifting left is about when feedback arrives, not which technology delivers it. A DAST scan wired into a preview environment shifts left; a SAST report nobody reads does not.