Application security testing is the practice of evaluating software applications for security vulnerabilities through a combination of manual and automated techniques. For the CISSP exam, Domain 6 tests the conceptual differences between testing approaches, when each is appropriate, and how they fit into the security development lifecycle. The exam is particularly interested in the SAST vs DAST distinction and the concept of misuse case testing.
Static Application Security Testing (SAST)
Static Application Security Testing analyses source code, bytecode, or binary code without executing the application. SAST tools scan the codebase looking for patterns that are associated with security vulnerabilities: SQL query construction using string concatenation (potential SQL injection), hardcoded credentials, use of deprecated cryptographic functions, buffer arithmetic errors, and insecure direct object references.
SAST is a white box testing approach — it requires access to the source code and examines the application's internal structure. Because SAST does not execute the application, it can be run very early in the development lifecycle — even as code is being written, through IDE plugins that provide real-time feedback. This makes SAST a natural fit for the shift-left security philosophy: catching vulnerabilities at the earliest possible stage when they are cheapest to fix.
SAST advantages: it can analyse all code paths, including error conditions and rarely executed paths that would be hard to trigger in dynamic testing. It scales well with codebase size and can be fully automated in CI/CD pipelines.
SAST limitations: the primary weakness of SAST is false positives — the tool may flag code as vulnerable when it is not, because the tool cannot fully understand the application's runtime context. Additionally, SAST cannot detect runtime vulnerabilities that only manifest when the application interacts with specific environments, configurations, or external services.
For the exam: SAST = static analysis of source code without executing it. Can be run early in development. High false positive rate. Finds code-level vulnerabilities.
Dynamic Application Security Testing (DAST)
Dynamic Application Security Testing tests a running application from the outside, without access to source code. DAST tools send crafted inputs to the application's interfaces (web forms, API endpoints, URL parameters) and analyse the responses to identify vulnerabilities. Because DAST tests the actual running application, it detects vulnerabilities that only manifest at runtime.
DASTis a black box testing approach — it simulates an external attacker who has no access to the source code. DAST is typically run against applications deployed in a test or staging environment, though web application scanners can also be used against production applications under controlled conditions.
DASTadvantages: low false positive rate compared to SAST (DAST confirms that a vulnerability is exploitable because it actually exploits it), can detect runtime and configuration vulnerabilities that SAST misses, and does not require source code access (useful for testing third-party components).
DASTlimitations: DAST can only test code paths that are reachable through the application's external interfaces. It cannot test code that is never triggered by external input. DAST is slower than SAST because it must send many requests and wait for responses. It typically runs later in the development lifecycle (in test/staging environments) so vulnerabilities discovered are more expensive to fix.
For the exam: DAST = dynamic testing of running applications from outside. Black box approach. Lower false positive rate than SAST. Tests runtime behaviour including configuration issues.
Code Review Methodologies: Manual vs Automated
Code review is the systematic examination of source code by humans or automated tools to identify security defects, logic errors, and compliance violations.
Manual code review involves security-aware developers or dedicated security reviewers examining code line by line. Manual review is most effective for complex logic errors, business logic flaws, and context-dependent issues that automated tools may miss. It is also effective for reviewing cryptographic implementations where subtle errors can create catastrophic vulnerabilities. The limitation is scale — manual review is time-intensive and cannot keep pace with large, rapidly evolving codebases.
Automated code review (SAST) provides broader coverage and higher throughput but is limited by the rules encoded in the tool. Effective application security programmes use both: automated SAST for broad coverage and continuous integration, complemented by manual review for high-risk code areas.
Peer code review (requiring a second developer to review every code change before merge) is a development practice that also catches security issues as a side benefit. It provides a lightweight, continuous security check without dedicated security resources.
Interface Testing: UI, API, and Network Interfaces
Interface testing evaluates the security of the interfaces through which a system communicates: user interfaces, APIs, and network interfaces.
User interface security testing evaluates whether the UI enforces security controls correctly: are sensitive fields masked appropriately, does the UI expose system internals through error messages, can UI elements be manipulated to bypass client-side controls?
API security testing is increasingly important as modern applications rely heavily on APIs for both internal communication (microservices) and external integration. API security testing evaluates: authentication and authorisation (is every API endpoint protected?), input validation (does the API reject malformed inputs?), rate limiting (can the API be abused through rapid repeated calls?), data exposure (does the API return more data than the consumer needs?), and injection vulnerabilities (are API parameters sanitised before use in database queries or commands?).
Network interface testing evaluates security at the network layer: open ports and services, protocol vulnerabilities, and whether network access controls (firewalls, ACLs) are implemented as designed.
For the exam: interface testing covers all external-facing entry points. The most security-relevant is API testing, which examines authorisation, input validation, and data exposure.
Misuse Case Testing
Misuse case testing is the practice of defining test cases based on how the system should NOT be used, rather than how it should be used (which is the focus of traditional use case testing). By systematically thinking about what an adversary or malicious user would try to do, misuse case testing identifies security vulnerabilities that functional testing might miss.
For example, a use case for a login form is: "User enters valid username and password and is authenticated." A corresponding misuse case is: "Attacker enters 10,000 username/password combinations per second using an automated tool." This misuse case identifies the need for rate limiting, account lockout, and CAPTCHA.
Misuse cases should be derived from threat modeling (STRIDE analysis of the application) and from known attack patterns (OWASP Top 10, MITRE ATT&CK).
For the exam: misuse case testing tests what the system should NOT allow to happen. It is the security complement to functional use case testing.
Coverage Analysis and Test Completeness
Security testing is only as good as its coverage. Coverage analysis measures what percentage of the application's code, functionality, or input space was exercised during testing.
Code coverage measures what percentage of source code lines, branches, and paths were executed during testing. High code coverage is necessary but not sufficient for security assurance — a test suite with 95% coverage may still miss security-relevant code paths if the test cases are not security-focused.
Input space coverage measures whether security testing has exercised the full range of inputs an application may receive, including boundary conditions, invalid inputs, and adversarial inputs.
For the exam: coverage analysis ensures that testing is comprehensive and not just validating the happy path. Security testing must cover error conditions, edge cases, and adversarial inputs, not just normal usage.
Exam Tip
SAST analyzes source code without executing it — finds code-level vulnerabilities early in development, high false positive rate. DAST tests running applications from the outside — confirms exploitability, lower false positives, tests runtime behaviour. Use SAST early (shift-left) and DAST in test/staging environments. Misuse case testing tests what should NOT work. Interface testing must cover all external-facing entry points including APIs.
// PRACTICE_THIS_DOMAIN
Test your knowledge on Security Assessment and Testing
AI-generated practice questions mapped to this domain. Get instant explanations and track your progress.