3.8 KiB
3.8 KiB
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.
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) must undergo threat modeling before implementation begins.
2.2 Secure Coding Standards
- Applications must meet OWASP ASVS Level 1 minimum; kill-chain-adjacent and externally exposed applications must meet Level 2.
- Authentication implementations must conform to Authentication Policy and OWASP Authentication Cheat Sheet.
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.
- 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 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 |