cisspSoftware Development Security· 10 min read· 21 May 2026
Application Security Testing: SAST, DAST, IAST, and Software Composition Analysis
Application security testing is the set of methods used to evaluate software for security vulnerabilities at different stages of the development lifecycle. Domain 8 of the CISSP exam covers four primary testing approaches — SAST, DAST, IAST, and Software Composition Analysis — and tests candidates on their distinct characteristics, where they fit in the development pipeline, and how they complement each other. This builds on Domain 6's coverage of testing from an assessment perspective; here the focus is on integration into the development process.
The Application Security Testing Landscape
No single testing method can find all vulnerabilities. Effective application security programmes combine multiple testing approaches because each method has blind spots that others cover.
SAST finds code-level vulnerabilities early but cannot see runtime behaviour. DAST tests runtime behaviour but cannot see the code that causes it. IAST provides runtime instrumentation that combines both perspectives. SCA addresses the risk from third-party components that none of the other methods fully cover.
The exam tests whether candidates understand which method to recommend given a specific scenario, and why. The answer depends on: the stage of development, whether source code is available, whether the application is running, and whether the concern is first-party code or third-party dependencies.
Static Application Security Testing (SAST)
SAST analyses source code, bytecode, or binary artefacts without executing the application. It searches for patterns associated with security vulnerabilities by examining the code's structure, data flows, and control flows.
SAST works by building a model of the application's code (Abstract Syntax Tree, control flow graph, data flow graph) and applying security rules to that model. For example, a data flow analysis might track untrusted user input from an HTTP parameter through the application's processing logic to a database query, flagging it if the input is not properly sanitised before use in the query (potential SQL injection).
SAST advantages: catches vulnerabilities at development time (shift-left), integrates naturally into IDEs and CI/CD pipelines, can analyse code paths that are never executed in testing, and provides developers with actionable feedback while the code is fresh in their minds.
SAST limitations: false positives are the primary challenge. Because SAST analyses code statically without understanding the full runtime context, it may flag code as vulnerable when it is not. Triage of false positives consumes developer time and, if managed poorly, causes developers to ignore SAST findings entirely. SAST also requires source code access — it cannot analyse third-party compiled libraries (use SCA for that).
For the exam: SAST = static, source code analysis, white box, early in development, higher false positives.
Dynamic Application Security Testing (DAST)
DAST tests a running application from the outside, sending crafted HTTP requests to the application and analysing responses to identify vulnerabilities. DAST simulates what an external attacker does: probe the application's inputs, look for error messages that reveal information, attempt injection attacks, and check for authentication and authorisation weaknesses.
DASTworks by crawling the application (discovering all accessible pages and endpoints), then fuzzing each discovered input (sending unexpected values including SQL injection payloads, XSS payloads, and boundary conditions) and analysing responses for vulnerability indicators (database errors, reflected script content, authentication bypass).
DASTadvantages: tests the actual running application in its deployment environment, including infrastructure configuration. Can detect vulnerabilities that only manifest at runtime — server misconfigurations, HTTP security header absence, insecure cookies — that SAST would not find. Lower false positive rate than SAST because it actually confirms the vulnerability is exploitable.
DAST limitations: requires a running application, so it can only run after the application is built and deployed (to a test environment at minimum). DAST may miss vulnerabilities in code paths that the crawler cannot reach — it has limited coverage of complex application flows that require specific state or authentication. DAST is slower than SAST because it must interact with the running application.
For the exam: DAST = dynamic, running application, black box, test/staging environment, lower false positives.
Interactive Application Security Testing (IAST)
IAST is a hybrid approach that instruments the running application with security sensors to monitor its behaviour from the inside during testing. Unlike SAST (which analyses code without running it) and DAST (which tests the running application from outside), IAST observes the application's internal behaviour while it executes.
IAST instrumentation is typically implemented as an agent embedded in the application runtime (Java agent, .NET profiler, Python middleware). The agent monitors function calls, data flows, and interactions with security-sensitive operations (database queries, file system access, network calls) in real time. When the application executes a potentially vulnerable operation (for example, constructing a SQL query using unsanitised input), the IAST agent reports the vulnerability with full context: the exact line of code, the data flow from input to sink, and a severity rating.
IAST advantages: very low false positive rate because it observes the actual execution of vulnerable code rather than analysing static patterns or inferring behaviour from external responses. Provides full context (stack trace, data flow) that makes findings immediately actionable. Can detect complex vulnerabilities that require multiple conditions to trigger.
IAST limitations: requires an agent to be embedded in the runtime, which may affect performance and may not be available for all languages and frameworks. Coverage depends on what code is actually executed during testing — code paths not exercised during the testing session are not analysed.
For the exam: IAST = instrumented runtime agent, tests during execution, lowest false positive rate, hybrid of SAST and DAST perspectives. The exam specifically tests the distinguishing characteristic: IAST instruments the application and analyses it dynamically simultaneously.
Software Composition Analysis (SCA)
Modern applications are composed largely of third-party open-source components. A typical enterprise application may include hundreds or thousands of open-source libraries, each of which may have its own known vulnerabilities. SCA is the tooling category that manages this risk.
SCA tools scan an application's dependencies (including transitive dependencies — the dependencies of dependencies) and compare them against databases of known vulnerabilities (NVD, GitHub Advisory Database, Snyk Vulnerability DB). When a component with a known CVE is identified, the SCA tool reports the vulnerability, the severity, and the available remediation (typically an upgrade to a version that fixes the vulnerability).
SCA also provides: licence compliance checking (ensuring that open-source licences are compatible with the organisation's commercial use), dependency graph visualisation (understanding the full dependency tree), and policy enforcement (blocking builds that include components with known critical vulnerabilities).
The Log4Shell vulnerability (CVE-2021-44228) demonstrated why SCA is critical: a vulnerability in the widely used Log4j library affected thousands of applications that had incorporated it as a dependency, often without the development teams knowing it was present. SCA would have flagged the vulnerable version immediately after the CVE was published, allowing organisations to identify affected applications and prioritise remediation.
For the exam: SCA addresses the risk from third-party open-source components. It identifies known vulnerabilities in dependencies, not in first-party code. SCA is the control for managing software supply chain risk at the dependency level.
Integrating Security Testing into CI/CD Pipelines
All four testing approaches can be integrated into CI/CD pipelines to automate security testing throughout the development lifecycle.
SAST runs on every code commit. The CI system checks out the new code, runs the SAST tool, and reports findings. Critical and high findings can be configured as pipeline blockers — preventing a commit from merging until the finding is addressed or explicitly waived.
SCA runs on every dependency change. When a developer adds or updates a dependency, SCA automatically checks whether the new version has known vulnerabilities. Like SAST, SCA findings can be pipeline blockers.
DASTruns against deployed test environments. In a CI/CD pipeline, the application is deployed to a test environment and DAST is run automatically. DAST cannot run as early as SAST or SCA because it requires a running application.
IAST runs continuously during testing phases. Because IAST is embedded in the application runtime, it monitors during all testing activities — functional testing, integration testing, and dedicated security testing.
For the exam: the combination of SAST + SCA in the build phase and DAST + IAST in the test phase provides comprehensive coverage across the CI/CD pipeline.
Exam Tip
IAST is the hybrid — it instruments the application and tests it dynamically simultaneously. SAST is static analysis without execution. DAST tests the running application from outside. SCA scans third-party dependencies. The exam tests the key differentiator for each: SAST = no execution needed; DAST = running application required; IAST = runtime agent; SCA = open-source dependency scanning. All four are complementary, not alternatives.
// PRACTICE_THIS_DOMAIN
Test your knowledge on Software Development Security
AI-generated practice questions mapped to this domain. Get instant explanations and track your progress.