SAST vs DAST vs SCA: What Each Catches (and Misses)

If you've shopped for security tooling, you've drowned in three-letter acronyms. The three that matter most — SAST, DAST, and SCA — describe genuinely different techniques that catch genuinely different bugs. Treating any one as 'application security' leaves a hole. Here's what each actually does, with the blind spots stated honestly.

SAST: reading the code at rest

Static Application Security Testing analyses source code without running it. It parses your code into a tree and looks for dangerous patterns: user input flowing into a SQL query, a secret in plaintext, a shell command built from a request parameter, a regex that backtracks catastrophically.

SAST's superpower is that it's early and precise about location. It runs in the editor and in CI, and it points at an exact file and line while the author still has the context. That makes it the cheapest place to catch a whole class of code-level vulnerability.

Its blind spot is runtime and configuration. SAST can't see that your reverse proxy forwards an internal header, that a cookie is missing the Secure flag in production, or that an admin route is reachable without auth — because none of that is visible in the source alone. It also reasons over all paths, so it can flag code that's safe in practice (false positives).

DAST: poking the running app

Dynamic Application Security Testing treats the deployed app as a black box and attacks it: crafted requests, a headless browser, fuzzed payloads. It finds what an attacker would find — broken authentication, missing security headers, a 500 that leaks a stack trace, server misconfiguration.

DAST's superpower is that it tests the real system, with its real config and infrastructure. It catches whole categories SAST structurally can't.

Its blind spot is that it needs something deployed and reachable, it runs later, and a finding describes a symptom (an exposed endpoint) without always pointing at the responsible line. It also only exercises the paths it manages to reach, so coverage depends on how well it's driven.

SCA: auditing what you didn't write

Software Composition Analysis inventories your third-party dependencies and checks them against vulnerability and license databases. Your own code might be flawless and still ship a critical CVE three levels deep in the dependency tree — Log4Shell is the canonical example.

SCA's superpower is reach into code you never read. It answers 'are we shipping a vulnerable package, and where' — the question that turns a CVE disclosure from a multi-day grep into a lookup.

Its blind spot is that it says nothing about how you use a dependency or about your own logic. A package can be CVE-free and still be called in a way that creates a vulnerability — that's SAST's job, not SCA's.

Putting it together

• •Use SAST on every commit for code-level flaws caught early with a precise location.
• •Use DAST against staging on every deploy for runtime and configuration issues.
• •Use SCA continuously for vulnerable and risky dependencies, because the graph changes under you.
• •Expect overlap and gaps: none is a superset of another, and the union is still not 'everything'.

Where GateTest sits

GateTest is primarily a SAST engine — most of its 110 modules read code at rest — with SCA built in (the dependencies and CVE-feed modules) and a DAST slice (the live browser-driven probes that run where a runner and target URL exist). The point isn't that one tool is all three perfectly; it's that one gate covering all three slices beats three disconnected tools with three dashboards and three bills.