2.0 KiB
2.0 KiB
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. 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.
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.
- 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.