IM Engineer Study Notes
← Back to list
Security & Privacy
#SAST#DAST#IAST#DevSecOps#SCA
Last updated · 2026-10-16

Application Security Testing (SAST, DAST, IAST)

1. Overview

Definition: Application Security Testing (AST) is a family of techniques that analyze an application's source code, executable binaries, or running service to identify and remove security vulnerabilities before release and operation. It is broadly divided into SAST, which statically analyzes code without executing it; DAST, which attacks a running application from the outside; and IAST, which embeds instrumentation (an agent) in the runtime to observe internal flows.

Behind application security testing's emergence as a distinct engineering discipline lies the "economics of vulnerabilities." A defect that would be a trivial fix if found in the requirements or design phase balloons into tens of times the cost — incident response, legal liability, brand damage — if it detonates in production. This is an old insight of software economics, and for security defects the asymmetry is even more extreme, because a single line of SQL injection can lead to the breach of millions of personal records. Hence the Shift-Left philosophy of "catch defects as far left (as early) as possible" became the starting point of security testing.

Another backdrop is the fact that applications have become an organization's largest attack surface. As the era of guarding the network perimeter with firewalls and segmentation faded, and business logic itself was exposed externally through web, API, and mobile channels, attackers' main intrusion path shifted from the network to the application. With open source dependencies now accounting for 70–90% of code, organizations must answer even for vulnerabilities in "code they did not write" (e.g., Log4Shell). This made a testing regime that repeatedly and automatically proves code is safe indispensable.

This shift extends the center of gravity of quality assurance from "does it work" to "can it be exploited." Where traditional testing confirmed the happy path that behaves as specified, security testing explores inputs, states, and flows the designer never intended, from the attacker's perspective. It asks not "what should it do" but "what can it be forced to do." This change of perspective gave rise to the distinct measurement points of SAST, DAST, and IAST.

This change of perspective also turns security testing from "a one-time pass/fail verdict" into a continuous risk-measurement activity. Code changes every day and new vulnerabilities (CVEs) are disclosed every day, so a system safe yesterday can be vulnerable today. Security testing therefore becomes not a single gate just before release but a standing process repeated in step with code changes and threat-intelligence updates. This "repeatability" makes automation and pipeline integration an inevitable requirement.

The essential characteristics of application security testing can be summarized in four points. First, lifecycle embedding — it dissolves into the CI/CD pipeline as an automated stage rather than a separate audit act. Second, multi-layer visibility — it views code (static), execution (dynamic), and components (dependencies) in complementary fashion. Third, risk-based prioritization — it does not treat every discovered vulnerability with equal weight but filters by exploitability and impact. Fourth, developer friendliness — it is designed so that developers, not security specialists, receive results immediately in their IDE and PRs. These four traits show that security testing has evolved from a post-hoc inspection into part of the development flow itself.

2. Overall Structure of Application Security Testing

Application security testing places different techniques at each stage of the SDLC (software development lifecycle), forming a multi-layered defense that filters vulnerabilities layer by layer from the moment code is written through operational monitoring. The concept diagram below shows the overall structure of where each technique sits atop the development flow.

flowchart LR
  subgraph DEV["Development"]
    IDE["IDE/Coding"]
    SCA1["SCA(Dependency Analysis)"]
    SASTX["SAST(Static Analysis)"]
  end
  subgraph BUILD["Build/Integration (CI)"]
    BUILDX["Build/Unit Test"]
    IASTX["IAST(Instrumentation)"]
  end
  subgraph TEST["Test/Staging"]
    DASTX["DAST(Dynamic Scan)"]
    PENX["Penetration Test(Manual)"]
  end
  subgraph OPS["Operations"]
    RASPX["RASP(Runtime Protection)"]
    ASOC["ASPM(Result Correlation/Management)"]
  end
  IDE --> SASTX --> BUILDX
  SCA1 --> BUILDX
  BUILDX --> IASTX --> DASTX --> PENX --> RASPX
  SASTX -.->|aggregate| ASOC
  DASTX -.->|aggregate| ASOC
  IASTX -.->|aggregate| ASOC
  SCA1 -.->|aggregate| ASOC

In the development stage, SAST and SCA are placed at the very point where code is created. The moment a developer writes code in the IDE or raises a PR (Pull Request), static analysis runs to point out vulnerable patterns, and SCA warns of known vulnerabilities (CVEs) in the open source libraries pulled in. The core value at this point is the immediacy of feedback. Because results arrive while the developer still remembers the context of the code just written, the cost of fixing is lowest.

In the build/integration stage, the application actually begins to compile and run, so IAST — which observes execution flows — becomes effective. When functional tests run on the CI server, an instrumentation agent runs alongside to observe whether vulnerable data flows actually occur on the code paths the tests exercised. It sits at a position that simultaneously compensates for the "code-only" limitation of static analysis and the "outside-only" limitation of dynamic analysis.

In the test/staging stage, DAST scans the completed application deployed in a production-like environment with the eyes of an external attacker, and critical systems add expert manual penetration testing to verify business-logic flaws that automation misses. In the operations stage, RASP blocks attacks in real time during execution, and ASPM (Application Security Posture Management) gathers results from every tool in one place to deduplicate and correlate risk. Thus the essence of the overall structure is not a single technique but a combination of stage-specific techniques.

3. Key Techniques and Operating Principles

The core of application security testing is the four techniques — SAST, DAST, IAST, and SCA — distinguished by "at what point, with what, and how" they find vulnerabilities. The concept diagram below shows how the four techniques access different representations of the application (code, execution, external interface).

flowchart TB
  SRC["Source/Bytecode"]
  RUN["Running Application"]
  DEP["External Dependencies(Open Source)"]
  SAST2["SAST Engine<br/>Data Flow/Taint Analysis"]
  IAST2["IAST Agent<br/>Runtime Instrumentation"]
  DAST2["DAST Scanner<br/>HTTP Request Tampering"]
  SCA2["SCA Engine<br/>SBOM/CVE Matching"]
  SRC --> SAST2
  SRC --> IAST2
  RUN --> IAST2
  RUN --> DAST2
  DEP --> SCA2
  SAST2 --> REP["Vulnerability Report"]
  IAST2 --> REP
  DAST2 --> REP
  SCA2 --> REP

A. SAST (Static Application Security Testing) analyzes source code, bytecode, or binaries without executing the application. Its core principle is taint analysis: starting from the point where untrusted external input enters (Source), it traces the data flow of that value as it passes through variables and functions until it reaches a dangerous operation (Sink, e.g., SQL query, command execution, file access). If no appropriate validation/escaping (Sanitizer) exists along this path, it reports an injection vulnerability.

SAST's greatest strength is completeness of coverage and earliness. It can analyze all code paths, including those tests never actually exercise, and it presents the exact file and line number of a vulnerability, making it easy for developers to fix. Because only code is needed, it can run from early development without configuring a runtime environment. Conversely, because it does not know the execution context, its destined limitation is a high rate of false positives — reporting as vulnerabilities even "statically unreachable paths" or "inputs neutralized at runtime." The phenomenon of "alert fatigue," where thousands of alerts flood a large codebase until developers tire and ultimately ignore them, is SAST's greatest operational challenge.

SAST's accuracy sits on a trade-off between analysis depth and performance. The deeper the flow-sensitive and path-sensitive analysis, the fewer false positives, but analysis time grows exponentially and delays CI. In structures hard to track statically — reflection, dynamic loading, a framework's implicit calls — the data flow breaks and false negatives arise. In practice, therefore, teams combine incremental scans (analyzing only changes) instead of full re-analysis, ruleset customization, and organizational baselines to find the "fast enough yet accurate enough" point through operational tuning.

B. DAST (Dynamic Application Security Testing) sends actual offensive requests from the outside to a running application and observes the reactions. Approaching as a black box without source code, it most closely resembles the attacker's real view and catches deployment- and configuration-level vulnerabilities that code alone does not reveal — server misconfigurations, authentication bypass, session-management flaws. For example, DAST injects a payload like ' OR '1'='1 into an input form and analyzes error messages, delays, and returned data in the response to prove actual exploitability.

DAST's strength is low false positives and empirical evidence. Because it actually elicited a response, a reported vulnerability is generally genuinely exploitable. However, since the application must be complete and runnable, discovery is late; screens and APIs the scanner cannot reach go unchecked, so coverage is incomplete; and it does not tell where in the code a vulnerability originates, requiring extra analysis to locate the fix. Its difficulty in automatically exploring stateful complex workflows or areas requiring authentication is also a limitation.

Recently, as structures where screens and APIs are intricately intertwined — SPA (Single Page Application), GraphQL, microservices — have become common, the coverage gap of traditional crawling-based DAST has widened. To compensate, API-centric DAST, which takes an API specification (OpenAPI/Swagger) as input to systematically explore endpoints, and hybrid approaches, in which the scan scope is guided by internal path information gathered by an IAST agent, are spreading. This is an attempt to compensate for DAST's fundamental "outside-only" limitation with internal visibility.

C. IAST (Interactive Application Security Testing) emerged to bridge the gap between SAST and DAST. By embedding an instrumentation agent in the application's runtime (e.g., JVM, runtime), it observes from the inside the data flows, function calls, and actual query executions while functional tests or DAST drive the application. That is, it simultaneously secures the external request (dynamic) and the internal code path (static-level information), so it reports only "actually executed vulnerable paths" together with their exact code location.

IAST's decisive strength is the coexistence of extremely low false positives and accurate location reporting. Because it sees only executed flows, false positives of unreachable paths vanish, and thanks to internal instrumentation it pinpoints the vulnerability's code line. It also runs automatically riding on the functional tests of the CI pipeline, so it adds almost no separate scan time. However, because the agent is tied to a specific language/runtime, supported stacks are limited, runtime instrumentation imposes a slight performance overhead, and above all it sees only paths that tests execute, so coverage is bound by the quality of functional tests.

D. SCA (Software Composition Analysis), unlike the three techniques above that look at "code written directly," analyzes the open source and third-party components pulled in. It parses the project's dependency tree to build an SBOM (Software Bill of Materials), matches each component's version against known vulnerability databases (NVD/CVE), and even checks for license violations. In a reality where most modern application code is open source, SCA has become not a choice but a necessity, and after the Log4Shell incident it rose to a core axis of supply chain security.

SCA's difficulty lies in transitive dependencies. Libraries a developer declares directly (direct dependencies) are within their control, but the dozens to hundreds of sub-dependencies those libraries pull in are outside the developer's view while holding the same execution privileges. A substantial share of actual vulnerabilities hides in these transitive dependencies, so mature SCA recursively parses the entire dependency graph and further distinguishes fix priorities through reachability analysis of "is the vulnerable function actually called." Treating every CVE with equal weight again leads to alert fatigue.

4. Technique Comparison and Application Cases

The difference among the four techniques stems not from a mere feature difference but from a difference in observation point — "which representation of the application is viewed, and when" — and that difference in turn creates structural differences in false-positive rate, time of discovery, and ease of fixing. The table below organizes the core axes.

Category SAST DAST IAST SCA
Analysis target Source/bytecode Running app (outside) Running app (inside instrumentation) Open source dependencies
Approach White box Black box Gray box Component matching
Application timing Early development Test/staging Build/integration Early development
False-positive tendency High Low Very low Low
Fix-location pointing Precise (code) Difficult Precise (code) Component-level
Representative limitation Alert fatigue Late discovery/coverage Stack dependence/path dependence Known vulnerabilities only

The principle underpinning the table's numerical tendencies is the difference in "amount of observed information." SAST sees all code paths but lacks execution context, so false warnings are many (FP↑); DAST sees only execution reactions, so falsehoods are few but, not knowing the code internals, it cannot point to the fix location; IAST sees execution and code internals at once, so its false positives are lowest and its location precise, but what it saw is only the "executed paths," so coverage is subordinate to test quality. In other words, the pros and cons of the three techniques are determined structurally not by design philosophy but by the kind and amount of information each technique can access.

The core of this comparison is not that any one is superior but that they are complementary. SAST catches early with complete coverage but has many false positives; DAST is empirical but late and incomplete; IAST takes the strengths of both but is confined to executed paths. Mature organizations therefore adopt a multi-layer combination strategy of "filter broadly on the left with SAST+SCA, verify precisely in CI with IAST, and empirically prove just before deployment with DAST + penetration testing." Adopting only one inevitably leaves a blind spot.

As a concrete case, the 2017 Equifax breach exposed the personal information of about 147 million people because a known remote-code-execution vulnerability in Apache Struts (CVE-2017-5638) went unpatched. This vulnerability lay not in code the organization wrote but in a framework it pulled in, so it was hard for SAST to catch and an area SCA would have warned of immediately. This incident imprinted the importance of supply chain component management (SCA/SBOM) across the entire industry.

As another case, 2021's Log4Shell (CVE-2021-44228) was a flaw in the globally used logging library Log4j, affecting hundreds of millions of systems. Many organizations faced a lack of visibility — "we do not even know where we use Log4j" — which became a turning point showing that without an accurate SBOM and SCA automation, one is helpless against supply chain incidents. Third, one financial fintech company reported that after introducing IAST into its CI pipeline, it reduced false positives by over 80% compared to its existing SAST and shortened the average vulnerability-fix lead time from weeks to days — demonstrating IAST's practical value that "reducing false positives translates directly into developer trust and fix speed."

5. Deep Dive — DevSecOps, ASPM, and AI-Based Trends

The biggest recent trend in application security testing is full embedding into DevSecOps. The old "gatekeeper" model, where the security team inspects once just before release, clashes with the speed-demanding agile and cloud-native environment. Instead, security testing has evolved toward being embedded as automated stages at each point of code commit, PR, and build, so developers receive immediate feedback within their own workflow. The key metric shifted from "how many vulnerabilities were found" to "do developers actually fix them," and accordingly developer experience (DevEx) — reducing false positives and presenting fix guidance — became a core criterion in tool selection.

The second trend is the rise of ASPM (Application Security Posture Management). Running SAST, DAST, IAST, and SCA separately causes the same vulnerability to be reported redundantly and makes it hard to judge which is truly risky. ASPM aggregates and normalizes results from multiple tools into one platform and connects the context of code-build-runtime-operations to correlate and prioritize risk by exploitability (reachability) and business impact. This is a shift that moves the center of security testing from "a list of tools" to "integrated management of risk."

The third is the two-sided impact of AI/LLMs. On the defensive side, generative AI explains the root cause of vulnerabilities in natural language and proposes fix code (patches) to ease developers' burden, and it is used in intelligent triage that filters false positives by context. On the offensive side, vulnerabilities creep into code generated by AI coding assistants, and vulnerabilities unique to LLMs, such as prompt injection, emerge, creating areas traditional SAST and DAST cannot handle. Accordingly, security testing techniques aimed at applications that AI generates and runs are themselves emerging as a new research area. In addition, supply chain security regulations (U.S. Executive Order 14028, the EU CRA, etc.) mandating SBOM submission are rapidly raising SCA's strategic weight.

6. Considerations and Implications

From a professional engineer's perspective, adopting application security testing should be approached not as tool selection but as a strategic task spanning process, culture, and governance.

  • Rejecting the single-technique illusion and a multi-layer combination strategy: Since SAST, DAST, IAST, and SCA are complementary, filling each other's blind spots, the notion of completing security with any one is dangerous. Design the combination to fit the organization's tech stack, regulatory requirements, and maturity, but recommend a phased expansion roadmap that starts broadly with SCA/SAST and raises precision with IAST/DAST. For critical systems, run expert penetration testing in parallel for business-logic flaws automation cannot catch.

  • The trade-off between false-positive management and developer acceptance: The success of security testing hinges not on detection rate but on whether developers trust the results and fix them. If false positives abound, the tool is ignored and security becomes a formality. Therefore manage the "signal-to-noise ratio" with rule tuning, baseline setting, and risk-based filtering, and minimize friction with IDE/PR integration and fix guidance. Technology must be evaluated not only by accuracy but by adoption.

  • Balancing pipeline integration and speed: Insert security stages into CI/CD, but excessively delaying the build clashes with development speed. Reconcile speed and safety with incremental scans (analyzing only changes), parallelization, and tiered gates by severity (blocking the build only for critical flaws). Once a perception grows that "security blocks deployment," a workaround culture takes root, so governance design is important.

  • Supply chain/SBOM governance and regulatory response: In a reality where most code is open source, SCA and SBOM have become not a choice but a requirement of regulatory compliance (EU CRA, U.S. SBOM mandates). Institutionalize continuous monitoring of dependencies, policies for swift updates of vulnerable components, and license-risk management; this determines an organization's resilience to supply chain attacks (of the Log4Shell type).

  • Architectural integration and outlook: Security testing has limited value alone; the closed loop is completed only when results are integrated via ASPM and connected with runtime protections like RASP/WAF and design-stage activities like threat modeling and secure coding. Since it is expected to evolve from "detection to autonomous response" with AI-based automatic fixing and exploitability analysis, organizations should position security testing as a common security platform layer rather than individual tools and select it on the premise of standards-based (OWASP, SARIF, etc.) integration.

References

In one line: Application security testing is a multi-layered defense that filters vulnerabilities layer by layer by combining SAST for static code analysis, DAST for externally attacking the running app, IAST for observing internals via runtime instrumentation, and SCA for matching open source across the SDLC — evolving toward DevSecOps embedding and ASPM/AI-based integrated management.