Secure SDLC — threat modelling, secure coding, SAST/DAST, dependency scanning, DevSecOps
Primary statement
Secure SDLC operates as a pipeline-integrated discipline: (1) threat modelling for material changes (SEBI PR.12); (2) secure coding training for developers; (3) SAST on every commit, DAST on every release, dependency scanning continuous; (4) pre-production security review (RBI PR.6); (5) DevSecOps maturity at Level 4 banks — security-as-code, pipeline-enforced controls, continuous feedback loops (RBI PR.25); (6) bespoke and custom software developed securely with addressed common software vulnerabilities (PCI 6.2.1); (7) customer authentication framework with MFA for high-value transactions (RBI PR.11).
Audit-fatigue payoff
A unified SDLC programme — threat-modelling cadence + SAST/DAST/SCA pipeline configuration + secure coding training records + pre-production gate evidence — satisfies SDLC requirements across all 11 contributing frameworks. The DevSecOps pipeline configuration (RBI PR.25) is the audit-defensible anchor for Maturity Level 4 banks.
Strictness matrix
Scope
Scope: ALL software development. Coverage includes threat modelling for material changes, secure coding training for ALL developers, SAST on EVERY commit, DAST on EVERY release, dependency scanning continuous. Five enforcement points across the SDLC lifecycle.
Ceiling source: sebi_cscrf:CSCRF.PR.12
Rationale: SEBI CSCRF PR.12 specifies the most enumerated SDLC scope with explicit cadence per enforcement point.
Threshold
Threshold for pipeline integration: SAST runs on every commit; DAST on every release; dependency scanning continuous; threat modelling on material changes. Each enforcement point fires on the triggering event without exception. Critical findings fail the build.
Ceiling source: sebi_cscrf:CSCRF.PR.12
Rationale: SEBI CSCRF PR.12 specifies binary trigger conditions per enforcement point. PCI 6.2.1 requires "developed securely" without specifying cadence; SEBI is the strict threshold.
Method
Method (combined): (1) threat modelling for material changes (SEBI PR.12); (2) secure coding training for all developers with annual refresher; (3) SAST + DAST + SCA in pipeline (SEBI PR.12); (4) pre-production security review (RBI PR.6); (5) DevSecOps integration with security-as-code + pipeline-enforced controls + continuous feedback (RBI PR.25); (6) bespoke / custom software developed addressing OWASP Top 10 + framework-specific (PCI 6.2.1); (7) customer-facing apps with strong MFA for high-value transactions (RBI PR.11); (8) cloud workloads with cloud-specific SDLC controls (SEBI PR.14).
Ceiling source: rbi_csf:RBI.PR.25
Rationale: RBI CSF PR.25 DevSecOps maturity is the strictest method articulator for Level 4 banks. Combined with SEBI PR.12 pipeline-integration specifics, this is the audit-defensible architecture.
Frequency
SAST: every commit. DAST: every release. Dependency scanning: continuous. Threat modelling: per material change. Secure coding training: induction + annual refresher. Pre-production security review: every release.
Ceiling source: sebi_cscrf:CSCRF.PR.12
Rationale: SEBI CSCRF PR.12 specifies the strictest per-enforcement-point cadences. The every-commit / every-release frequency is uniquely strict.
Evidence
Required evidence: (1) SDLC framework document; (2) threat modelling records for sample material changes; (3) pipeline configuration showing SAST/DAST/SCA gates; (4) sample pipeline runs with security findings + closure; (5) secure coding training records; (6) pre-production security review records per release; (7) DevSecOps maturity assessment (RBI PR.25); (8) build-failure evidence for critical findings (not advisory only); (9) cloud-specific SDLC controls (SEBI PR.14).
Ceiling source: rbi_csf:RBI.PR.25
Rationale: RBI CSF PR.25 DevSecOps evidence list combined with SEBI PR.12 pipeline evidence is comprehensive. The build-failure evidence (not advisory-only) is uniquely strict.
Auditor test pattern
Step 1: Inspect the SDLC framework document. Step 2: Sample 1 recent release; trace through threat modelling → SAST → DAST → SCA → pre-production review. Step 3: Verify pipeline configuration fails the build on critical findings (not advisory only). Step 4: Inspect secure coding training records; verify all developers completed. Step 5: For Maturity Level 4 banks, verify DevSecOps maturity assessment exists. Step 6: For customer-facing apps with high-value transactions, verify MFA implementation (RBI PR.11). Step 7: For cloud workloads, verify cloud-specific SDLC controls (SEBI PR.14).
Common findings
Common 2024–26 findings: (1) SAST runs on PR but findings advisory-only — build never fails; (2) DAST configured but runs only quarterly, not per release; (3) Dependency scanning generates findings but no SLA for remediation; (4) Threat modelling absent or limited to design phase without revisit on material change; (5) Pre-production security review theatre — sign-off without substantive review; (6) DevSecOps claimed but security gates are external to pipeline (manual handoff); (7) Customer auth MFA bypassable via legacy paths.