712-50 Question 318
Single answerConfigure and run tools that help in developing secure programsA global software company has experienced several late-stage security defects in a customer-facing application, including vulnerable open-source components and injection flaws that were not detected until pre-production penetration testing. The CISO wants to improve secure program development by configuring security tools earlier in the SDLC without causing major delivery delays. Which approach would BEST achieve this objective?
- A
Integrate software composition analysis (SCA) and static application security testing (SAST) into the CI/CD pipeline with risk-based gating, and require developers to triage findings before promotion to later stages
- B
Rely primarily on annual third-party penetration tests because they provide the most realistic assessment of exploitable vulnerabilities before release
- C
Deploy only runtime web application firewalls (WAFs) in production to block injection attempts, and defer code-level remediation to future release cycles
- D
Require manual security code reviews for every commit and disable automated scanning until the false-positive rate is reduced to near zero
Show answer and explanation
Correct answer: A
Explanation
The best answer is to integrate SCA and SAST into CI/CD with risk-based gating because the scenario highlights two specific problem areas: vulnerable open-source components and injection flaws discovered too late. SCA is the appropriate tool category for identifying known vulnerabilities in third-party dependencies, while SAST is well suited for early detection of many code-level weaknesses. Running these tools automatically during builds provides timely feedback to developers and reduces the cost of remediation compared with finding issues in pre-production testing. A risk-based gate is critical at the leadership level because it aligns security enforcement with business delivery objectives by blocking materially risky builds while allowing managed exceptions and triage workflows.
This approach is consistent with widely accepted guidance from NIST's Secure Software Development Framework (SSDF), which emphasizes integrating security checks throughout development; OWASP Software Assurance and OWASP SAMM practices for automated security verification; and NIST SP 800-218 principles for securing software development pipelines and dependencies. Penetration testing and WAFs still have value, but they are supplementary controls rather than the primary mechanism for developing secure programs. Effective CCISO-level decision making focuses on selecting and configuring toolchains that improve coverage, timeliness, and governance while remaining operationally sustainable.
- A. Correct.
Correct. This is the strongest practical approach because it shifts security left by embedding automated tooling where developers already work. SCA helps identify known vulnerabilities, risky licenses, and outdated dependencies in third-party components, while SAST detects code-level issues such as injection patterns, insecure deserialization risks, and other implementation weaknesses before deployment. Risk-based gating is important because a mature program should not block delivery for every low-severity or unverified finding; instead, it should enforce policy for high-confidence, high-severity issues and require documented triage or exception handling. This balances security improvement with operational efficiency and is aligned with DevSecOps practices and secure SDLC guidance.
- B. Incorrect.
Incorrect. Penetration testing is valuable, but using it as the primary control is too late in the lifecycle for efficient defect removal. It is also point-in-time, limited by scope, and often cannot provide comprehensive coverage of source code or all dependency risks. The scenario specifically calls for earlier detection without major delays, which is better supported by automated tooling in the build pipeline. Candidates may choose this option because penetration tests are realistic and important, but they are not the best first-line mechanism for continuous secure development.
- C. Incorrect.
Incorrect. A WAF can provide compensating controls and reduce exploitability of some web-based attacks, but it does not fix insecure code or vulnerable libraries. It also will not address all flaw classes, especially those outside HTTP request filtering or deeper business logic issues. Deferring remediation increases technical debt and risk acceptance without addressing the root cause. This option reflects the common misconception that perimeter or runtime controls can substitute for secure coding and secure build practices.
- D. Incorrect.
Incorrect. Manual code review is useful for complex business logic, architectural concerns, and validating critical findings, but requiring it for every commit is typically not scalable and would likely create the delivery delays the CISO wants to avoid. Disabling automated scanning until false positives are nearly eliminated is also poor practice; mature programs tune tools, establish triage workflows, and combine automation with human review rather than waiting for perfection. This option may appeal to those frustrated by noisy tools, but it undermines continuous security feedback.