Secure Software Development Lifecycle (SSDLC) Policy

Version: 1.0 | Last updated: [Date] | Document owner: [Role, e.g., Head of Engineering/CISO]

1. Purpose

To establish mandatory security practices across every phase of [Company Name]'s software development lifecycle, reducing vulnerabilities introduced in code before reaching production.

2. Scope

Applies to all internally developed code, including web applications, APIs, automation scripts, and infrastructure as code (IaC), regardless of language or stack used.

3. Security by Development Lifecycle Phase

3.1 Planning and Design:** mandatory threat modeling for features that process sensitive data or authentication. Security requirements must be defined alongside functional requirements.

3.2 Development:** mandatory static application security testing (SAST) on every pull request before merge. Secrets (API keys, credentials) must never be committed to the repository — use of a secrets manager is mandatory.

3.3 Code Review:** all code must go through review by at least one peer before merge, with specific attention to input validation, access control, and error handling.

3.4 Testing:** automated security testing (SCA for dependencies, DAST where applicable) must run in the CI/CD pipeline before production deployment.

3.5 Deploy and Operations:** mandatory segregation between development, staging, and production environments, with distinct access controls for each.

4. Code Vulnerability Management

Identified vulnerabilities must be addressed according to severity: Critical within [timeframe, e.g., 24–72h], High within [7 days], Medium/Low within the normal sprint cycle.

5. Third-Party Dependencies

Third-party libraries and packages must be scanned for known vulnerabilities (CVE) before inclusion in the project and continuously monitored thereafter.

6. Roles and Responsibilities

• [Role, e.g., Head of Engineering]: ensures SSDLC controls are implemented in the CI/CD pipeline.
• Developers: responsible for following secure coding practices and fixing identified vulnerabilities within defined timeframes.
• [Role, e.g., CISO/AppSec]: defines severity criteria and approves exceptions.

7. Training

All developers must complete application security training (e.g., OWASP Top 10) during onboarding and annually thereafter.

8. Policy Review

Annual review, or after a security incident involving a code vulnerability.