Application Security Testing: Complete Guide to SAST, DAST, IAST & RASP (2026)

What is application security testing?

Application security testing (AST) is the process of finding, validating, and fixing security vulnerabilities in software before attackers exploit them. It spans four distinct methods, each examining applications from a different angle: source code analysis, runtime attack simulation, instrumented testing, and runtime self-protection.

Software vulnerabilities remain the single largest attack vector for data breaches. The average breach now costs $4.88 million according to IBM’s 2024 report, and 90% of security incidents trace back to exploitable software defects. Manual code review cannot keep pace with modern development velocity. Automated AST fills that gap.

The AST market crossed $12 billion in 2025 and is growing at roughly 18% per year. That growth reflects a straightforward reality: organizations ship more code, faster, across more platforms than ever before. The attack surface grows with every deployment. AST tools are how security teams keep up.

Four approaches make up the AST landscape:

• SAST (Static Application Security Testing) analyzes source code without executing the application.
• DAST (Dynamic Application Security Testing) attacks running applications from the outside.
• IAST (Interactive Application Security Testing) instruments the application runtime during testing.
• RASP (Runtime Application Self-Protection) defends applications from inside during production.

Each method has strengths and blind spots. No single approach catches everything. The rest of this guide breaks down how they work, what they find, and how to pick the right combination for your team.

The four testing approaches

The testing approaches break down along two axes. White-box methods (SAST) have full code visibility but no runtime context. Black-box methods (DAST) test real behavior but cannot see inside the code. Grey-box methods (IAST) split the difference by instrumenting the runtime. RASP stands apart because it is not a testing method at all. It is a protection mechanism that lives in production.

Most security programs start with SAST and DAST, then layer in IAST or RASP as they mature.

SAST: Static analysis

Static Application Security Testing scans source code for vulnerabilities without running the application. It reads your codebase, builds an abstract syntax tree, and traces data flow from user-controlled inputs to dangerous operations. When untrusted data reaches a database query, a file path, or an OS command without sanitization, SAST flags it.

SAST runs at the earliest possible moment. Developers get results in their IDE as they write code, or on pull requests within minutes. A developer introduces a SQL injection on Monday morning and knows about it before lunch. Fix it before the code merges. That fast feedback loop is why SAST is the foundation of most AppSec programs.

The trade-off is noise. SAST does not execute code, so it cannot distinguish between a genuinely exploitable code path and one that is protected by framework middleware the tool does not model. Untuned SAST tools can produce false positive rates of 30-60%. Tuning matters. So does picking a tool that understands your framework.

SAST catches injection flaws, XSS, hardcoded secrets, insecure cryptography, buffer overflows, and path traversal. It misses server misconfigurations, authentication bypass, missing security headers, and business logic flaws. Those are gaps that DAST fills.

Key tools: Checkmarx, SonarQube, Semgrep, Snyk Code, Fortify, and Veracode SAST. Open-source options like Semgrep, Bandit (Python), and Brakeman (Ruby on Rails) are capable starting points for smaller teams.

Read our full SAST guide for a deeper breakdown. Compare all SAST tools.

DAST: Dynamic testing

Dynamic Application Security Testing attacks a running application from the outside. No source code needed. The tool crawls your web application, discovers endpoints, and fires malicious payloads at them. If the application responds in a way that indicates a vulnerability, DAST reports it.

This is black-box testing. The scanner behaves like an attacker, submitting SQL injection strings, XSS payloads, and directory traversal attempts, then watching for database errors, reflected scripts, or file contents in the response. A finding from DAST is a confirmed exploitable issue, not a theoretical code pattern.

DAST runs against staging or pre-production environments. Full crawl scans can take hours, so most teams run them nightly or weekly. Lightweight scans from tools like Dastardly or ZAP baseline mode can run on every deployment in minutes.

DAST excels at catching what SAST cannot: server misconfigurations, missing security headers, SSL/TLS issues, authentication flaws, and CORS problems. It also tests third-party components and infrastructure that are invisible to source code analysis.

The downside is that DAST cannot tell you which line of code caused the problem. It gives you a URL and a parameter. Developers need to trace the issue back to the source manually, or correlate with SAST findings.

Key tools: Burp Suite, ZAP, Invicti, Acunetix, StackHawk, and Nuclei. ZAP and Nuclei are free and integrate well into CI/CD pipelines.

Read our full DAST guide for a deeper breakdown. Compare all DAST tools.

IAST: Interactive testing

Interactive Application Security Testing places an agent inside your application runtime. As your test suite sends requests to the application, the agent watches untrusted data flow through actual code execution paths. It sees both the code being executed and the runtime behavior, combining the precision of SAST with the real-world context of DAST.

When your integration test submits a form value, the IAST agent traces that input from the HTTP parameter through controller logic, service layers, and data access code. If the input reaches a SQL query without parameterization, the agent reports the vulnerability with the exact file, line number, and full call stack. No guessing required.

This grey-box approach produces the lowest false positive rate of any AST method. The agent only reports vulnerabilities in code paths that are actually executed during testing. If a vulnerable pattern exists in dead code that no request ever reaches, IAST will not flag it. That is both a strength (fewer false positives) and a limitation (coverage depends on test quality).

IAST fits between SAST and DAST in the SDLC. It runs during QA and integration testing. The better your automated test coverage, the more value IAST delivers. For teams already running robust test suites, adding an IAST agent is a low-effort way to validate SAST findings and reduce triage time.

The market is smaller here. Contrast Assess is the clear leader, with a free Community Edition available. Seeker and Datadog IAST are the main alternatives. IAST has fewer players because building a reliable instrumentation agent across multiple language runtimes is technically demanding.

Read our full IAST guide for a deeper breakdown. Compare all IAST tools.

RASP: Runtime protection

Runtime Application Self-Protection is not a testing method. It is a defense mechanism. A RASP agent lives inside your application in production, monitoring requests and blocking attacks in real time. Where SAST, DAST, and IAST find vulnerabilities so you can fix them, RASP stops exploitation attempts whether the vulnerability is patched or not.

RASP works by instrumenting the application runtime the same way IAST does. The difference is the response. When an IAST agent detects a SQL injection attempt during testing, it logs a finding. When a RASP agent detects the same attempt in production, it blocks the request before the malicious query reaches the database.

This makes RASP valuable for virtual patching. A critical vulnerability is disclosed on a Friday afternoon. You cannot deploy a code fix until Monday. A RASP agent can block exploitation attempts for that specific vulnerability within minutes, buying your team time to develop and test a proper fix.

RASP is often compared to Web Application Firewalls (WAFs). The difference is where they sit. A WAF inspects traffic at the network perimeter based on request patterns. RASP inspects behavior inside the application with full context about the code being executed. A WAF might block a request that looks like SQL injection. RASP blocks a request that is actually causing a SQL injection in a specific code path. Fewer false positives, more precise blocking. See our RASP vs WAF comparison for a detailed breakdown.

The trade-off is performance overhead and operational complexity. Embedding a security agent in every application instance adds latency and requires careful configuration to avoid blocking legitimate requests. Adoption is lower than SAST or DAST for this reason.

Key tools: Contrast Protect, Imperva RASP, and OpenRASP. The market is niche compared to SAST and DAST, but growing as organizations look for ways to protect legacy applications that cannot be easily patched.

Read our full RASP guide for a deeper breakdown. Compare all RASP tools.

Choosing the right approach

The right combination depends on where your team stands today. There is no single correct answer, but there are clear starting points based on team size, budget, and application architecture.

Start here: SAST + DAST

Most organizations should run SAST and DAST together. SAST catches code-level flaws early. DAST catches runtime and configuration issues that SAST cannot see. Together they cover the widest range of vulnerability types at the lowest cost, since strong open-source options exist for both.

A practical starting stack:

• SAST: Semgrep or SonarQube Community Edition in CI on every pull request.
• DAST: ZAP or Nuclei against staging on every deployment.

This costs nothing and covers the OWASP Top 10 well.

Add IAST for precision

If your team already runs SAST and DAST but struggles with false positive triage, IAST reduces that burden. It validates SAST findings with runtime evidence and gives developers exact code locations that DAST cannot. Contrast Assess offers a free tier to test the approach before committing budget.

IAST delivers the most value when you have strong automated test coverage. If your test suite only exercises 30% of your code, IAST will only observe 30% of your code.

Add RASP for critical applications

RASP makes sense for applications that handle sensitive data and cannot tolerate any window of exposure between vulnerability disclosure and patch deployment. Financial services, healthcare, and e-commerce platforms are common adopters.

Decision matrix

What catches what

No column in this table is all green. That is why layering matters. Each method fills gaps the others leave open.

AST in the SDLC

Each testing approach fits a specific phase of the software development lifecycle. Placing them correctly maximizes coverage without creating bottlenecks.

Code phase. SAST runs here. Developers get feedback in their IDE (Snyk Code, SonarLint) or on pull requests (Semgrep, SonarQube, Checkmarx). This is the cheapest point to fix vulnerabilities. A bug caught during code review costs a fraction of one found in production.

Build phase. SAST quality gates block merges when critical findings appear. SCA tools scan dependency manifests for known vulnerabilities. Both run in the CI pipeline and finish in minutes.

Test phase. IAST agents observe the application during QA and integration testing. DAST runs lightweight scans against ephemeral review environments. Both produce findings that map to specific test scenarios.

Staging phase. Full DAST crawls run against the staging environment. These longer scans cover the entire application surface, including pages and flows that quick CI scans skip. Findings here are the last gate before production.

Production phase. RASP agents protect running applications by blocking exploitation attempts in real time. Continuous DAST scanning monitors for newly introduced vulnerabilities or configuration drift.

This is the shift-left model in practice. Push testing as early in the pipeline as the method allows. SAST shifts all the way left to the IDE. DAST and IAST sit in the middle. RASP covers what is already deployed.

Place each tool where it delivers the most value, so vulnerabilities get caught at the earliest and cheapest point possible. For a full walkthrough of building this pipeline, see our Secure SDLC guide.

Browse Tools by Category

This hub covers 4 application security categories with 72 tools total. Dive into any category to compare tools, read reviews, and find the best fit for your stack.

Learning Resources

Deepen your understanding with these in-depth guides covering key concepts, tool comparisons, and implementation strategies.

Frequently Asked Questions

Written by

Suphi Cankurt

Suphi Cankurt is an application security enthusiast based in Helsinki, Finland. He reviews and compares 154 AppSec tools across 10 categories on AppSec Santa. Learn more.