This chapter covers Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) tools and their integration, a key topic under CompTIA CySA+ CS0-003 Domain 2.0 (Vulnerability Management), Objective 2.4 (Analyze output from vulnerability assessment tools). Understanding the differences, strengths, weaknesses, and integration strategies of SAST and DAST is critical for the exam, as roughly 10-15% of vulnerability management questions will involve selecting or interpreting the appropriate testing methodology. You need to know when to use each, how they complement each other, and how to interpret their outputs for effective remediation.
Jump to a section
Think of SAST as a meticulous proofreader and DAST as a test driver. When you write a book, a proofreader (SAST) examines every sentence, word, and punctuation mark without ever running the printing press. They check for grammar errors, logical inconsistencies, and style violations. They can point out a sentence that will be confusing before a single copy is printed. However, they cannot tell you if the book will actually sell or if the binding will fall apart. Conversely, DAST is like a test driver who gets behind the wheel of a finished car and drives it on a real road. They test acceleration, braking, and handling. They can find that the car pulls to the left at high speeds or that the radio cuts out over bumps. But they never inspect the engine block's metallurgy or the wiring harness's gauge. A proofreader finds issues in the manuscript; a test driver finds issues in the driving experience. In software, SAST finds vulnerabilities in source code without execution, while DAST finds vulnerabilities in running applications by simulating attacks. Neither is complete alone — you need both to ensure the book is both well-written and well-received.
What is SAST?
Static Application Security Testing (SAST) analyzes source code, byte code, or binary code without executing the application. It is a white-box testing technique because the tester has access to the internal structure and code. SAST tools scan the entire codebase to identify potential security flaws such as SQL injection, cross-site scripting (XSS), buffer overflows, and hardcoded credentials. They work by building a model of the code's control and data flow, then applying pattern matching, taint analysis, or abstract interpretation to find vulnerabilities.
How SAST Works Internally
SAST tools typically follow these steps:
1. Parsing: The tool parses the source code into an abstract syntax tree (AST) or intermediate representation (IR). For example, a Java SAST tool will parse .java files into AST nodes representing classes, methods, variables, etc.
2. Building a Model: The tool creates a call graph and data flow graph. It tracks how data moves from inputs (e.g., user input, file reads) to sensitive sinks (e.g., SQL queries, system commands). This is called taint propagation.
3. Rule Application: The tool applies a set of security rules (e.g., OWASP Top 10) to the model. Rules are often written in a domain-specific language (DSL). For example, a rule for SQL injection might detect where unsanitized user input reaches a executeQuery() call.
4. Reporting: The tool outputs findings with file names, line numbers, and a description of the vulnerability. Most tools also classify severity (Critical, High, Medium, Low) and provide remediation guidance.
Key components of SAST: - Rule sets: Predefined or custom rules for specific languages and frameworks. Default rules cover OWASP Top 10, CWE Top 25, and PCI DSS requirements. - Baseline: SAST can be run on a full codebase (full scan) or only on changed code (incremental scan). Incremental scans are faster and used in CI/CD pipelines. - False positives: SAST tends to produce false positives because it cannot determine runtime context. For example, it may flag a SQL query that is actually safe due to a prepared statement, but the tool cannot always verify the parameter binding.
What is DAST?
Dynamic Application Security Testing (DAST) analyzes an application in its running state. It is a black-box testing technique because the tester has no knowledge of the internal code or architecture. DAST tools simulate attacks against the application, typically by sending HTTP requests and analyzing responses. They are used to find vulnerabilities that manifest at runtime, such as SQL injection, XSS, authentication bypass, and insecure direct object references (IDOR).
How DAST Works Internally
DAST tools operate as follows:
1. Crawling: The tool first crawls the application to discover all endpoints, forms, cookies, and parameters. It follows links, submits forms, and handles JavaScript (some tools use a headless browser for single-page applications).
2. Attack Injection: The tool then sends malicious payloads to each input point. For example, it might send ' OR '1'='1 to a login form to test SQL injection, or <script>alert(1)</script> to a comment field to test XSS.
3. Response Analysis: The tool analyzes HTTP responses for signs of vulnerabilities. For SQL injection, it looks for database error messages, timing differences, or content changes. For XSS, it checks if the payload is reflected in the response without sanitization.
4. Reporting: DAST tools output findings with the affected URL, parameter, HTTP method, and evidence (e.g., the payload that triggered the vulnerability). Severity is based on impact and exploitability.
Key components of DAST: - Spider/Scanner: The crawling engine that discovers the application's attack surface. Some tools allow manual specification of URLs or API endpoints. - Authentication: DAST tools can be configured to log in to the application to test authenticated areas. This is done by recording a login macro or providing credentials. - Session management: The tool maintains session cookies to stay authenticated during the scan. - Rate limiting: Many DAST tools have settings to throttle requests to avoid overwhelming the server or triggering WAFs.
SAST vs DAST: Key Differences
| Feature | SAST | DAST | |---------|------|------| | Access | White-box (source code) | Black-box (running app) | | Phase | Early in SDLC (coding) | Late in SDLC (testing/staging) | | Vulnerabilities Found | Injection, buffer overflow, hardcoded secrets | Runtime issues, misconfigurations, auth flaws | | False Positives | High | Medium (can be high if not tuned) | | Language Dependency | Yes (language-specific) | No (language-agnostic) | | Requires Running App | No | Yes | | Scan Speed | Fast (minutes to hours) | Slow (hours to days) | | Coverage | All code paths (theoretically) | Only reachable paths at runtime |
Integration into SDLC and CI/CD
For effective vulnerability management, SAST and DAST are integrated into different stages of the Software Development Lifecycle (SDLC):
SAST Integration: - Developer IDE: SAST plugins (e.g., SonarLint, Checkmarx CxSAST IDE plugin) run scans as the developer writes code, providing immediate feedback. - Pre-commit hooks: SAST can be run on staged files before commit using tools like Git hooks. - CI/CD Pipeline: SAST is typically run after a build (e.g., in Jenkins, GitLab CI, GitHub Actions). It scans the compiled code or source. The pipeline can fail if critical vulnerabilities are found. For example, a Jenkins pipeline step:
stage('SAST') {
steps {
sh 'sonar-scanner -Dsonar.projectKey=myapp -Dsonar.sources=.'
}
}Reporting: Results are sent to a dashboard (e.g., SonarQube, DefectDojo) for tracking and remediation.
DAST Integration: - Staging Environment: DAST is run against a deployed staging instance, often nightly or after major commits. - CI/CD Pipeline: DAST can be triggered after deployment to a test environment. For example, using OWASP ZAP in a Docker container:
stage('DAST') {
steps {
sh 'docker run -v $(pwd):/zap/wrk owasp/zap2docker-stable zap-baseline.py -t https://staging.myapp.com -r report.html'
}
}Pre-Production: DAST is often run against a pre-production environment that mirrors production as closely as possible.
Combined Integration (DevSecOps): - Pipeline Gates: Both SAST and DAST results are used as quality gates. For example, a pipeline might: 1. Build code 2. Run SAST (fail if any Critical or High vulnerabilities) 3. Deploy to staging 4. Run DAST (fail if any Critical vulnerabilities) 5. Deploy to production if all gates pass - Vulnerability Correlation: Results from SAST and DAST can be correlated in a central platform (e.g., DefectDojo) to prioritize vulnerabilities that appear in both.
Tool Examples
SAST Tools: Checkmarx, Fortify, Veracode, SonarQube (with security plugins), Synopsys Coverity, HCL AppScan Source.
DAST Tools: OWASP ZAP (Zed Attack Proxy), Burp Suite Professional, Acunetix, Netsparker, HCL AppScan Dynamic, Qualys Web Application Scanner.
Common Pitfalls and Exam Tips
SAST cannot find runtime configuration issues (e.g., misconfigured CORS, insecure TLS settings). DAST can.
DAST cannot find vulnerabilities in code that is not executed (e.g., dead code paths). SAST can.
False positives are higher in SAST because it lacks runtime context. For example, SAST may flag a SQL query as vulnerable even if it uses parameterized queries, depending on the tool's ability to trace parameter binding.
DAST requires authentication to test authenticated areas; otherwise, it only tests unauthenticated pages.
SAST is language-specific; a tool for Java may not work for Python. DAST is language-agnostic.
The exam may ask: "Which testing method would find a SQL injection vulnerability in source code?" Answer: SAST. "Which method would find a SQL injection vulnerability in a deployed web application?" Answer: DAST.
Security Concerns and Limitations
SAST Limitations:
High false positive rate requires manual triage.
Cannot detect vulnerabilities introduced by third-party libraries unless the tool supports dependency scanning (some SAST tools do include SCA).
Slower for large codebases if not using incremental scanning.
DAST Limitations:
Slower scan times (hours to days).
May miss vulnerabilities in complex multi-step workflows if not properly configured.
Can cause performance issues or data corruption in production if not carefully scoped.
Both: Neither can find all vulnerabilities. They complement each other and should be used together with other techniques like IAST (Interactive Application Security Testing) and RASP (Runtime Application Self-Protection).
Choose the Right Tool for the Phase
In the SDLC, SAST is best applied early (coding phase) to catch vulnerabilities before compilation. DAST is best applied later (testing/staging) when the application is running. For CI/CD, integrate SAST after build and DAST after deployment to a test environment. The exam expects you to know that SAST is a white-box test (code analysis) and DAST is a black-box test (runtime analysis). Choosing the wrong tool for a given scenario is a common mistake.
Configure SAST with Appropriate Rules
SAST tools use rule sets. Select rules that match the programming language and framework. For example, for a Java Spring application, enable rules for SQL injection, XSS, and Spring-specific vulnerabilities. Set severity thresholds: typically, fail the build on Critical or High findings. Use incremental scanning to reduce scan time in CI/CD. The tool will parse the source code into an AST and apply taint analysis to track data from sources (e.g., HTTP request) to sinks (e.g., database query).
Interpret SAST Output and Triage False Positives
SAST reports include file, line number, vulnerability type, and severity. Developers must review findings and mark false positives. For example, a SAST tool may flag a parameterized query as SQL injection if it cannot trace the parameter binding. The developer must verify the code and if safe, mark as false positive. This step is critical because high false positive rates can lead to alert fatigue. The exam may ask about false positive handling.
Configure DAST with Crawling and Authentication
DAST tools need to crawl the application. Provide the starting URL(s) and configure authentication. Use a login macro or provide valid credentials. The tool will maintain session cookies. Set the scope to include all relevant pages (e.g., exclude logout pages). Define attack patterns: the tool will inject payloads into parameters, headers, and forms. For API testing, provide the API endpoints and authentication tokens.
Run DAST and Analyze Results
DAST scans can take hours. After completion, review findings by severity. Each finding includes the URL, parameter, HTTP method, and evidence (e.g., payload and response snippet). Validate findings manually because DAST can also produce false positives (e.g., a reflected XSS that only appears in a debug page). Correlate with SAST findings: if both tools find the same vulnerability, it is likely real and high priority. Remediate and re-test.
Scenario 1: E-commerce Application with PCI DSS Compliance A large e-commerce company processes credit card payments and must comply with PCI DSS. They use SAST (Checkmarx) integrated into their GitLab CI pipeline. Every commit triggers a SAST scan. Critical vulnerabilities block the merge request. They also run DAST (Burp Suite Professional) weekly against their staging environment. The DAST scan includes authenticated sessions to test the checkout flow. In production, they discovered a SQL injection vulnerability in a search endpoint that SAST had missed because the vulnerable code was in a legacy third-party component. DAST caught it because it tested the live endpoint. The issue was that SAST only scanned first-party code; they later added Software Composition Analysis (SCA) to cover third-party libraries. Performance: SAST scans take 30 minutes for a 500K-line codebase; DAST scans take 6 hours for 2000 pages. Misconfiguration: Initially, they didn't configure DAST authentication, so it only tested unauthenticated pages, missing critical vulnerabilities in the admin panel. They fixed this by recording a login macro.
Scenario 2: SaaS Provider with Continuous Deployment A SaaS provider deploys multiple times per day. They use SAST (SonarQube) in their CI pipeline with quality gates: no Critical or High vulnerabilities allowed. They also use DAST (OWASP ZAP) in a dedicated staging environment that is a full clone of production. The DAST scan runs automatically after each deployment. They encountered a problem where DAST scans were too slow (2 hours) for their rapid deployment cadence. They solved this by running DAST only on changed pages using a diff-based approach and by using a baseline scan that only tests for the most critical vulnerabilities (e.g., SQL injection, XSS) on every deployment, reserving full scans for nightly runs. They also integrated IAST (Contrast Security) to reduce false positives from both SAST and DAST. A key lesson: they initially relied solely on SAST and missed a misconfigured CORS policy that allowed data exfiltration. DAST caught it because it tested the actual HTTP headers.
Scenario 3: Financial Institution with Legacy Applications A bank has a mix of modern and legacy applications. For legacy COBOL applications, SAST tools are limited. They use DAST (HCL AppScan Dynamic) to test the web interfaces. They also use SAST for their modern Java and .NET applications. They found that DAST produced many false positives for legacy apps because the tools did not understand the custom session management. They had to manually tune the DAST tool by excluding certain parameters and writing custom attack patterns. For modern apps, SAST was effective but generated thousands of findings; they prioritized based on CVSS scores and exploitability. They also integrated both tools into a centralized vulnerability management platform (DefectDojo) to correlate findings and track remediation. A common issue: developers ignored SAST findings because of high false positive rates. The bank implemented a policy that all Critical and High findings must be triaged within 24 hours, and false positives must be documented and approved by a security lead.
What CS0-003 Tests on SAST vs DAST The exam objective 2.4 (Analyze output from vulnerability assessment tools) expects you to:
Differentiate between SAST and DAST based on their characteristics (white-box vs black-box, when in SDLC they are used, what types of vulnerabilities they find).
Interpret sample outputs from SAST and DAST tools to identify the vulnerability and recommend remediation.
Understand integration points in CI/CD pipelines.
Recognize the limitations and appropriate use cases for each.
Common Wrong Answers and Why 1. "DAST can find vulnerabilities in source code." This is false. DAST tests running applications, not source code. Candidates confuse this because they think "dynamic" means it analyzes code dynamically, but it actually analyzes the application dynamically. 2. "SAST is language-agnostic." False. SAST tools are language-specific because they need to parse the syntax. DAST is language-agnostic because it only sees HTTP requests/responses. 3. "SAST finds runtime configuration issues." False. SAST cannot detect issues like misconfigured CORS, TLS settings, or authentication logic that only manifest at runtime. DAST can. 4. "DAST is faster than SAST." Generally false. DAST scans take longer because they need to crawl and attack the application. SAST scans are typically faster, especially incremental scans.
Specific Numbers and Terms That Appear on the Exam - OWASP Top 10: Expect questions referencing it as the basis for both SAST and DAST rules. - CWE: Common Weakness Enumeration identifiers (e.g., CWE-89 for SQL injection) may appear in tool outputs. - False Positive Rate: SAST has a higher false positive rate than DAST. - Pipeline Stage: SAST is typically run after build; DAST after deployment. - Tools: Be familiar with examples: SonarQube (SAST), Checkmarx (SAST), OWASP ZAP (DAST), Burp Suite (DAST).
Edge Cases and Exceptions - IAST (Interactive Application Security Testing): Combines SAST and DAST by instrumenting the application. The exam may ask how it differs from SAST/DAST. - SCA (Software Composition Analysis): Often confused with SAST. SCA specifically analyzes open-source libraries for known vulnerabilities (e.g., Log4j). SAST analyzes custom code. - Mobile Applications: For mobile, SAST can analyze code (e.g., APK decompilation), while DAST can test the backend APIs. The exam may ask which is appropriate for mobile apps.
How to Eliminate Wrong Answers - If the question mentions "source code," it's SAST. - If it mentions "running application" or "deployed," it's DAST. - If it mentions "type of vulnerability that only appears at runtime" (e.g., race condition, misconfiguration), it's DAST. - If it mentions "language-specific," it's SAST. - If it mentions "false positives are a major issue," it's likely SAST.
SAST is a white-box test that analyzes source code without execution; DAST is a black-box test that analyzes running applications.
SAST is best integrated early in the SDLC (IDE, pre-commit, CI after build); DAST is best integrated later (staging, CI after deployment).
SAST finds vulnerabilities like SQL injection, XSS, and buffer overflows in code; DAST finds runtime issues like misconfigured CORS, authentication flaws, and reflected XSS.
SAST has a higher false positive rate than DAST because it lacks runtime context.
DAST requires authentication to test authenticated areas; otherwise, it only tests unauthenticated pages.
Both SAST and DAST are necessary for comprehensive security; they complement each other.
Common SAST tools: SonarQube, Checkmarx, Veracode. Common DAST tools: OWASP ZAP, Burp Suite, Acunetix.
The exam expects you to interpret tool outputs and recommend the appropriate testing method based on the scenario.
These come up on the exam all the time. Here's how to tell them apart.
SAST (Static Application Security Testing)
White-box testing with source code access
Performed early in SDLC (coding/unit testing)
Finds vulnerabilities like injection, buffer overflow, hardcoded secrets
Language-specific; requires parser for each language
High false positive rate due to lack of runtime context
DAST (Dynamic Application Security Testing)
Black-box testing with no source code access
Performed late in SDLC (staging/production)
Finds runtime vulnerabilities like misconfigurations, auth bypass, XSS
Language-agnostic; only sees HTTP requests/responses
Lower false positive rate but can miss vulnerabilities in dead code
Mistake
DAST can find vulnerabilities in source code by analyzing compiled binaries.
Correct
DAST is black-box; it only interacts with the running application via inputs and outputs. It cannot inspect source code or binaries. That is the domain of SAST or binary analysis tools.
Mistake
SAST is always faster than DAST and therefore should be used exclusively.
Correct
SAST is faster per scan, but it misses runtime vulnerabilities. A comprehensive security program requires both. The exam emphasizes that they are complementary.
Mistake
DAST does not require authentication to test the entire application.
Correct
DAST without authentication only tests unauthenticated pages. To test authenticated functionality (e.g., user dashboard, admin panel), you must configure the tool with valid credentials or a login macro.
Mistake
SAST can detect all types of SQL injection vulnerabilities.
Correct
SAST can detect SQL injection in source code, but it may miss it if the vulnerability is introduced via dynamic SQL built from user input that the tool cannot trace. Also, it may produce false positives for parameterized queries. DAST can confirm if the vulnerability is actually exploitable.
Mistake
SAST and DAST are interchangeable; you only need one.
Correct
They find different types of vulnerabilities. SAST finds issues early in code; DAST finds runtime issues. Relying on one leaves gaps. The exam expects you to know when to use each.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
SAST (Static Application Security Testing) analyzes source code without executing it, finding vulnerabilities early in the SDLC. DAST (Dynamic Application Security Testing) analyzes a running application by simulating attacks, finding runtime vulnerabilities. SAST is white-box, language-specific, and has higher false positives. DAST is black-box, language-agnostic, and tests the application as it behaves in production. Both are needed for comprehensive security.
Use SAST early in the SDLC, during coding and build phases, to catch vulnerabilities before deployment. Integrate it into IDEs, pre-commit hooks, and CI/CD pipelines after build. Use DAST later, after the application is deployed to a staging or test environment, to find runtime issues like misconfigurations and authentication flaws. DAST is typically run after deployment in CI/CD pipelines.
No. SAST cannot find runtime configuration issues, logic flaws that only appear during execution, or vulnerabilities in third-party libraries (unless combined with SCA). DAST can find some of these, but neither is complete. They should be used together with other techniques like IAST and manual penetration testing.
SAST lacks runtime context. For example, it may flag a SQL query as vulnerable even if the application uses parameterized queries because the tool cannot always verify that the parameters are properly bound. It may also flag code paths that are never executed at runtime. Developers must manually triage findings to separate true positives from false positives.
Yes, but you must configure the DAST tool with valid credentials or a login macro. The tool will then maintain session cookies and crawl authenticated pages. Without authentication, the scan only covers unauthenticated areas, missing vulnerabilities in user-specific or admin functionality.
In DevSecOps, both SAST and DAST are automated and integrated into CI/CD pipelines. SAST runs after code commit/build, providing fast feedback. DAST runs after deployment to a test environment. Results are used as quality gates to block vulnerable code from reaching production. They are part of a 'shift left' and 'shift right' strategy to find vulnerabilities early and often.
Common SAST tools include SonarQube, Checkmarx, Fortify, Veracode, and Synopsys Coverity. Common DAST tools include OWASP ZAP, Burp Suite, Acunetix, Netsparker, and HCL AppScan Dynamic. The exam expects you to be familiar with these names and their categories.
You've just covered SAST vs DAST Tools and Integration — now see how well it sticks with free CS0-003 practice questions. Full explanations included, no account needed.
Done with this chapter?