What Is Application Security Testing (AST)?

A single unpatched library took down Equifax. The flaw was in Apache Struts, a dependency the application pulled in, and a scanner that read the software bill of materials would have flagged it before the breach. That is the job application security testing does: find the exploitable weakness in code, configuration, and dependencies before an attacker finds it in production.

Application security testing (AST) is not one tool. It is a family of methods that look at software from different angles, at different points in its life. Static analysis reads the source. Dynamic analysis attacks the running app. Interactive analysis watches it from inside. Composition analysis checks the open-source parts you did not write. Each catches a class of flaw the others miss, which is why mature programs run several, not one.

This guide covers what AST is, the four core methods (SAST, DAST, IAST, SCA) with what each finds and where it runs in the pipeline, a side-by-side comparison, where runtime protection like RASP fits, the standards and tools that anchor the practice, and how a blue team reads AST output. It is written for defenders: SOC analysts, AppSec engineers, and DFIR responders who have to turn a scan result into a decision.

What is application security testing?

Application security testing is the practice of evaluating software to find vulnerabilities that an attacker could exploit. It analyzes an application's source code, its dependencies, its configuration, and its runtime behavior, and it does this across the whole software development lifecycle (SDLC) rather than once at the end.

The threats AST hunts for are concrete. Injection flaws like SQL injection, where unsanitized input reaches a database query. Cross-site scripting (XSS), where attacker-controlled script runs in another user's browser. Cross-site request forgery (CSRF), broken access control, insecure deserialization, hardcoded secrets, and known-vulnerable open-source components. These map closely to the OWASP Top 10, the industry reference list of the most critical web application security risks, whose current edition is the 2025 release.

The reason AST is a discipline and not a checkbox is timing and coverage. A flaw caught while a developer is still writing the function costs minutes to fix. The same flaw caught in production, after a breach, costs an incident response. AST pushes detection left, toward the developer and the build, while still testing the running system where some flaws only appear. No single method sees everything, so the practice is defined by combining methods that cover each other's blind spots.

The output of AST is not "secure" or "insecure." It is a prioritized list of findings, each with a location, a severity, and a path to fix it. The work, for a defender, is triaging that list: confirming the real vulnerabilities, discarding the false positives, and routing the rest to the team that owns the code.

The four core methods: SAST, DAST, IAST, SCA

Four methods carry most application security testing programs. They differ on one axis above all: whether they look at the code at rest or the application in motion.

SAST: read the source code

Static application security testing (SAST) analyzes an application's source code, bytecode, or compiled binaries for vulnerabilities without running it. It models how data flows through the code and flags patterns that lead to injection, buffer overflows, hardcoded credentials, and unsafe API use.

SAST runs earliest. It can fire in the developer's editor as code is typed, on every commit, or in the nightly build, because it needs only the code, not a deployed environment. That is its strength: it catches flaws before the application ever runs, and it points the developer at the exact file and line. OWASP notes that SAST "scales well, can be run on lots of software, and can be run repeatedly," and that its output "highlights the problematic code by filename, location, line number, and even the affected code snippet."

The trade-off is false positives and blind spots. Because SAST reasons about code it never executes, it flags paths that cannot actually be reached and produces, in OWASP's words, "high numbers of false positives." It is also weak on flaws that only exist at runtime: authentication problems, access control logic, and configuration issues that are not represented in the code. Tune it, or it drowns the team in noise.

DAST: attack the running application

Dynamic application security testing (DAST) tests a running application from the outside, with no access to the source. It sends crafted requests, much like an attacker would, and watches how the application responds, looking for vulnerabilities that surface only during execution.

DAST runs later, against a deployed build in a test or staging environment. Because it exercises the live system, it finds what SAST cannot: authentication and session flaws, server misconfiguration, exposed endpoints, and runtime injection that depends on the deployed stack. It is also language-agnostic, since it never reads the code. This is the method that probes login flows where threats like credential stuffing and broken authentication live.

Its limits are the mirror of SAST's. DAST cannot tell you which line of code is wrong, only that an input produced a bad response, so remediation takes more digging. It only tests the paths it can reach, so coverage depends on how well it crawls the app, and it runs late enough that fixes are costlier. SAST and DAST are complements, not rivals.

IAST: watch from inside the running app

Interactive application security testing (IAST) instruments the application with an agent so it can analyze code and runtime behavior at the same time. As tests exercise the app, in QA or in automated functional testing, the agent watches data flow through the actual executing code.

IAST sits between SAST and DAST and borrows from both. Because it sees the running app, it confirms a flaw is genuinely reachable, which cuts the false positives that plague SAST. Because it sees the code, it can point at the vulnerable line, which DAST cannot. The result is high-fidelity findings with location and proof of exploitability.

The cost is operational. IAST requires deploying and maintaining an agent inside the application, it adds runtime overhead, and its coverage is only as good as the test traffic that drives it. If your test suite never exercises a code path, IAST never sees it.

SCA: check the code you did not write

Software composition analysis (SCA) inventories the third-party and open-source components an application depends on and flags those with known vulnerabilities or problematic licenses. Modern applications are mostly other people's code, and that is exactly where the Equifax flaw lived.

SCA reads the dependency manifest and the software bill of materials, then matches each component and version against vulnerability databases like the CVE list. It is the only one of the four methods aimed squarely at supply-chain risk: a critical CVE in a logging library you imported three layers deep. OWASP frames it as "the process of automating application security for managing third-party and open-source components," and ships its own SCA tool, OWASP Dependency-Check, which detects publicly disclosed vulnerabilities in a project's dependencies.

SCA does not analyze your own logic at all, so it complements rather than replaces SAST. Its weak point is noise of a different kind: a vulnerable dependency may not be reachable from your code, so reachability analysis matters when triaging SCA findings, or the team chases CVEs that are not actually exploitable.

SAST vs DAST vs IAST vs SCA

The four methods are best read as a matrix of what they see and when they run. Use the table to decide which gaps you still have, not which single tool to buy.

Three takeaways matter more than the cells.

First, no method is complete. SAST and SCA cover the code at rest, first-party and third-party. DAST and IAST cover the application in motion. A program that runs only one of these has a structural blind spot, not a tuning problem.

Second, the methods stack onto the pipeline at different stages, so you do not choose one, you sequence them. SAST and SCA on commit. IAST during functional testing. DAST against staging. Each gate catches what slipped past the last.

Third, the goal is to shift detection earlier without abandoning the late checks. Catching a flaw in SAST on commit is cheapest. But some flaws only exist at runtime, so DAST stays in the pipeline as the backstop. The discipline that wires these checks into the development pipeline is DevSecOps, and AST tools are its instruments.

Where AST fits in the pipeline

AST is most effective when its methods are wired into the continuous integration and delivery (CI/CD) pipeline rather than run as a one-time audit. Each method has a natural home.

In the IDE and on commit, SAST and secrets scanning give the developer feedback in seconds, while the context is fresh. SCA runs here too, flagging a vulnerable dependency the moment it is added to the manifest. These are the cheapest gates, and they keep most flaws from ever reaching the build.

In the build and test stages, SCA re-runs against the full dependency tree, and IAST instruments the app while the functional and integration tests drive traffic through it. This is where findings gain proof of reachability.

Against staging, DAST attacks the deployed build the way an external attacker would, catching the runtime and configuration flaws the earlier gates structurally cannot see. A failed gate here blocks promotion to production.

In production, the testing handoff becomes monitoring and runtime defense. This is where runtime application self-protection (RASP) lives: not a testing method but a control that runs inside the deployed application and blocks exploit attempts in real time. It overlaps with web application firewalls and belongs to the operate phase, after AST has done its work.

The principle is the same one that makes layered detection useful to defenders: place a control at every stage so a flaw that slips one gate trips another. The earlier the catch, the cheaper the fix.

Standards and tooling that anchor AST

AST does not run on vendor marketing. A few open standards and reference tools define the practice, and knowing them keeps you grounded when a tool's output is ambiguous.

The OWASP Foundation is the center of gravity. The OWASP Top 10 (2025 edition) is the canonical list of critical web application risks that AST tools test against and report findings in terms of. The OWASP Application Security Verification Standard (ASVS) provides a tiered checklist of security requirements to test toward. OWASP also maintains the DevSecOps Guideline, which lays out how SAST, DAST, IAST, and SCA slot into a pipeline.

On the tooling side, the open-source anchors are worth naming because they are free to learn on. OWASP ZAP (Zed Attack Proxy) is the reference open-source DAST scanner; as of September 2024 its core team and the project joined Checkmarx, though it remains open source under the Apache 2.0 license. OWASP Dependency-Check is a widely used SCA tool. Semgrep and the open-source ecosystem around it cover SAST. Commercial platforms bundle several methods, but the open tools are enough to understand what each method does and to read its output critically.

Standards matter for triage. When a SAST tool flags "CWE-89," that is the Common Weakness Enumeration ID for SQL injection, a stable identifier you can map across tools. When SCA reports a CVE, that is a specific, dated, publicly disclosed vulnerability you can look up. Findings that reference these shared identifiers are auditable; findings that use only a vendor's private severity scale are not.

How blue teams read AST output

AST belongs to the build pipeline, but its output lands on the blue team's desk during triage, incident response, and vulnerability management. It is also a core piece of cloud security, where applications, containers, and their dependencies are the attack surface. Reading AST output well is a defender skill.

Triage by confirming exploitability. A SAST report with two thousand findings is not two thousand vulnerabilities. The first job is separating the real from the noise: is the flagged path actually reachable, is the input actually attacker-controlled, is the vulnerable dependency actually called. IAST and reachability analysis exist precisely to answer this, and a defender who can read the data flow saves the dev team from chasing false positives.

Map findings to attacker behavior. A DAST finding of reflected XSS or a SCA hit on a remote-code-execution CVE is not an abstract score. It is an entry point an attacker would use. Reading an AST finding as "what does this let an adversary do" is the same instinct used in API security review and in threat modeling, and it is what turns a scanner result into a risk decision.

Feed findings into incident response. When an application is breached, the AST history is evidence. The SCA inventory tells responders exactly which vulnerable component versions shipped. The SAST and DAST findings that were accepted or deferred are a map of where the weakness likely was. A defender who knows the application's known flaws scopes the investigation faster.

Close the loop. Every confirmed finding should become a detection or a control, the same intelligence-driven loop a SOC runs on intrusions. A recurring class of flaw points to a missing secure-coding standard or a gap in the pipeline gates. AST is most valuable when its output changes how the next build is written, not just patched.

The bottom line

Application security testing finds the exploitable flaw in code, dependencies, configuration, and runtime before an attacker does. It is a family, not a product: SAST reads the source, DAST attacks the running app, IAST watches from inside, and SCA checks the open-source parts you imported. Each covers the others' blind spots, which is why programs run several and wire them into the pipeline at the stage where each is cheapest.

The defender's work is not running the scan, it is reading the output: confirming what is exploitable, mapping it to what an attacker could do, and closing the loop so the next build ships fewer flaws. Anchor that work in the open standards, the OWASP Top 10, the CWE and CVE identifiers, so findings stay auditable instead of riding on a vendor's private score. Done well, AST turns "is this app secure" into a list of specific, fixable answers.