A.8.25 / A.8.28 — Is there a secure development lifecycle with security testing and secure coding standards? (A.8.28 NEW)
Demonstrate that the organization operates a secure development lifecycle with documented secure coding standards, mandatory security testing at appropriate development phases, and evidence of remediation for identified vulnerabilities before production release.
Description
What this control does
This control requires organizations to implement a Secure Development Lifecycle (SDLC) incorporating security activities at every phase from requirements through deployment. Security testing includes static application security testing (SAST), dynamic application security testing (DAST), software composition analysis (SCA), and manual code reviews. Secure coding standards such as OWASP Top 10, CERT Secure Coding, or language-specific guidelines must be documented, enforced through tooling and training, and integrated into the development pipeline. This control reduces exploitable vulnerabilities in custom-developed and acquired software by embedding security into the engineering process rather than treating it as a post-development activity.
Control objective
What auditing this proves
Demonstrate that the organization operates a secure development lifecycle with documented secure coding standards, mandatory security testing at appropriate development phases, and evidence of remediation for identified vulnerabilities before production release.
Associated risks
Risks this control addresses
- Injection flaws (SQL, command, LDAP) introduced through unsanitized input handling in application code
- Authentication bypass or broken access control allowing unauthorized access to sensitive functions or data
- Use of vulnerable third-party libraries or components with known CVEs exploitable by attackers
- Hardcoded secrets (API keys, passwords, cryptographic keys) committed to source code repositories and exposed
- Insecure deserialization or XML external entity (XXE) attacks enabling remote code execution
- Deployment of untested code to production environments resulting in exploitable zero-day vulnerabilities
- Cross-site scripting (XSS) or cross-site request forgery (CSRF) attacks compromising user sessions and data
Testing procedure
How an auditor verifies this control
- Obtain the organization's secure development lifecycle policy and secure coding standards documentation, noting which frameworks are referenced (e.g., OWASP ASVS, CERT, SANS CWE Top 25).
- Review developer training records to verify that personnel writing code have completed secure coding training within the past 12 months.
- Select a representative sample of 3-5 recent software releases or major updates and retrieve associated project documentation, including security requirements and test plans.
- Examine evidence of static application security testing (SAST) execution for sampled projects, including tool configurations, scan results, and identified vulnerability reports.
- Examine evidence of dynamic application security testing (DAST) or penetration testing results for sampled projects, including scope, findings, and remediation timelines.
- Review software composition analysis (SCA) reports for the sampled projects to verify identification of third-party components and scanning for known vulnerabilities (CVEs).
- Trace a sample of critical or high-severity findings from security testing through to documented remediation, code commits, and retesting validation before release.
- Inspect CI/CD pipeline configurations to confirm automated security testing gates are enforced and that builds fail or require approval when security thresholds are breached.