712-50 Question 312
Select 2Secure Coding Best Practices and Securing Web Applications (5 questions)A global retail company is preparing to launch a new customer-facing web application developed by multiple agile teams and an outsourced vendor. During final security review, the CISO learns that developers rely primarily on perimeter defenses such as a web application firewall (WAF), while secure coding requirements are inconsistent across teams. Recent testing identified SQL injection and broken access control issues in staging. The board wants a remediation approach that reduces business risk across the software development lifecycle rather than relying on compensating controls alone. Which TWO actions should the CISO prioritize to most effectively improve the security of the web application program?
- A
Mandate organization-wide secure coding standards based on recognized guidance, and require developers to use parameterized queries, input validation, output encoding, and centralized authorization checks in the application code
- B
Rely on the WAF as the primary mitigation for injection and access control flaws, since it can block most malicious traffic without requiring code changes
- C
Integrate security testing into the CI/CD pipeline, including SAST, DAST, and remediation gates for high-risk findings before production release
- D
Postpone remediation of identified vulnerabilities until after go-live, because issues found in staging are less likely to be exploitable in production if network segmentation is in place
- E
Shift responsibility for application security to the outsourced vendor exclusively, because contractual ownership reduces the enterprise's direct risk exposure
Show answer and explanation
Correct answers: A, C
Explanation
The best answer is to prioritize secure coding standards and SDLC-integrated security testing. For a CISO-level decision, the key objective is to reduce recurring enterprise risk through governance and process, not just patch isolated findings or rely on perimeter defenses. SQL injection and broken access control are classic examples of defects that should be prevented through secure design and coding, then detected early through automated and manual assurance activities. Industry best practices consistently support this approach: OWASP recommends parameterized queries, server-side validation, contextual output encoding, and strong access control design; OWASP ASVS provides a structured baseline for web application security requirements; NIST SSDF (SP 800-218) emphasizes integrating secure software development practices throughout the lifecycle; and the OWASP Software Assurance Maturity Model supports establishing consistent, measurable software security activities. A WAF can supplement these controls, but it is not a substitute for building security into the application and delivery pipeline.
- A. Correct.
This is correct. Establishing consistent secure coding standards is a foundational control for reducing systemic software risk. Recognized guidance such as the OWASP ASVS, OWASP Top 10, and CERT Secure Coding standards emphasizes controls like parameterized queries to prevent SQL injection, strict server-side input validation, contextual output encoding to reduce XSS risk, and robust authorization logic to address broken access control. Centralized authorization checks are especially important because access control failures often occur when enforcement is spread inconsistently across application components. This option addresses root causes rather than symptoms.
- B. Incorrect.
This is incorrect. A WAF can provide valuable compensating protection, especially for known attack patterns, but it should not be treated as the primary or sole mitigation for application-layer vulnerabilities. WAFs can be bypassed, may generate false positives or false negatives, and are generally weaker against business logic flaws and broken access control issues. Relying mainly on perimeter filtering reflects a common misconception that external controls can replace secure design and coding practices.
- C. Correct.
This is correct. Embedding security testing into CI/CD operationalizes secure development and helps detect defects earlier, when remediation is less costly. SAST can identify insecure coding patterns and tainted data flows during development, while DAST can validate exploitable behaviors in running applications. Remediation gates for high-severity findings are a practical governance mechanism that aligns security with release management. This approach supports a scalable, repeatable DevSecOps model rather than ad hoc testing late in the project.
- D. Incorrect.
This is incorrect. Deferring known vulnerabilities until after release unnecessarily accepts avoidable risk, particularly for issues such as SQL injection and broken access control that are routinely exploited and can lead to data compromise. Network segmentation may reduce blast radius in some environments, but it does not remediate application-layer flaws exposed to users. This option reflects a risky misconception that environmental controls can sufficiently offset insecure code in internet-facing systems.
- E. Incorrect.
This is incorrect. Third-party development does not transfer accountability for enterprise risk. While vendors can and should be held contractually responsible for secure coding practices, the organization remains accountable for governance, assurance, acceptance criteria, and independent validation of security requirements. Exclusive reliance on the vendor is a governance failure and contradicts effective third-party risk management practices.