Add AGENTS.md guidance and expand Security policy library

Security/secure_sdlc_policy.md

@@ -0,0 +1,60 @@
+# 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)**