What is the difference between SAST, DAST and SCA, and what kind of vulnerability does each one miss?

Short answer

SAST finds risky patterns in code, DAST probes the deployed app from the outside, and SCA flags vulnerable dependency versions. None is complete: SAST misses runtime behavior, DAST misses unreachable paths, SCA misses misuse, and all three miss many business-logic authorization bugs.

Keep appsec explicit in the answer because that is the concept the interviewer is actually trying to test. A good appsec explanation names the trade-off, the failure mode, and the evidence you would use before choosing. Use appsec once more at the decision point so the answer reads as judgement rather than a detached example.

Keep appsec explicit in the answer because that is the concept the interviewer is actually trying to test. A good appsec explanation names the trade-off, the failure mode, and the evidence you would use before choosing.

What each tool is actually looking at

Static application security testing reads source code, bytecode or an intermediate representation without running it, matching patterns against known vulnerability classes: string concatenation flowing into a SQL statement, an unescaped variable landing in an HTML template, a hard-coded credential. Because it never executes anything, it can reach every line in the codebase, including code paths that are hard to trigger from outside — an admin-only branch, an error handler, a feature flag nobody has turned on in months.

That completeness is also its weakness: SAST reasons about the code's structure, not its behaviour, so it cannot tell whether a web application firewall sits in front of the vulnerable endpoint, whether the input is sanitised three calls upstream in a way the analysis loses track of, or whether a misconfigured server header is exposing the same class of risk with no source-level trace at all.

Dynamic application security testing takes the opposite stance: it treats the running application as a black box and attacks it the way an external actor would, sending malformed input to live endpoints and observing the response. This catches what SAST structurally cannot — misconfiguration, issues that only appear once request handling, session management and the actual deployed environment interact, and vulnerabilities in code the scanner never had source access to, such as a third-party service exposed at the edge. The cost is that DAST can only find what it can reach.

An endpoint behind an authentication flow the scanner never navigates, or one that a nightly crawl simply never discovers because it isn't linked from anywhere, is invisible to it, and a DAST report is silent about code that was never exercised, not clean of it.

Software composition analysis is different again: it doesn't analyse your code at all, it inventories your dependencies and checks each one's version against known-vulnerability databases. This is the tool that catches the class of risk your own SAST and DAST scans will never see, because the vulnerable code lives in a library you imported and neither wrote nor tested.

Its blind spot is equally specific: SCA flags a vulnerable version regardless of whether your application actually calls the vulnerable function, which produces a large volume of findings that are technically true and practically irrelevant, and it says nothing about a dependency being used correctly versus dangerously — a cryptography library with no known CVE can still be misused in a way that breaks confidentiality, and that misuse is invisible to a tool that only checks version numbers.

Why the coverage does not simply add up

The instinct to say "run all three and you're covered" undersells the problem, because the three tools' blind spots are not the complement of each other's strengths in any clean sense. A business-logic flaw — an API that lets a user cancel someone else's order by changing an identifier in the request — is invisible to all three.

SAST sees a syntactically valid database call with no obvious injection; DAST sees a 200 response to a request that is, by the shape of the HTTP traffic, indistinguishable from a legitimate one; SCA has nothing to say about application logic at all. This is the gap interactive application security testing and manual review exist to close, and it is worth naming unprompted, because it demonstrates you understand these tools as a partial, overlapping net rather than a complete solution.

Class of vulnerability            SAST    DAST    SCA
---------------------------------------------------------
SQL injection in first-party code   yes    yes     no
Vulnerable library version          no     rarely  yes
Misconfigured TLS / headers         no     yes     no
Business-logic authorisation flaw   no     no      no
Dependency misused but not itself
  vulnerable                        no     no      no

The triage problem is the real cost

The trap in this question is treating tool selection as the whole answer, when the operational cost is triage volume. SAST in particular is notorious for a high false-positive rate on unfamiliar codebases, because the analysis has to guess at intent it cannot fully reconstruct, and SCA floods a report with dependency findings regardless of reachability. A team that turns all three on without a triage process — severity thresholds, reachability analysis to filter unused vulnerable code paths, and an owner for the backlog — gets a report nobody reads, which is a worse security posture than running fewer tools well, because the alerts that matter drown in the ones that do not.

Each tool answers a different question — what does the code say, what does the running app do, what did we import — and none of them answers what the application is supposed to do, which is where the vulnerabilities a scanner cannot find are hiding.

---

© 2026 Preptima. Originally published at preptima.com.