712-50 Question 320
Single answerUnderstand software vulnerability analysis techniques including static code, dynamic code, and software composition analysisA global financial services company is accelerating releases of a customer-facing web application built with internally developed code and numerous open-source libraries. After a recent incident, the CISO asks you to recommend a vulnerability analysis approach that will reduce production risk without significantly slowing delivery. The development teams want early detection of coding flaws, validation of how the running application behaves under attack-like conditions, and visibility into known vulnerabilities and license risks in third-party components. Which approach should you recommend?
- A
Implement static application security testing (SAST) in the CI pipeline, dynamic application security testing (DAST) against running test environments before release, and software composition analysis (SCA) to continuously inventory and assess third-party dependencies
- B
Rely primarily on DAST because testing the running application will identify coding flaws, insecure libraries, and license issues in a single activity without requiring source code access
- C
Use SAST only, because source code analysis provides complete coverage of runtime behavior and can accurately identify vulnerabilities in bundled open-source components without dependency metadata
- D
Adopt software composition analysis (SCA) only, because most modern application risk comes from open-source packages, and secure coding flaws in proprietary code are best addressed through annual penetration testing
Show answer and explanation
Correct answer: A
Explanation
The best answer is to combine SAST, DAST, and SCA because the scenario explicitly calls for three different outcomes: early detection of coding flaws, validation of behavior in a running application, and visibility into third-party component risk. These are complementary rather than interchangeable capabilities. SAST is most useful earlier in development because it analyzes source or compiled code for patterns associated with weaknesses before deployment. DAST assesses the live application from the outside and helps identify issues manifested in runtime behavior. SCA inventories dependencies and maps them to known vulnerabilities and license concerns, supporting software supply chain governance.
From a CCISO perspective, this is also the strongest governance recommendation because it balances risk reduction with delivery speed by embedding controls across the lifecycle rather than relying on a single late-stage activity. This approach is consistent with widely accepted secure development guidance, including NIST SSDF (Secure Software Development Framework), OWASP guidance on SAST/DAST usage, and common DevSecOps practices that advocate layered testing and continuous monitoring of third-party components.
- A. Correct.
Correct. This is the most effective and realistic recommendation because it aligns each technique to its strength. SAST helps detect insecure coding patterns and certain classes of flaws early in the software development lifecycle, which supports faster remediation and lower cost. DAST evaluates the application while it is running, helping identify issues observable in execution and deployment contexts, such as authentication, session handling, or input validation weaknesses exposed through HTTP interactions. SCA is specifically designed to identify third-party and open-source components, detect known vulnerabilities through dependency matching against vulnerability databases, and often highlight license or policy risks. Together, these controls provide layered coverage without depending on a single method to do everything.
- B. Incorrect.
Incorrect. DAST is valuable, but it does not replace SAST or SCA. It tests the application from the outside while running, so it can miss code-level weaknesses that are not reachable in the test scenario and generally does not provide comprehensive visibility into which open-source packages are present. It also is not the right primary tool for software license analysis. This option reflects the common misconception that runtime testing alone is sufficient for secure development.
- C. Incorrect.
Incorrect. SAST provides important early feedback, but it does not provide complete coverage of runtime behavior. Static analysis cannot fully validate how the deployed application behaves in its operating environment, especially where issues depend on configuration, authentication flows, server responses, or runtime state. In addition, while some SAST platforms may include package analysis features, SAST by itself is not the best or most reliable method for identifying known vulnerabilities and license obligations in third-party dependencies. That is the role of SCA.
- D. Incorrect.
Incorrect. SCA is essential for managing open-source risk, but using it alone leaves major gaps. Proprietary code can still contain logic flaws, injection weaknesses, insecure error handling, or other defects that SAST and DAST are designed to help uncover. Deferring those concerns to annual penetration testing is insufficient for a fast release environment because it delays discovery and remediation and does not support secure-by-design practices. This option reflects an overly narrow focus on supply chain risk.