# Secure Software Development Lifecycle (SDLC) Policy

**Document owner:** [Owner/Role]  
**Approved by:** [Steering Committee / CISO]  
**Effective date:** [YYYY-MM-DD]  
**Review cadence:** [Annually]

---

## 1. Purpose & Scope
This policy establishes mandatory secure development requirements for software built or materially customized by [Organization]. It applies to all engineering teams and to third-party developers per the [Vendor & Third-Party Risk Management Policy](vendor_risk_management_policy.md).

---

## 2. Policy Statements

### 2.1 Secure Design & Threat Modeling
- New systems handling TLP:AMBER+STRICT/RED data or touching kill-chain infrastructure (per [Authentication Policy §2.1](authentication_policy.md)) **must** undergo threat modeling before implementation begins.

### 2.2 Secure Coding Standards
- Applications **must** meet [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/) Level 1 minimum; kill-chain-adjacent and externally exposed applications **must** meet Level 2.  
- Authentication implementations **must** conform to [Authentication Policy](authentication_policy.md) and [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html).

### 2.3 Dependency & Supply Chain Security
- A Software Bill of Materials (SBOM) **must** be generated for production applications.  
- Dependencies **must** be scanned for known vulnerabilities on every build; findings follow the SLA in [Vulnerability & Patch Management Policy §2.2](vulnerability_patch_management_policy.md).  
- Dependency pinning **must** be used; automatic unpinned upgrades to production are prohibited.

### 2.4 Code Review & Analysis
- All production code changes **must** be peer reviewed before merge.  
- Static analysis (SAST) **must** run on every build; dynamic analysis (DAST) **must** run at least before each production release for externally exposed applications.

### 2.5 Secrets in Code
- Secrets **must not** be committed to source control — see [Secrets & Key Management Policy §2.2](secrets_management_policy.md) and its secret-scanning guidance.

### 2.6 Penetration Testing
- Kill-chain-adjacent and externally exposed production applications **must** undergo penetration testing at least annually and after material architecture change.

### 2.7 Enforcement
- Production deployment **must not** proceed without passing SAST and dependency scanning gates, absent a documented, time-bound CISO exception.

---

## 3. Antifragility Alignment
This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**.

| Pillar | Applied In | How |
|---|---|---|
| **1. Structural Decoupling** | §2.3 | SBOM and pinned dependencies make the hidden coupling graph of third-party code visible and controllable |
| **2. Optionality Preservation** | §2.2 | Following an open standard (ASVS) rather than a single vendor's proprietary security checklist keeps the standard portable |
| **3. Stress-to-Signal Conversion** | §2.4 | SAST/DAST findings and pen test results feed the same structural-fix process as any other incident |
| **4. Sovereign Intelligence** | §2.1 | Threat models are documented artifacts, not a conversation that evaporates after the design meeting |
| **5. Asymmetric Payoff Design (Barbell)** | §2.2, §2.6 | ASVS Level 2 and mandatory pen testing concentrated on kill-chain-adjacent/external apps; internal low-risk tools stay at Level 1 |

---

## 4. References
- **[NIST SP 800-218, Secure Software Development Framework (SSDF)](https://csrc.nist.gov/pubs/sp/800/218/final)**  
- **[OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/)**  
- **[OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)**