SAST vs DAST vs SCA vs IAST in 2026: What Each Finds, 34% False Positives

Every security vendor I have spoken to this year sells "SAST, DAST, SCA and IAST" as if they were four flavours of the same thing, and every engineering team I talk to has at least one of them switched on and quietly ignored. They are not flavours. Each one looks at a different artefact (your source, your running app, your dependency tree, your instrumented runtime), so each finds a different class of bug and fails in a different way. This post explains SAST vs DAST vs SCA vs IAST in plain terms, what each actually finds, what published research says about false positive rates, which tools are worth your time in 2026 (Semgrep, CodeQL, SonarQube, Snyk, ZAP and friends), what AI changed, and where each scanner belongs in a pipeline.

What is the difference between SAST, DAST, SCA and IAST?

The shortest useful definition is by input.

SAST (static application security testing) reads your source code, or a compiled representation of it, without running it. It builds a model of how data flows from sources (an HTTP parameter, a file, an environment variable) to sinks (a SQL query, a shell call, an HTML template) and flags paths where untrusted data arrives without sanitisation. SQL injection, command injection, path traversal, hard-coded crypto keys and unsafe deserialisation are its home ground.

DAST (dynamic application security testing) attacks a running application from the outside, like a very patient and slightly dim penetration tester. It crawls pages and API endpoints, sends malicious payloads and looks at the responses. It finds what is actually exposed: missing security headers, reflected XSS, misconfigured TLS, verbose error pages. It knows nothing about your code.

SCA (software composition analysis) reads your dependency manifests and lockfiles (or a container image, or an SBOM) and matches the package versions against vulnerability databases such as OSV and the NVD. Most tools also check licences.

IAST (interactive application security testing) puts an agent inside the running application, usually as a language runtime hook, and watches real requests travel through real code during tests. AWS's DevOps guidance describes it as combining the strengths of both: agents with access to "application code, system memory, stack traces, and requests and responses", which is why it reports fewer false alarms. The same page marks IAST as optional and says many organisations find sufficient coverage with SAST and DAST.

	SAST	DAST	SCA	IAST
Input	Source or bytecode	Running app over HTTP	Lockfiles, images, SBOMs	Instrumented running app
Finds	Injection, unsafe APIs, hard-coded secrets in code	Exposed misconfig, XSS, auth and header issues	Known CVEs in dependencies, licence problems	Confirmed data-flow vulns on exercised paths
Misses	Runtime config, business logic, anything in dependencies	Code paths the crawler never reaches	Bugs in your own code, unknown vulns	Code your tests never execute
When it runs	Every PR	Against staging, nightly or pre-release	Every PR, plus a daily rescan	During integration tests in a test env
Open-source examples	Semgrep CE, Opengrep, CodeQL (free for public repos), SonarQube Community Build	ZAP	OSV-Scanner, Trivy, Grype, Dependabot	Few; mostly commercial (Contrast and others)

The "Misses" row is the one to read twice. A team running only SAST will never learn that its staging load balancer serves an admin panel on port 8080. A team running only DAST will never learn that the admin panel's login handler concatenates strings into SQL on a branch the crawler cannot reach.

Is SAST or DAST better?

Neither, and the question usually comes from someone with budget for one tool. If I had to pick a single scanner for a typical web team, I would pick SCA first, not either of them, because most of the code you ship is code you did not write and the fixes are usually a version bump. Datadog's State of DevSecOps 2026 found that 87% of organisations run at least one known exploitable vulnerability in deployed services and 42% of services rely on unmaintained libraries. Those are SCA findings. The same report found that only 18% of vulnerabilities rated critical stay critical once runtime context is applied, which is the strongest argument I know for prioritising SCA output by reachability and exposure rather than by CVSS score alone. I wrote more about that in vulnerability management in 2026.

After SCA, SAST is the next cheapest to run because it needs nothing but a checkout and gives feedback on the pull request where the developer still remembers the code. DAST comes third: it needs a deployed environment, test credentials and a crawl configuration, and it is slow. But it is the only one of the four that tells you what an attacker on the internet actually sees.

How accurate are SAST tools? The false positive problem

This is the part vendors are quietest about. The most careful recent number I trust comes from an ISSTA 2025 experience report that ran CodeQL across 258 popular embedded open-source projects: CodeQL reported 709 true defects with a false positive rate of 34%. The same paper found only 3% of those projects went beyond trivial compiler analyses at all, and developers cited perceived ineffectiveness and false positives as the reason.

GitHub's own documentation says the queries in CodeQL's default suite are "highly precise and return few false positive" results; the security-extended and security-and-quality suites add lower-precision queries. That is the practical lever: suite choice moves the false positive rate more than tool choice does.

Semgrep's free engine has a structural reason for noise. Semgrep's own comparison says Community Edition does cross-function constant propagation within a single file and taint analysis within a single function, cannot track data beyond a single function or file, and "may find more false positives". Cross-file taint tracking is in the paid Semgrep Code product, which is free for up to 10 contributors. In exchange, CE is fast and its rules are YAML you can write in an afternoon.

DAST false positives are a different shape. ZAP's passive rules mostly report facts (a header is missing, a cookie lacks Secure), so the problem is less "wrong" than "true and uninteresting". Its active scanner can misread a reflected payload or a timing blip as an injection.

SCA false positives are almost entirely about reachability: the vulnerable function exists in a package you import but your code never calls it. That is a real CVE in the lockfile and a non-issue in production, which is why VEX statements and reachability analysis exist.

Semgrep vs CodeQL vs SonarQube vs Snyk vs ZAP

Here is how I would describe the main tools to a colleague in late 2026.

CodeQL treats code as a database you query. It has deep interprocedural data flow, a large maintained query library, and is the engine behind GitHub code scanning. The CLI is at v2.27.3 (20 October 2026). It is free for public repositories; for private repositories it needs GitHub Code Security, which GitHub split out of Advanced Security in April 2025 at $30 per active committer per month, with Secret Protection at $19.

Semgrep is pattern matching that looks like the code it matches. Releases ship weekly (v1.183.0 on 29 October 2026). The engine is LGPL-2.1, but in December 2024 Semgrep moved its maintained rules to the more restrictive Semgrep Rules License, and early in 2025 a group of security vendors launched the Opengrep fork to keep engine and rules fully open. Opengrep is shipping steadily (v1.33.1 on 29 October 2026, per its releases page). If you only scan your own code internally, the rules licence does not bite; if you build a product on top of the rules, read it.

SonarQube is a code quality platform with security rules attached, strongest when you want one dashboard for bugs, smells, coverage and security hotspots. The free Community Build is at 26.10; branch and PR analysis and the deeper taint engine are in paid editions.

Snyk sells SAST (Snyk Code), SCA (Snyk Open Source), container and IaC scanning as one commercial platform with a developer-friendly UI. Its SCA database and fix PRs are the reason most teams buy it.

ZAP is the open-source DAST default. Since September 2024 it is "ZAP by Checkmarx", with Checkmarx employing the three project leaders, but it stays Apache-2.0 and under the core team's control. The latest stable release is 2.17.0 from December 2025, with weekly builds since.

A minimal "one of each" run looks like this. It is not a pipeline, just the three commands I would use to see what each category finds on a repository and its staging deployment:

#!/usr/bin/env bash
# One scanner per category, pinned versions, run from the repo root.
set -euo pipefail

# SAST: Semgrep CE 1.183.0, registry default ruleset, no telemetry, fail on findings
docker run --rm -v "$PWD:/src" semgrep/semgrep:1.183.0 \
  semgrep scan --config p/default --metrics=off --error /src

# SCA: OSV-Scanner v2.7.0 against every lockfile it can find
osv-scanner scan source -r .

# DAST: ZAP 2.17.0 passive baseline scan of staging (-I: do not fail on warnings)
docker run --rm -t zaproxy/zap-stable:2.17.0 \
  zap-baseline.py -t https://staging.example.com -I

If you want the pipeline version of the SAST half, with SARIF upload, PR-only scanning and suppressions, I wrote it up as a step-by-step guide to adding Semgrep and CodeQL to GitHub Actions. For container images specifically, the Trivy and Grype guide covers the SCA side.

Where does each scanner go in the CI/CD pipeline?

The rule I use: run each scanner at the earliest stage where its input exists, and only block on findings the author of the change can reasonably fix.

Two details make this work in practice. First, SAST on a pull request should report only findings introduced by that change; otherwise the first PR after enabling it inherits three hundred legacy alerts and someone disables the check. Semgrep does this with --baseline-commit, and the CodeQL Action uses diff-informed analysis on pull requests to focus on the lines a change added or modified. Second, a DAST scan should never be a required check on a PR unless you deploy an ephemeral environment per PR, because a scanner that fails on someone else's broken staging deploy teaches people to click "re-run" until it passes.

This is where platform discipline still matters. None of the scanners is hard to install. What makes them useful is the boring part: pinned versions, baselines, an owner per alert class, and a policy about what blocks a merge. That matters more now that code volume per engineer has gone up.

Does AI replace SAST? AI-powered security code review in 2026

AI changed two things: who writes the code, and who triages the findings.

On the first, Veracode's 2025 GenAI Code Security Report tested over 100 models on tasks built around known CWE weaknesses and found they chose the insecure implementation 45% of the time, with Java above 70%. More code, written faster, with a known bias toward insecure defaults, is an argument for more automated scanning, not less. I covered the wider picture in what DevSecOps means in 2026.

On the second, the research is genuinely promising. A 2025 paper putting a fine-tuned Llama 3 8B model behind Semgrep cut false positives from 225 to 20, about 91%, on the authors' own evaluation. A January 2026 comparison of LLM agents filtering CodeQL alerts, "Sifting the Noise", reports the best configuration identifying up to 93.3% of false positives on real Java projects, and it warns plainly that aggressive filtering can suppress true vulnerabilities and that results depend heavily on the model and the CWE. That is the right pattern: deterministic scanner for recall, model for triage, human for the decision.

The product versions exist too. GitHub's Copilot Autofix proposes fixes for code scanning alerts and is available on all public repositories without a Copilot subscription. Anthropic publishes a Claude Code security review action that reviews PR diffs with a model, and its README says it is not hardened against prompt injection and should only review trusted PRs. Take that sentence seriously: a reviewer that reads attacker-controlled code with a model is an attack surface. The wider story of AI finding bugs at scale is in AI vulnerability discovery in 2026.

My view: an LLM reviewer is a fifth category that is good at logic flaws the pattern matchers miss (an authorisation check on the wrong object, for example) and bad at being consistent. Run it as an advisory comment next to SAST, never instead of it.

FAQ

What is the main difference between SAST and DAST?

SAST analyses source code without running it and finds bugs like injection by tracing data flow. DAST tests a running application from the outside by sending attack payloads, so it finds exposed misconfigurations and runtime issues. SAST runs on every pull request; DAST needs a deployed environment.

Is SCA the same as SAST?

No. SCA scans your third-party dependencies for known vulnerabilities and licence issues by matching package versions against databases such as OSV. SAST scans the code you wrote. You need both, because most of the code in a modern application comes from dependencies.

Do I need IAST if I already run SAST and DAST?

Usually not. IAST gives more accurate findings because an agent watches real requests inside the app, but it requires language-specific agents, a test environment and good test coverage. AWS's DevOps guidance lists it as optional for exactly that reason.

Is Semgrep or CodeQL better?

CodeQL has deeper cross-file data flow and is free on public GitHub repositories; Semgrep CE is faster, easier to write rules for, and runs anywhere, but its free engine analyses one file at a time. Many teams run CodeQL for depth and Semgrep for custom, organisation-specific rules.

This quarter I would turn on SCA with a daily rescan first, add CodeQL default setup or Semgrep CE on pull requests with baseline-only reporting, write two or three custom rules for the mistakes my own codebase keeps repeating, and schedule a nightly ZAP baseline against staging that opens tickets rather than failing builds. Only after that would I look at AI triage, and I would measure how many true findings it discards before trusting it.

Related: What Is DevSecOps in 2026? 87% Run Exploitable Code, 4% Pin Actions, Vulnerability Management in 2026: 48,185 CVEs, a Triaged NVD, EPSS v5 and GitHub Actions Security in 2026: 76 Hijacked Tags and the Fixes That Work.