SAST vs DAST - Differences, When to Use Each, and IAST/SCA (2026)

Direct answer

SAST reads source code without running it and traces tainted data to dangerous sinks, so it runs on every commit and pinpoints the line. DAST attacks a deployed application from the outside and confirms real exploitability, so it runs against staging and reports the endpoint. They overlap very little. SCA covers the dependency tree, IAST bridges the two with an in-process agent, and AI code review adds logic-level judgement none of them have. Verified 2026-10-19.

What is the difference between SAST and DAST?

Direct answer: SAST is white-box static analysis of source, bytecode or binaries - no running app required, findings at line level, higher false positives. DAST is black-box dynamic probing of a deployed application - requires a running target, findings at endpoint level, lower false positives. SAST finds insecure code; DAST finds an insecure system. Verified 2026-10-19.

The mistake teams make is treating “we have a security scanner” as a solved problem when they run exactly one of these. Each is blind to an entire class of defect the other sees easily. A team running SAST only will ship a flawless codebase behind a reverse proxy that leaks stack traces. A team running DAST only will pass every scan while an unexercised admin endpoint sits unauthenticated in code that no test ever calls.

This guide covers both poles, then the two techniques that fill the gaps (IAST and SCA), then the honest answer on where LLM-based AI code review actually sits in that stack.

SAST vs DAST side by side

Dimension	SAST	DAST
Approach	White-box, reads source / bytecode / binary	Black-box, sends crafted requests to a running target
When it runs	IDE, pre-commit, pull request, every commit	Staging or production, post-deploy, usually scheduled
Needs a running app	No	Yes
Needs a build	Sometimes (compiled languages)	Yes, a deployed one
Typical runtime	Seconds to minutes per PR	Tens of minutes to hours per full crawl
Primary findings	Injection, unsafe deserialization, path traversal, hardcoded secrets	Missing security headers, TLS config, auth bypass, verbose errors, exposed endpoints
Pinpoints the line	Yes, with the dataflow path	No, reports the endpoint and payload
False positives	Higher - no runtime context, flags unreachable paths	Lower - a successful probe is evidence
False negatives	Misses config and deployment flaws entirely	Misses every path your crawl or tests do not reach
Language awareness	Per language, per framework	Protocol level, language agnostic
Coverage	All code paths including dead code	Only paths reachable at runtime through the crawl
Merge-gate suitability	Good	Poor - too slow, needs a deployment

The pattern is clean. SAST tells you the code could be dangerous. DAST tells you the deployed system is dangerous. You want both signals, and you want them at different points in the pipeline, because a technique that needs a deployment cannot be a pre-merge gate.

What is SAST and what does it actually catch?

SAST, or Static Application Security Testing, parses your code into an abstract syntax tree and a control-flow graph, then traces how untrusted data moves through the program. The analysis it is built for is taint tracking: identify a source of untrusted input, identify a dangerous sink, and report every path between them that does not pass through a sanitizer.

The canonical finding is SQL injection:

# SAST flags this - request data reaches the query unsanitized
def get_user(request):
    name = request.args.get("name")
    return db.execute(f"SELECT * FROM users WHERE name = '{name}'")

Because SAST works on source, it runs at the earliest possible point: in the editor as you type, and on the pull request before merge. That shift-left timing is its biggest advantage, and it is why SAST is the only one of these four techniques that makes a sensible required status check. For the pipeline mechanics, see AI code review in CI pipelines and our guide to shift-left security.

Its structural weakness is context. SAST does not know how the application is deployed, which framework middleware is active, or whether a code path is reachable in production. So it flags issues that cannot be exploited, and the triage cost is real. The three things that most reduce SAST false positives are interfile dataflow, framework-aware sanitizer models, and a reachability filter. All three are features you pay for.

Where SAST is structurally weak

OWASP-style category	SAST coverage	Why
Injection (SQLi, command, LDAP)	Strong	Expressible as source-to-sink taint
Insecure deserialization	Strong	Known dangerous sinks per language
Path traversal	Strong	Taint into filesystem APIs
Hardcoded secrets	Strong	Pattern plus entropy matching
Broken access control	Weak	Whether a missing check is a bug depends on intent
Security misconfiguration	Very weak	Config lives outside the scanned code
Vulnerable components	None	That is SCA’s job
Cryptographic failures	Mixed	Catches weak primitives, misses key management
Server-side request forgery	Mixed	Needs accurate allowlist modelling

Broken access control is the one that should worry you, because it is both the hardest for static analysis and consistently near the top of real-world breach causes. It is also the category where an LLM reviewer that can read the surrounding code and the PR description has a genuine advantage.

What is DAST and what does it actually catch?

DAST takes the opposite approach. It runs against a deployed, running application and probes it from the outside with crafted requests, exactly as an external attacker would. It has no access to source, only to inputs and responses.

DAST shines at vulnerabilities that do not exist in source code at all. A missing Strict-Transport-Security header, a TLS version enabled on the load balancer, an authentication bypass introduced by a routing rule, a server that returns a full stack trace on a malformed request, a staging database reachable from the internet - none of these are visible to a source-code scanner, because they are properties of the running system rather than of any line.

A DAST finding is also evidence rather than inference. The scanner sent a payload and the application responded in a way that proves the flaw. That is why DAST false-positive rates are structurally lower than SAST’s, and why DAST findings carry weight with engineers who have learned to ignore static alerts.

The tradeoffs mirror SAST’s strengths:

• It runs late. A finding arrives after the code is written, merged and deployed, which is the most expensive point to fix it.
• It only tests what it can reach. Unexercised features, admin paths behind an unusual auth flow, and anything requiring a multi-step business workflow often go unscanned. Authenticated crawling helps and is fiddly to configure.
• It cannot tell you which line to fix. You get an endpoint and a payload, and then an engineer spends an hour finding the code.
• It is slow. Full crawls run for tens of minutes to hours. This is why DAST belongs on a schedule, not in a pull request gate.

Where do IAST and SCA fit?

Direct answer: IAST instruments the running app with an in-process agent, so it sees the code path and the runtime behaviour at once and confirms reachability - fewer false positives than SAST, line-level precision DAST lacks. SCA scans a completely different surface: your dependency tree, matched against CVE databases, with licence checks. Neither is optional in a mature program. Verified 2026-10-19.

IAST sits between the two poles. The agent observes execution from inside the process while your existing test suite or QA traffic drives the application. Because it sees both the code and the runtime path, it can confirm that a vulnerable code path is actually reachable, which removes the biggest source of SAST noise. The cost is that it needs a running instrumented build, runtime support for the agent, and test coverage good enough to exercise the vulnerable paths. Uncovered code is simply not analyzed, so IAST inherits DAST’s coverage problem while solving SAST’s precision problem.

SCA scans a different attack surface entirely: your dependencies. Modern applications are mostly third-party code once you resolve the transitive tree, and SCA matches every resolved package version against vulnerability databases and licence policy. SAST scans the code you wrote; SCA scans the code you imported. A vulnerable version of a logging library will never appear in a SAST scan of your own source, which is exactly why SCA is not optional. We cover the mechanics in depth in what is software composition analysis, including why reachability analysis is the thing separating useful SCA from a CVE firehose.

The four techniques on one table

Technique	What it analyzes	Needs running app	Finding granularity	Best pipeline position
SAST	Your source, bytecode or binary	No	Line plus dataflow path	Every commit and pull request
SCA	Resolved dependency tree	No	Package and version, ideally with reachability	Every commit, plus continuous monitoring after merge
DAST	Deployed, running application	Yes	Endpoint plus payload	Nightly or weekly against staging
IAST	Running app from inside, via agent	Yes	Line plus confirmed runtime reachability	Alongside the test suite in QA

A complete program layers all four: SAST and SCA on every commit, DAST on a schedule against staging, IAST where test coverage can drive it. Then one more layer on top, which is the part most security content skips.

Does AI code review replace SAST?

Direct answer: No. AI code review is not SAST and does not substitute for it. SAST is deterministic, reproducible and auditable, which is what a compliance gate needs. An LLM reviewer is non-deterministic and reasons about intent, which is what broken access control needs. Run both. As of 2026-10-19 no AI reviewer publishes an independently verified OWASP detection rate. Verified 2026-10-19.

None of the four techniques above understand business logic. SAST traces taint, DAST throws payloads, SCA diffs a lockfile, IAST watches a call stack. None of them knows that your new endpoint forgot the require_org_admin check that every sibling endpoint enforces, or that a refactor quietly widened a permission boundary from org-scoped to global.

That is the gap AI review fills, and it is a real one. LLM-based reviewers reason about intent across files and catch context-dependent security mistakes that pattern-matching cannot express and black-box probing cannot see. Our deeper treatment is in AI code review for security and AI code review for security vulnerabilities.

Three honest caveats, because this is where vendor content gets sloppy:

1. Non-determinism is a compliance problem. The same PR reviewed twice can produce different findings. A SOC 2 auditor asking “prove this scan ran on every commit with the same ruleset” is not satisfied by an LLM.
2. The independent evidence is thin. No party without a commercial stake has published a false-positive rate, precision figure or noise measurement for any shipping commercial AI code reviewer (verified 2026-10-19). SWE-PRBench and CR-Bench do publish false-positive data, but they measure bare models in fixed harnesses, not products you can buy.
3. Vendor claims diverge wildly. Anthropic publishes 84% bug detection on PRs over 1,000 lines at under 1% false positives for its Code Review product - vendor-published and unreplicated (verified 2026-10-18). Meanwhile c-CRAB found that across four agentic tools, 97 of 234 executable review tests were passed by at least one tool, 41.5% (arXiv 2603.23448). Note the conflict: c-CRAB’s author block includes one SonarSource affiliation, and Sonar acquired Gitar, which is a paid sponsor of this site. We disclose it every time.

The practical 2026 stack: AI review plus SAST plus SCA at the pull request, DAST against staging, IAST where coverage allows. AI review is the newest layer and the one that catches logic-level security bugs the older methods structurally miss. It is not a replacement for any of them.

Can you run SAST on-premise, or is it a tunnel?

Direct answer: Read the deployment diagram. SonarQube, Checkmarx, Coverity and Semgrep’s CE binary genuinely execute inside your network. But Semgrep’s Network Broker is a WireGuard tunnel to Semgrep’s cloud, and Snyk Broker is the same pattern. Neither is on-premise deployment. If source must never leave your network, a broker does not satisfy that. Verified 2026-10-18.

This is the single most common procurement mistake in application security, and vendors are not always eager to correct it. “Broker” sounds like a proxy that keeps data local. It is not. It is an outbound tunnel that avoids opening inbound firewall ports while still delivering code or metadata to the vendor’s analysis cloud.

Deployment claim	What it actually means	Examples
Level 1 - true self-hosted	The analysis engine runs on your infrastructure; no code leaves	SonarQube (core SAST engine on-prem), Checkmarx on-prem, Coverity, Semgrep CE binary in your CI
Level 2 - enterprise self-hosted, gated	Genuine self-host, but only above a seat or contract threshold	CodeRabbit self-hosting requires 500+ seats (per their docs, Aug 2026)
Level 3 - tunnel, not on-prem	Outbound connector to the vendor’s cloud where analysis runs	Semgrep Network Broker (WireGuard tunnel to Semgrep’s cloud), Snyk Broker, GitHub Copilot code review (validation can run on self-hosted runners, the review service does not)

Two further facts worth carrying into a vendor call:

• Semgrep Inc. is explicitly not ISO 27001 certified per its own documentation (verified 2026-10-18; the docs URL we used returned 404 on re-check 2026-10-19, so treat as vendor-stated and re-verify before quoting in a contract). Several aggregator profiles list Semgrep as holding PCI, HIPAA, FedRAMP, ISO and CSA STAR. Those listings are wrong.
• Semgrep’s interfile taint analysis requires the proprietary Pro engine. Semgrep CE cannot do interfile. Opengrep’s --taint-intrafile matches --pro-intrafile under LGPL 2.1, so “interfile taint analysis plus an open source licence” does not exist in this market (verified 2026-10-18). Cross-file analysis with the Pro engine is available on all hosted tiers including Free, so it is free-as-in-beer but never free-as-in-licence.

If your constraint is regulatory rather than preference, our AI code review for regulated teams page works through the full deployment ladder, and AI code review tools that are self-hosted does the same for the review layer specifically.

The tools that run each scan

Most modern platforms bundle several methods, which is why “SAST vs DAST” is increasingly a coverage question rather than a product choice.

Snyk Code is a SAST engine whose DeepCode AI performs interfile dataflow analysis, shipping inside a platform that also covers SCA, container and IaC scanning. Snyk’s model changed in 2026: enterprise is now a prepaid credit platform subscription where 1 credit equals $1, with Snyk Code metered at 1.0 credit per active contributor per day. Live caps are Free at 5 projects and 100 Code tests per month, Team at 100 projects and 1,000 tests per month (verified 2026-10-18). The commonly quoted “Ignite $1,260/yr unlimited projects” figure is third-party sourced and not on Snyk’s plans page - do not state it as fact. See Snyk pricing and our Snyk Code explainer.

Semgrep is the fast, developer-friendly option whose custom rules read like the code they match. Its platform splits into modules priced separately: Teams is Code $30, Supply Chain $30 and Secrets $15 per contributor per month (verified 2026-10-18). Semgrep Free covers 10 contributors and 10 private repos with 60 AI credits. Maturity is uneven - 20 rulesets at GA, 2 beta, 19 experimental, with cross-file dataflow in only 8 languages, and 710+ Pro rules for Python against 170+ for C#. Semgrep pricing has the full breakdown, and Semgrep vs CodeQL covers the depth tradeoff.

Checkmarx offers the deepest commercial SAST taint analysis for regulated enterprises - compare it in Checkmarx vs Veracode. Veracode is the other end of the same market and is one of only seven vendors in our compliance sweep holding ISO/IEC 42001:2023, the AI-specific standard (verified 2026-10-18).

SonarQube deserves a precision note, because two products get conflated constantly. SonarQube Community Build analyzes the main branch only and cannot analyze pull requests - Sonar’s own docs state that Developer Edition is the minimum for branch and pull request analysis. SonarQube Cloud’s free tier does include PR analysis, up to 50k lines on private projects, and never expires. Community Build also excludes C, C++, Dart, Objective-C, PL/SQL, PowerShell, R, Shell, Swift and T-SQL, and excludes taint analysis, though it does include secrets detection (verified 2026-10-18). “SonarQube free tier for a C++ shop” is a non-starter.

For DAST specifically, Codacy is notable because its Business tier bundles ZAP-powered DAST alongside SAST, SCA and quality analysis, giving smaller teams static and dynamic coverage in one dashboard. Codacy’s Developer tier is free forever and Team starts at $18/dev/mo billed yearly, up to 30 devs (verified 2026-10-18). For the full field of static scanners see best SAST tools 2026 and the best static analysis tools buyers guide.

A pipeline that actually works

Order matters more than tool choice. The failure mode is putting a slow, late-stage technique in front of a merge.

Stage	What runs	Blocking?	Why
Editor / pre-commit	Linter, secrets scan	Advisory	Instant feedback, zero CI cost
Pull request opened	SAST on changed files, SCA on lockfile diff, AI review	SAST and SCA block on new high-severity; AI review advisory	Fast, cheap, pre-merge
Pull request, deeper	Full-repo SAST on a schedule or on label	Non-blocking	Interfile analysis is too slow per PR on large repos
Merge queue	Re-run required checks on the queued combination	Blocking	Guards against semantic conflicts between PRs
Post-deploy to staging	DAST authenticated crawl, IAST during the test run	Non-blocking, ticketed	Needs a deployment, too slow to gate
Continuous	SCA monitoring of shipped dependencies	Alerting	New CVEs land against code you already shipped

One CI gotcha that bites teams running required security checks behind GitHub’s merge queue: the merge_group event is separate from pull_request and push. If a required SAST or AI-review job triggers only on pull_request, the merge queue stalls permanently, because GitHub’s docs state the status check “will not be triggered… The merge will fail as the required status check will not be reported” (verified 2026-10-18). See what is a merge queue.

Common mistakes

• Running only one method. SAST-only misses runtime and config flaws. DAST-only misses insecure code your crawl never reached.
• Forgetting SCA. Your own code can be flawless while a transitive dependency carries a critical CVE. Most of your line count is third-party.
• Gating merges on raw SAST output. Tune rules, enable reachability, and triage before you block, or developers will learn to ignore a wall of alerts. Our AI code review tools with low false positives page covers the noise problem.
• Treating DAST as shift-left. It needs a running app. It is a late gate by construction.
• Accepting “broker” as “on-prem”. Semgrep’s Network Broker and Snyk Broker are tunnels to the vendor cloud. Ask where analysis executes.
• Quoting aggregator compliance tables. Verify against the vendor trust centre. “HIPAA certified” is not a real certification scheme; HIPAA requires a signed BAA, and SOC 2 alone does not satisfy it.
• Assuming AI review is a SAST replacement. It is a different layer with different failure modes and no deterministic audit trail.

How we verified this

Checked at primary source on 2026-10-19:

• DORA-unrelated but relevant to our pipeline claims: GitHub’s merge-queue documentation on merge_group behaviour, carried from our 2026-10-18 pass.
• We attempted to re-verify Semgrep’s compliance statement at semgrep.dev/docs/trust-and-security and the redirect target docs.semgrep.dev/trust-and-security. Both returned HTTP 404 on 2026-10-19. The ISO 27001 negative is therefore carried from our 2026-10-18 verification of Semgrep’s own docs and is labelled vendor-stated, not re-confirmed today.

Carried from the 2026-10-18 verification pass (vendor documentation and pricing pages read directly):

• Semgrep Teams modular pricing (Code $30 / Supply Chain $30 / Secrets $15 per contributor per month), Semgrep Free limits, interfile requiring the Pro engine, Opengrep’s --taint-intrafile parity under LGPL 2.1, and Semgrep ruleset maturity counts.
• Snyk’s shift to a prepaid credit platform subscription, Free at 5 projects / 100 Code tests per month, Team at 100 projects / 1,000 tests per month.
• SonarQube Community Build versus SonarQube Cloud free tier, including the language exclusions and the correction that secrets detection is in Community Build.
• Codacy tiers, CodeRabbit’s 500+ seat self-hosting threshold, Veracode’s ISO/IEC 42001:2023 certification.
• Anthropic’s published Code Review metrics (84% detection on 1,000+ line PRs, under 1% false positives) and c-CRAB’s 41.5% union figure from arXiv 2603.23448.

What we could not verify:

• No independent, vendor-neutral false-positive or precision measurement exists for any shipping commercial AI code reviewer. We state this as the strongest honest claim available rather than quoting a vendor number as fact.
• No published benchmark compares SAST detection rates across vendors on a shared, independent corpus of real production code. Vendor-run SAST benchmarks exist; independent ones at scale do not, in our checking.
• Per-language SAST precision data does not exist publicly. No vendor publishes per-language precision or recall for its own product.
• DAST runtime figures in this article are expressed as ranges based on application size and authentication complexity. We did not run a controlled timing benchmark and do not present one.

Conflict disclosure: Gitar is a paid sponsor of aicodereview.cc. Sonar acquired Gitar in May 2026, and one c-CRAB author lists SonarSource as his affiliation. We disclose this wherever c-CRAB is cited. It changes nothing about the ranking on this page.

Recommendations

Criteria: coverage per dollar, deployment honesty, and whether a finding arrives early enough to be cheap to fix.

If you are a team of 10 or fewer and have no security budget: run Semgrep Free in CI for SAST (10 contributors, 10 private repos) plus your package manager’s audit command for a crude SCA baseline, and add SonarQube Cloud’s free tier if you need pull request analysis on a private repo. Skip DAST until you have a staging environment worth scanning.

If you have a real AppSec budget and live on GitHub: SAST via CodeQL through GitHub Advanced Security, SCA via Snyk or Semgrep Supply Chain with reachability on, DAST on a nightly authenticated schedule, and an AI PR reviewer on top for the access-control and business-logic class. That combination has the fewest structural blind spots.

If you are regulated and source cannot leave your network: SonarQube self-hosted or Checkmarx on-prem for SAST, and be rigorous about rejecting broker architectures that present as on-prem. Confirm with the vendor, in writing, where analysis executes.

If you can only afford one thing: SCA, not SAST. Most of your exploitable surface is third-party code with published, weaponized CVEs, and the fix is usually a version bump rather than a redesign. That is the highest return per hour of engineering time available in application security, and it is the layer teams skip most often.

Further reading

• Best SAST Tools in 2026
• AI Code Review for Security
• What Is Software Composition Analysis?
• What Is CodeQL?
• Static Code Analysis Tools - The Definitive Guide
• Shift-Left Security Explained