Explorer
KNOW-PAT-220

Secure SDLC Checklist — Sécurité à chaque phase du cycle de développement

Domaine
cybersecu
Type
pattern
Priorité
P0

Secure SDLC Checklist

Problème

La sécurité est souvent bolt-on après le développement, ce qui coûte 10-100x plus cher que de l'intégrer dès le départ.

Solution

Checklist par phase du SDLC, alignée OWASP Top 10:2025, ASVS 5.0, NIST SSDF et Proactive Controls.

Checklist par phase

1. Discovery / Requirements

  • Choisir niveau ASVS (Level 1 minimum, Level 2 si données personnelles, Level 3 si financier/santé)
  • Définir les exigences sécurité (auth, encryption, retention, logging)
  • Classifier les données (public, internal, personal, sensitive, financial, credentials)
  • Identifier les obligations légales (GDPR, PCI-DSS, HIPAA)

2. Architecture / Design

  • Secure by Design : appliquer les patterns architecturaux OWASP SbD
  • Threat modeling (Threat Dragon) pour projets sensibles
  • Privacy by Design : minimisation, pseudonymisation, defaults privacy-friendly
  • Chiffrement by default : TLS 1.3 in transit, AES-256 at rest
  • Least privilege : service-to-service, engineer, support, customer admin
  • Mapper data flow end-to-end (APIs, DBs, logs, caches, backups, analytics)

3. Implementation

  • C1 — Define Security Requirements (ASVS level choisi)
  • C2 — Leverage Security Frameworks (NextAuth, bcrypt, Prisma, DOMPurify)
  • C3 — Secure Database Access (parameterized queries, least privilege DB user)
  • C4 — Encode and Escape Data (context-aware : HTML, attribute, JS, URL, CSS)
  • C5 — Validate All Inputs (server-side, schema validation)
  • C6 — Implement Digital Identity (MFA/FIDO2, argon2, sessions sécurisées)
  • C7 — Enforce Access Controls (server-side, RBAC, Row-Level Security)
  • C8 — Protect Data Everywhere (TLS 1.3, AES-256, key management)
  • C9 — Security Logging and Monitoring (audit logs, SIEM forwarding)
  • C10 — Handle Errors Securely (pas de stack traces en prod, error boundaries)

4. Pre-commit

  • Secret scanning (trufflehog, detect-secrets, git-secrets)
  • Linting (ESLint security plugin, Bandit pour Python)
  • Pas de secrets dans le code (env vars ou Vault)

5. CI/CD (Build & Test)

  • SAST (Semgrep, SonarQube)
  • SCA (Trivy, OWASP Dependency-Check, DevGuard)
  • DAST si web app (OWASP ZAP, Burp Suite)
  • IaC scanning si infrastructure (Trivy, Checkov)
  • Container scanning si Docker
  • SBOM generation (CycloneDX)
  • License compliance check

6. Pre-release

  • ASVS checklist verification (niveau choisi en phase 1)
  • Security headers verification (HSTS, CSP, X-Frame-Options, etc.)
  • Pen test si projet sensible
  • Privacy review structured (KNOW-REF-050)

7. Production

  • Audit logs actifs et forwardés vers SIEM externe
  • Monitoring des anomalies de sécurité
  • Incident response runbook documenté
  • HSTS, CSP strict, security headers
  • TLS 1.2+ sur tous les endpoints
  • RBAC enforced
  • Retention policies actives (automated deletion)

Quand l'utiliser

Tout projet (web, API, mobile, desktop). Le niveau de rigueur s'adapte au niveau ASVS choisi.

Quand NE PAS l'utiliser

Jamais — c'est un framework universel. Même un prototype doit au minimum faire C3, C4, C5.

Références

  • [[KNOW-REF-042]] — OWASP Top 10:2025
  • [[KNOW-REF-043]] — OWASP ASVS 5.0
  • [[KNOW-REF-044]] — OWASP Proactive Controls
  • [[KNOW-REF-046]] — NIST SSDF
  • [[KNOW-REF-047]] — OWASP Secure by Design
  • [[KNOW-REF-050]] — Privacy by Design Checklist
  • [[KNOW-PAT-221]] — Privacy by Design Architecture
  • [[KNOW-PAT-222]] — DevSecOps Pipeline Setup
  • [[KNOW-PAT-223]] — Security Headers & CSP
  • [[KNOW-PAT-224]] — Secure Auth Implementation
  • [[KNOW-PAT-225]] — Secrets Management