A.8.25
Secure development life cycle
Technological controlsCheckpoints 6Evidence 7Cases 7
Control objective
This control requires the organization to build security activities into every stage of planning, designing, implementing, testing, deploying, and maintaining software and systems, so that vulnerabilities are prevented from entering deliverables and the cost of remediating them after the fact is reduced. Defining security requirements from the earliest stage and applying consistent rules and verification steps at each phase helps the organization achieve security by design and security by default. The approach should apply consistently across the whole organization regardless of the development methodology (waterfall/agile/DevOps) and whether development is in-house or outsourced.
Key checkpoints
- Is a secure development life cycle (secure SDLC) policy/standard documented and applied consistently to both in-house and outsourced development?
- Are the security activities to be performed at each stage (requirements/design/implementation/test/deployment/transition to production) and their pass criteria (security gates) defined?
- Are secure coding standards and training provided to developers, and is compliance checked?
- Is a secure development/configuration management environment (version control, access control, build/deployment pipeline) established and controlled?
- Are security requirements and verification (license, vulnerabilities, SBOM, and so on) defined for open source/third-party/outsourced components?
- Are the results of pre-deployment security review/testing (threat modeling, secure code review, vulnerability assessment) reflected in deployment approval?
Implementation guidance
- Define the security activities, roles and responsibilities, deliverables, and pass criteria across all SDLC stages as a standard, and align them with the development methodology the organization uses (including agile/DevOps).
- Derive security and privacy requirements during the planning/requirements stage, and perform threat modeling and security architecture review during the design stage.
- Establish secure coding standards (input validation, authentication/authorization, session/encryption, error handling, safe logging, and so on) and run developer training and compliance checks in parallel.
- Automate static analysis (SAST), dynamic analysis (DAST), software composition analysis (SCA/open source vulnerabilities), and secret scanning by integrating them into the CI/CD pipeline.
- Separate development/test/production environments, and secure configuration/version control, source code access control, and the integrity of build/deployment artifacts (signing, artifact verification).
- Compare pre-release security test results with risk-based approval criteria. Verify remediation and retesting of blocking defects; track acceptable exceptions with authorized residual-risk acceptance, compensating controls, remediation deadlines, and expiry.
- For outsourced development, include security requirements and acceptance criteria in the contract, and verify the security of deliverables at the point of acceptance.
Evidence
- Secure development life cycle (secure SDLC) policy/standard and procedures
- Per-stage security activity checklists and security gate pass records
- Secure coding standard documents and developer security training records
- Threat modeling/security architecture review deliverables
- SAST/DAST/SCA scan results and remediation records
- Pre-deployment security testing (code review, vulnerability assessment, penetration testing) reports and deployment approval records
- Outsourced development contracts (including security requirements) and acceptance verification results
Nonconformity examples
- A secure SDLC policy exists, but in actual projects security checks are performed only just before deployment after development is complete.
- Secure coding standards do not exist, or exist but are not shared/taught to developers and so are not actually followed.
- Security testing is not integrated into the CI/CD pipeline, so vulnerable code is deployed automatically without verification.
- Open source/third-party components are adopted without verifying their known vulnerabilities and licenses.
- A release proceeds with defects meeting blocking criteria, without remediation, authorized exception approval, or compensating controls.
- The outsourced development contract has no security requirements, and no security verification is performed at acceptance.
- Development/test/production environments and source code access privileges are not separated/controlled.