SAST, DAST, IAST and SCA: what each finds and what each misses

What can none of these tools find?

Authorisation errors, tenant isolation failures and business logic abuse. A scanner can see that a route exists, that a query runs and that a response returns, but it cannot see that the query was missing a predicate restricting rows to the caller's organisation. Nothing in the code looks wrong. The vulnerability lives in the gap between what the code does and what someone intended it to do, and that intent is not written anywhere the tool can read.

The same limitation covers price manipulation, replayed state transitions, workflow steps taken out of order and quantity fields that accept negative numbers. These are the findings that dominate real penetration test reports and real incidents, and they are found by people who understand the application, not by pattern matching.

Here is a test worth running this week. Take your last penetration test report, or the last three security incidents, and write next to each finding which tool in your pipeline would have caught it. Teams commonly discover that half the list has no tool against it at all, which reframes the budget conversation from buying another scanner to funding review time.

What does SAST actually prove?

That untrusted input can reach a dangerous function without passing through something the tool recognises as a sanitiser. Static analysis parses your source or bytecode, builds a model of data flow, and traces paths from sources such as request parameters to sinks such as query execution, command invocation or template rendering. When the trace completes, you have a real finding with a real path, and that is genuinely valuable for injection, path traversal, unsafe deserialisation and hardcoded cryptographic material.

Its accuracy depends entirely on how well the engine models your framework. Dependency injection, reflection, dynamic dispatch, decorators and anything that resolves a target at runtime break the trace, and the tool either loses the path or invents one. This is why the same product performs respectably on a conventional Java service and produces noise on a metaprogramming-heavy codebase, and why you should evaluate a SAST tool on your repository rather than on a demonstration application.

The practical consequence is that SAST tells you about a class of bug in code you wrote, and says nothing about configuration, deployment or the routes that were left unauthenticated. It also cannot tell you whether the vulnerable path is reachable in production, because it has no idea which routes are exposed.

What does DAST actually prove?

That the application, as deployed, responds badly to hostile input at a URL the scanner could reach. Dynamic testing sends requests and reads responses, which gives it two things static analysis cannot have: it tests the real configuration, including headers, cookie flags, TLS settings and redirects, and every finding is by definition reachable, because the tool just reached it.

Reachability is also the constraint. A DAST run is bounded by what the crawler discovered, and modern applications are hostile to crawlers. Single-page front ends, multi-step flows, forms with server-side tokens, anything behind a login and anything that requires a valid business state will be skipped silently. The scanner does not report the pages it failed to find, so a clean report from a shallow crawl looks identical to a clean report from a thorough one.

That makes authenticated scanning the whole game. Before you trust a DAST result, check what proportion of your route table the run actually touched. If the tool cannot tell you, the number you have is coverage-unknown, and treating it as an assurance is the mistake.

How do the four families compare?

They differ in what they observe rather than in quality, which is why the sensible question is what each one is evidence of. The table also includes the two scanners most teams actually run daily, image scanning and secret detection, because in practice they are part of the same pipeline decision.

Where do IAST and SCA earn their place?

IAST earns it on accuracy. An agent loaded into the runtime watches actual values move through actual calls while your tests run, so a reported taint path happened rather than being inferred. False positives drop sharply compared with static analysis. The trade is stark: coverage equals test coverage, so a service with thin integration tests gets a thin security result, and the agent has to support your runtime version.

SCA earns it on volume of real risk. Most code in a modern application was written by somebody else, and known vulnerabilities in that code are published, indexed and trivially exploitable once a proof of concept circulates. Composition analysis reads your dependency graph and matches it against advisory data, which is the single highest-yield automated check available to most teams.

Its weakness is that it reports presence, not exposure. A vulnerable library that is installed but never imported produces the same alert as one on your request path. Tools that add reachability analysis, tracing whether your code can actually call the affected function, cut the actionable list dramatically, and that capability is worth more than any difference in database size.

Which one should you buy first?

Secret scanning, then SCA, in that order, and both before anything else. Secret detection has almost no false positive problem when configured to verify credentials, and a leaked live key is an active compromise rather than a theoretical weakness. SCA follows because it addresses the largest volume of genuinely exploitable, already-public risk and needs no application knowledge to interpret.

SAST comes third, scoped to the sink categories you care about rather than every rule the vendor ships, because an unfiltered first run on an established codebase produces a backlog nobody will process. DAST is worth adding once you have a staging environment that can be authenticated into reliably. IAST is a refinement for teams with strong automated tests, not a starting point.

None of that addresses the access control gap, so budget for review as a line item rather than hoping tooling covers it. A short, focused review of authorisation checks on your highest-value endpoints, done by someone who understands the domain, finds a class of bug that no purchase will.