712-50 Question 314
Select 2A global financial services company is modernizing its customer-facing applications using agile delivery and DevSecOps. Recent internal audits found that security activities are inconsistent across teams: some developers rely only on end-of-cycle penetration tests, threat modeling is rarely performed, and third-party components are introduced without formal review. The CISO has asked the CCISO to establish a software assurance program that aligns with secure coding principles and embeds control points across the full SDLC without causing major delivery delays. Which TWO actions should the CCISO prioritize to best achieve this objective?
- A
Define secure coding standards and architecture requirements, then integrate automated checks such as SAST, software composition analysis, and secrets scanning into CI/CD pipelines, with risk-based security gates and remediation workflows.
- B
Retain the current development approach and strengthen only the final pre-production penetration test, since independent validation at the end of the lifecycle is the most reliable way to detect exploitable flaws.
- C
Introduce mandatory security activities in each SDLC phase, including security requirements during planning, threat modeling and design review during architecture, code review and automated testing during build, and vulnerability management after release.
- D
Shift responsibility for application security to the QA team so developers can focus on delivery speed, while security specialists review releases only for internet-facing applications.
- E
Defer third-party component reviews until after deployment so product teams can maintain release velocity, and address any identified library issues through routine patching cycles.
Show answer and explanation
Correct answers: A, C
Explanation
The best answer is to institutionalize software assurance as an end-to-end SDLC program rather than rely on isolated, late-stage testing. The two strongest actions are: (1) establish secure coding standards and automate controls in the pipeline, and (3) mandate phase-appropriate security practices across planning, design, development, testing, release, and maintenance. Together, these measures create repeatable governance, earlier risk discovery, and scalable assurance for agile and DevSecOps environments. This aligns with recognized best practices such as the NIST Secure Software Development Framework (SP 800-218), which emphasizes integrating security throughout development, and OWASP guidance on secure coding, threat modeling, code review, and dependency management. Penetration testing remains important, but as one assurance activity among many, not the centerpiece. Similarly, third-party software risk should be addressed before introduction into production and monitored continuously due to the growing importance of software supply chain security.
- A. Correct.
Correct. A mature software assurance program should operationalize secure coding principles through defined standards and automated enforcement. Integrating static application security testing (SAST), software composition analysis (SCA), and secrets scanning into CI/CD supports earlier defect detection, reduces rework, and scales security across agile teams. Risk-based gates are important because they allow the organization to distinguish between critical findings that must block promotion and lower-risk issues that can be tracked for remediation. This approach aligns with secure-by-design and shift-left practices promoted by NIST SSDF and OWASP guidance.
- B. Incorrect.
Incorrect. Final-stage penetration testing is valuable, but using it as the primary or only assurance mechanism is inefficient and incomplete. Penetration testing occurs late, after design and coding decisions are already embedded, making remediation more expensive and disruptive. It also will not reliably identify all classes of weaknesses, such as insecure design choices, weak dependency governance, or coding standard violations. This option reflects the common misconception that late-stage validation can substitute for integrated SDLC controls.
- C. Correct.
Correct. Embedding security activities throughout the SDLC is a foundational principle of software assurance. Security requirements should be defined early, threat modeling and design review should address architectural risks before implementation, secure code review and automated testing should occur during development, and post-release vulnerability management should sustain assurance in operations. This creates traceability from requirements to deployment and aligns strongly with frameworks such as the NIST Secure Software Development Framework (SSDF), which emphasizes preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities.
- D. Incorrect.
Incorrect. Application security is a shared responsibility, not something that should be transferred solely to QA or a small specialist group. Developers must be accountable for secure coding, supported by architecture, testing, and security teams. Restricting reviews to only internet-facing applications is also too narrow because internal systems, APIs, and integrations can carry significant business and regulatory risk. This option reflects the misconception that security can be isolated as a downstream inspection function rather than embedded into engineering practices.
- E. Incorrect.
Incorrect. Deferring third-party component review until after deployment weakens software assurance and increases exposure to known vulnerabilities, license risks, and supply chain compromise. Third-party libraries and open-source dependencies should be evaluated before use and continuously monitored afterward. Routine patching alone is insufficient because some component risks require replacement, compensating controls, or policy exceptions before release. This option is plausible for teams focused on speed, but it conflicts with secure SDLC and modern supply chain risk management practices.