Let's Get the Dirty Secret Out of the Way
Every AppSec vendor on the planet will tell you their tool "shifts security left" and "finds critical vulnerabilities before they reach production." And every single one of them is lying by omission. Not because their tools don't work — most of them do something useful — but because none of them do what the marketing slide deck implies: actually secure your application.
I've spent the better part of a decade building AppSec programs, and the single most expensive lesson I've learned is this: the choice between SAST, DAST, and IAST matters way less than how you operationalize whatever you pick. But it does still matter. So let's talk about what each one actually does, what it's good at, what it's terrible at, and where the industry keeps getting this wrong.
SAST: Your Paranoid Code Reviewer Who Never Sleeps (and Never Shuts Up)
Static Application Security Testing reads your source code — or bytecode, or binaries — without ever executing it. It builds abstract syntax trees, does taint analysis, tracks data flow from sources to sinks, and flags patterns that look like vulnerabilities. Tools like SonarQube, Semgrep, Checkmarx, and Fortify all live in this space, though they approach the problem very differently.
Semgrep, for instance, is pattern-based. You write rules that look almost like the code you're trying to match, and it finds instances. It's fast, it's developer-friendly, and it's phenomenal for enforcing "never do this specific dangerous thing" rules. Checkmarx and Fortify go deeper — they do inter-procedural data flow analysis, tracing a user input through seventeen function calls and three class boundaries to see if it ever hits a SQL query unsanitized. That depth is powerful. It's also why a Fortify scan on a large Java codebase can take four hours and produce a report with 3,000 findings, 2,400 of which are garbage.
And that's the fundamental tension with SAST. The more thorough the analysis, the more false positives you drown in. I once inherited an AppSec program where the previous team had turned on Fortify with default rules across 40 microservices. The backlog had fourteen thousand open findings. Developers had completely stopped looking at them. The tool was running, the reports were generating, and security theater was being performed at enterprise scale. It took us six months of rule tuning, custom suppressions, and ruthless triage to get that backlog to something actionable.
What SAST genuinely excels at: finding injection flaws where you can trace the data flow. SQL injection, XSS, path traversal, command injection — the classic CWE Top 25 stuff where tainted input flows to a dangerous sink. It's also great for finding hardcoded secrets, weak cryptographic configurations, and use of known-dangerous APIs. Semgrep rules for things like yaml.load() without Loader=SafeLoader in Python, or dangerouslySetInnerHTML in React — those are high-signal, low-noise wins.
What SAST is bad at: anything that requires understanding runtime state. It can't tell you about authentication bypass bugs because it doesn't understand your auth model. It can't find SSRF vulnerabilities where the exploitability depends on your cloud network topology. It has no concept of your deployment environment. And it fundamentally cannot find business logic flaws — "users can apply a discount code twice" isn't a pattern any AST analysis will catch.
DAST: Throwing Rocks at the Black Box
Dynamic Application Security Testing takes the opposite approach. It doesn't look at your code at all. It interacts with your running application over HTTP, fuzzing inputs, crawling endpoints, and analyzing responses for signs of vulnerability. OWASP ZAP and Burp Suite are the heavyweights here, though they serve slightly different audiences — ZAP being the open-source workhorse you integrate into CI/CD, Burp being the Swiss Army knife that every pentester has open on their second monitor.
The appeal is obvious: DAST tests what's actually deployed. It doesn't care what language you wrote it in. It doesn't need access to source code. It finds the vulnerabilities that are actually exploitable in your running environment, with your actual configurations, your actual WAF (or lack thereof), your actual middleware stack.
But here's where it gets painful.
DAST is slow. A comprehensive ZAP active scan against a modern SPA with fifty API endpoints can take 30-90 minutes. In a CI/CD pipeline where developers expect feedback in under ten minutes, that's a non-starter for blocking merges. So you end up running it asynchronously — maybe nightly, maybe as a gate before staging-to-production promotion — and now you've lost the fast feedback loop that makes security testing useful.
DAST also struggles with coverage. It can only test what it can reach. If your crawler can't navigate a complex multi-step workflow — say, an insurance quote flow that requires valid data at each step — it's just not going to test those endpoints. Authentication is another nightmare. You can configure ZAP with session tokens, but maintaining those configs as your app evolves is a constant tax. I've seen DAST scanners happily report "no vulnerabilities found" because they spent the entire scan getting 401 responses and nobody noticed.
Where DAST shines is finding things SAST literally cannot: server misconfigurations, missing security headers, CORS misconfigurations, actual reflected XSS that's exploitable through the full HTTP stack, and — this is underappreciated — vulnerabilities in third-party components and middleware that you didn't write and don't have source for. Your SAST tool will never find that your Apache Struts version is exploitable. A good DAST scan might, because it's testing the behavior, not the code.
IAST: The Approach Nobody Talks About (Because It's Complicated)
Interactive Application Security Testing is the weird middle child, and honestly, I think it's the most technically interesting of the three. IAST works by instrumenting your application at runtime — typically via an agent that hooks into the language runtime (JVM, .NET CLR, Node.js process). It watches data flow while the application is actually executing, so it gets the source-to-sink analysis of SAST combined with the runtime context of DAST.
Contrast Security is the dominant player here, and their approach is genuinely clever. The agent sits inside your app, observes every HTTP request, tracks tainted data through the actual execution path, and flags when that data reaches a dangerous operation without proper sanitization. Because it's watching real execution, the false positive rate drops dramatically compared to SAST. When Contrast says "this input reached this SQL query unescaped," it's not guessing based on static analysis — it watched it happen.
So why isn't everyone using IAST?
Performance overhead, deployment complexity, and language support. Instrumenting a JVM adds latency — typically 2-5%, but I've seen it spike higher under load. For a low-latency trading platform or a real-time system, that's a dealbreaker. The agent needs to be deployed with your application, which means changes to your Docker images, your deployment manifests, your Helm charts. And if you're running a polyglot microservices architecture with Go, Rust, Python, and Java services, your IAST coverage is going to be spotty because agent support varies significantly by language.
There's also a subtler problem: IAST only analyzes code paths that are actually exercised. If your QA suite doesn't hit an endpoint, IAST doesn't test it. So your IAST coverage is directly bounded by your test coverage and your QA team's thoroughness. That's a dependency most security teams don't love.
But when it works — when you've got a Java or .NET monolith with solid functional test coverage and you can tolerate the agent overhead — IAST produces the highest-signal findings of any automated approach I've used. Confirmed, exploitable, with a full data flow trace through actual execution. Developers actually fix those findings because the evidence is irrefutable.
Where Each One Lives in Your Pipeline (And Why You'll Get This Wrong the First Time)
Here's what a mature AppSec pipeline looks like — and I mean actually looks like in organizations that have iterated on this, not the vendor reference architecture that assumes infinite engineering time.
SAST goes in the PR/merge request. You run Semgrep or your SAST tool of choice as a GitHub Actions check or a Jenkins pipeline stage that triggers on every pull request. But — and this is critical — you run it with a curated, high-confidence rule set. Not everything. Not the kitchen sink. You pick the 50-100 rules that have a <10% false positive rate in your codebase and you block merges on those. Everything else goes into an informational report that the security team triages weekly. I've seen teams set this up in a single .github/workflows/sast.yml file that runs Semgrep in under two minutes. That's the sweet spot.
DAST runs nightly against staging. You point ZAP at your staging environment, let it crawl and scan overnight, and pipe the results into your vulnerability management system. Nobody's merge is blocked. Nobody's waiting. The security team reviews results the next morning, confirms real issues, and files tickets. For extra credit, you run a lightweight ZAP baseline scan (passive only, no active fuzzing) as part of your deployment pipeline — that adds maybe 3-5 minutes and catches missing headers, cookie flags, and other low-hanging misconfigurations before they hit production.
IAST rides along with your QA/integration test suite. If you're using it, the agent is deployed in your test environment and passively analyzes traffic generated by your automated test suite and manual QA. It generates findings continuously as tests run. This is where IAST really earns its keep — it turns your existing QA investment into security testing without any additional test authoring.
The mistake I see teams make constantly: trying to do all of this at once, day one. Don't. Start with SAST in PRs with a minimal rule set. Get developers used to it. Tune it. Then add DAST nightly. Then consider IAST if your stack supports it. Trying to boil the ocean on week one is how you end up with fourteen thousand ignored findings and a demoralized engineering team.
The SCA Elephant Sitting Right There in the Room
We need to talk about Software Composition Analysis, because it's quietly more important than all three of the above combined. And yes, I know this post is about SAST/DAST/IAST, but ignoring SCA in this conversation is malpractice.
The vast majority of code in your application wasn't written by your developers. It was pulled in via npm, pip, Maven, NuGet, or whatever package manager your ecosystem uses. And the vulnerabilities in those dependencies — the Log4Shells, the Spring4Shells, the prototype pollution du jour — aren't going to be found by SAST (which analyzes your code, not library internals), DAST (which might catch the symptom but won't tell you it's CVE-whatever in version X.Y.Z), or IAST (same limitation as DAST).
Tools like Snyk, Dependabot, Renovate, and Grype exist specifically for this. They check your dependency manifests against vulnerability databases and tell you what's exposed. If you're building an AppSec program and you haven't set up SCA yet, stop reading this and go do that first. Seriously. The ROI on SCA is embarrassingly high compared to the effort required. Dependabot is literally free and takes five minutes to enable on a GitHub repo.
The Thing None of These Tools Will Ever Find
I want to end on something that keeps me up at night as someone who builds AppSec programs.
You can run SAST, DAST, IAST, and SCA. You can have 100% code coverage on your Semgrep rules. You can run ZAP against every endpoint. You can instrument every service with Contrast. And you will still miss the bugs that actually cost your company money.
Business logic vulnerabilities don't have signatures. There's no CWE for "user can manipulate the order of API calls to get a premium feature for free." No scanner will flag "the referral bonus is credited before the referred user's payment is verified." No data flow analysis catches "an admin can export another tenant's data by modifying the tenant ID in the export job parameters, because the authorization check only validates the admin role, not the tenant scope."
These are the bugs that show up in your bug bounty program. These are the bugs that sophisticated attackers exploit. And the only way to find them is manual security review by someone who understands both the code and the business domain — threat modeling, design reviews, and skilled penetration testing by humans who think like attackers.
Automated tools are necessary. They catch the low-hanging fruit at scale, and that's genuinely valuable — you don't want your pentesters wasting time finding reflected XSS that Semgrep could have caught in a PR. But they're not sufficient. If your AppSec program is nothing but tool output, you're playing defense with one arm tied behind your back.
The tools find the bugs in the code. Humans find the bugs in the design. You need both, and the organizations that figure out how to balance that investment are the ones that actually end up secure.