712-50 Question 315
Single answerA newly appointed CISO is reviewing a software assurance program after a customer-facing application suffered repeated security defects shortly before release. The organization currently performs a penetration test at the end of development and requires developers to fix only critical findings before go-live. There are no defined security requirements during planning, no formal threat modeling, and third-party components are added by development teams without centralized oversight. The CISO must improve the program so that secure coding principles are applied across the entire SDLC while balancing delivery speed and risk reduction. Which action should the CISO prioritize FIRST to establish a sustainable software assurance program?
- A
Mandate more extensive penetration testing immediately before release and block deployment until all medium-risk findings are remediated
- B
Implement an SDLC-integrated secure development framework that defines security requirements, threat modeling, secure coding standards, automated testing, and third-party component governance at phase-appropriate checkpoints
- C
Require all developers to attend annual secure coding training and rely on team leads to decide where security controls should be added in projects
- D
Outsource code review for all high-risk applications to an external specialist firm and retain the existing development lifecycle to avoid disrupting delivery timelines
Show answer and explanation
Correct answer: B
Explanation
The best answer is to establish an SDLC-integrated secure development framework because the scenario describes systemic weaknesses, not a single control failure. Effective software assurance requires security to be embedded throughout the lifecycle: security requirements during planning; threat modeling and secure architecture review during design; secure coding standards and peer review during implementation; automated SAST, SCA, secrets detection, and appropriate DAST/IAST during testing; release criteria and risk-based exception handling before deployment; and vulnerability management, patching, and logging/monitoring during operations and maintenance. Third-party component governance is also essential because unmanaged dependencies are a common source of software risk. This approach is consistent with NIST Secure Software Development Framework (SP 800-218), which emphasizes preparing the organization, protecting software, and producing well-secured software through repeatable practices. It also aligns with OWASP SAMM and OWASP ASVS concepts for defining measurable security requirements and verification activities. From a CCISO perspective, the key is selecting a governance-led, scalable programmatic action that reduces risk earlier in the SDLC, improves accountability, and lowers long-term remediation cost rather than overinvesting in late-stage testing alone.
- A. Incorrect.
This is not the best first priority because it reinforces a late-stage, defect-detection approach rather than building security into the SDLC. Penetration testing is valuable, but relying on end-of-cycle testing leads to costly rework, misses design flaws, and does not address upstream gaps such as absent security requirements, lack of threat modeling, or unmanaged software components. A common misconception is that stricter release gates alone create a software assurance program; in reality, they only strengthen one downstream control.
- B. Correct.
This is correct because it addresses the root cause: security activities are missing across multiple SDLC phases. A sustainable software assurance program should embed security from planning through design, development, testing, release, and maintenance. That includes defining security and abuse-case requirements early, performing threat modeling during design, enforcing secure coding standards during implementation, integrating static/dynamic testing and code review into CI/CD, and governing open-source and third-party components through approved inventories, vulnerability monitoring, and patching processes. This approach aligns with recognized practices from NIST SSDF, OWASP SAMM, and the principle of shifting security left while maintaining phase-appropriate controls.
- C. Incorrect.
Training is important, but by itself it is insufficient as the first priority. Without a formal framework, training often results in inconsistent execution, unclear accountability, and uneven control coverage across projects. Team leads making ad hoc decisions may perpetuate the same fragmented process that allowed defects to reach late-stage testing. Candidates may choose this option because developer education is visible and relatively easy to launch, but it does not create the governance, standards, and checkpoints needed for program maturity.
- D. Incorrect.
External code review can help for selected applications, but outsourcing one control while keeping an ineffective lifecycle intact does not establish an enterprise software assurance program. This option fails to address missing requirements engineering, threat modeling, secure design, secure coding governance, and software supply chain oversight. It may also create dependency on a point-in-time assessment instead of building internal capability and repeatable controls. The misconception here is treating code review as a substitute for SDLC-wide assurance.