# Secure SDLC Guidance

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

---

## 1. Purpose & Scope
Implementation guidance for the [Secure Software Development Lifecycle Policy](secure_sdlc_policy.md). Applies to engineering teams.

---

## 2. Tooling Patterns
- **SAST:** run in CI on every PR, not just nightly — catch it before merge, not after.  
- **Dependency scanning:** Dependabot/Renovate + a vulnerability scanner (e.g., Snyk, Trivy, `npm audit`/`pip-audit`) gated in CI.  
- **SBOM:** generate via CycloneDX or SPDX tooling as a build artifact, not a one-off manual exercise.  
- **Secret scanning:** pre-commit hook + CI-time scan — see [Secrets & Key Management Guidance §4](secrets_management_guidance.md).

## 3. ASVS Level — How to Decide
- Level 1: internal tools, low sensitivity, no kill-chain adjacency.  
- Level 2: anything externally exposed, anything touching TLP:AMBER+ data, anything adjacent to a kill-chain system per [Authentication Policy §2.1](authentication_policy.md).  
- Level 3: reserve for the kill-chain systems themselves (IdP, PKI, payment processing) — not the default; apply deliberately.

## 4. Threat Modeling — Lightweight Version
- STRIDE walkthrough in a design doc before build starts for anything hitting ASVS Level 2+.  
- Doesn't need a dedicated meeting for every feature — fold it into design review for qualifying systems only.

## 5. Checklist
✅ SAST + dependency scan gates block merge on new critical/high findings.  
✅ SBOM generated per production build.  
✅ Threat model documented for kill-chain-adjacent systems before build.  
✅ Pen test scheduled annually for externally exposed production apps.  
✅ No hardcoded secrets — verified by scanner, not just code review.

---

## 6. References
- **[NIST SP 800-218 (SSDF)](https://csrc.nist.gov/pubs/sp/800/218/final)**  
- **[OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/)**