712-50 Question 319
Single answerConfigure and run tools that help in developing secure programsA global software company is modernizing its software development lifecycle after several security defects were discovered late in pre-production testing. The CISO wants a tooling strategy that improves developer adoption, detects vulnerabilities earlier, and provides governance metrics to leadership without slowing high-frequency releases. The engineering organization uses Git-based workflows, CI/CD pipelines, containerized deployments, and several open-source libraries. Which approach is the MOST effective for configuring and running tools that help develop secure programs in this environment?
- A
Implement integrated security tooling across the SDLC by using IDE plug-ins for developer feedback, SAST during code commits or pull requests, software composition analysis for open-source dependencies, secrets scanning, container/image scanning in CI, and risk-based policy gates tied to severity and exploitability, while centralizing findings for metrics and triage.
- B
Rely primarily on annual third-party penetration tests and move all security testing to a dedicated hardening phase before production, so developers are not distracted by tool output during active development.
- C
Deploy dynamic application security testing only in production-like staging environments because runtime testing finds the most realistic issues, and disable earlier code-level scanning to reduce false positives.
- D
Mandate manual secure code reviews for every change request and avoid automated tools until the development teams complete advanced security training, ensuring that only human judgment influences release decisions.
Show answer and explanation
Correct answer: A
Explanation
The best answer is the integrated, shift-left-and-throughout-the-pipeline approach because secure program development requires multiple complementary tools configured to provide timely feedback, broad coverage, and measurable governance. In practice, organizations should combine secure coding support in developer workflows with automated scanning in CI/CD and centralized defect management. Common tool categories include static application security testing (SAST), software composition analysis (SCA), secrets scanning, infrastructure-as-code scanning where applicable, container/image scanning, and dynamic testing in later environments. From a CCISO perspective, success is not just selecting tools, but configuring them to support business velocity, triage findings effectively, and produce metrics for leadership.
This approach aligns with widely accepted guidance from sources such as NIST SSDF (Secure Software Development Framework, SP 800-218), which emphasizes integrating security practices throughout development; OWASP SAMM and the OWASP Software Assurance ecosystem, which promote governance, verification, and developer enablement; and industry DevSecOps best practices that recommend early feedback, automation, and risk-based gates rather than relying on a single late-stage control. Penetration testing and manual review still have important roles, but they are most effective as part of a broader secure development toolchain, not as substitutes for it.
- A. Correct.
Correct. This is the most effective and modern approach because it layers complementary tools at multiple points in the SDLC and aligns with DevSecOps principles. IDE plug-ins and pre-commit or pull-request checks provide fast feedback to developers when fixes are cheapest. SAST helps identify insecure coding patterns in proprietary code, software composition analysis (SCA) addresses risks from third-party and open-source components, secrets scanning helps prevent credential exposure, and container/image scanning is appropriate for containerized deployments. Risk-based policy gates are more practical than blunt blocking because they can be tuned to severity, exploitability, business context, and exception workflows. Centralized findings support governance, trend reporting, remediation tracking, and executive metrics, which is especially important at the CCISO level.
- B. Incorrect.
Incorrect. Annual penetration tests and a late hardening phase may identify some issues, but this approach pushes detection too far to the right in the lifecycle, increasing remediation cost and release friction. It also does little to improve secure development practices or developer behavior at the point where code is written. Penetration testing is valuable, but it should complement, not replace, earlier automated controls and continuous security testing.
- C. Incorrect.
Incorrect. DAST can be useful for identifying certain runtime and configuration issues in an integrated environment, but using it as the primary or only control is insufficient. It typically cannot provide the same code-level insight as SAST and does not address dependency risk the way SCA does. Disabling earlier scanning to reduce false positives reflects a governance and tuning problem, not a sound security strategy. Mature programs reduce noise through baselining, rule tuning, and risk prioritization rather than eliminating early controls.
- D. Incorrect.
Incorrect. Manual code reviews remain valuable for high-risk changes, architectural concerns, and business logic flaws, but they do not scale well as the sole control in high-frequency release environments. Avoiding automated tools until all teams complete advanced training delays needed risk reduction and creates process bottlenecks. Secure development programs are strongest when they combine training, automation, and targeted human review rather than depending only on manual inspection.