Secure SDLC (Software Development Life Cycle)

Statut : draft. Cible technique : OWASP ASVS 4.0 Niveau 2 (recommandé pour fintech). Mapping en cours.

1. Principes

• La sécurité est traitée à chaque étape du cycle, pas uniquement en fin de chaîne.
• Toute nouvelle feature touchant l'argent, les PII ou l'authentification déclenche un threat modeling léger.
• Aucune modification de prod sans revue de code par au moins 1 personne (cf. ADR [À CONFIRMER MR approval]).
• Tout incident produit une leçon apprise réinjectée dans le SDLC (cf. IRP §3.4).

2. Étapes du SDLC

Étape 1 — Idée / spec

• Ticket Jira créé.
• Si feature touche argent, PII, auth, providers : checkbox "threat modeling fait" obligatoire avant développement.

Étape 2 — Design

• Documenter les flows critiques (cf. /flows/).
• Mettre à jour le data flow diagram si circulation de données change.
• Mettre à jour l'ACM si nouveau rôle / nouvelle ressource.
• Décision structurante → écrire un ADR (cf. /architecture/adr/).

Étape 3 — Code

• TypeScript strict mode (tsconfig partagé @nex/tsconfig).
• ESLint avec règles sécu (@nex/eslint-config).
• DRY, max 70 lignes logiques par fonction, early returns, no dead code (cf. CLAUDE.md racine).
• Jamais de secret en clair, jamais de logging de PII non masquée.
• Validation des inputs (DTO + class-validator côté NestJS).

Étape 4 — Review

• Merge request obligatoire vers develop, avec au moins 1 reviewer.
• Convention de commit (@nex/eslint-config + Commitlint).
• Checklist code review (cf. /dev/code-review).
• Reviewer doit vérifier : DTO validation, gestion d'erreurs, pas de secret, pas de log PII, threat model encore valable.

Étape 5 — Test

• Unit tests : Jest, couverture cible [À CONFIRMER].
• Integration tests : services + DB locale ou conteneurisée.
• E2E : [À CONFIRMER framework — Cucumber côté orchestrator, Detox/Maestro côté mobile ?].
• Tests négatifs : ne pas tester seulement le golden path.
• Tests compliance : limites BEAC, PEP, sanctions, double-spend (cf. /qa/compliance-test-cases).

Étape 6 — Build

• Build via Turborepo + Nest CLI.
• Image Docker construite en CI.
• Scan image Trivy (déjà en CI, cf. infrastructure/cicd/_templates.yml). Sortie : security-reports/<service>-trivy.json.
• SBOM [À PROVISIONNER — Trivy peut générer SPDX/CycloneDX].

Étape 7 — Deploy

• Pipeline modulaire GitLab (prepare → test → build → security → migrate → deploy).
• deploy:review automatique par MR labelisée (cf. /operations/cicd-deploy-review).
• deploy-staging manuel après merge develop.
• Production : [À CONFIRMER trigger].
• Aucun skip d'étape sécurité possible (le job est obligatoire).

Étape 8 — Run

• Monitoring Grafana / Loki (cf. /operations/monitoring-alertes).
• Alerting sur erreurs, latence, taux d'erreur.
• Surveillance du risk-engine (taux blocked, latence adapters).
• Trace audit (en attendant logs-reporting complet).

3. Mapping OWASP ASVS 4.0 Niveau 2

Gap analysis à conduire chapitre par chapitre. Pour chaque contrôle ASVS L2 :

Statut	Sens
✅	Implémenté et démontré
⚠️	Partiel — soit non couvert sur tout le périmètre, soit non documenté
❌	Non couvert
N/A	Hors scope Nex

Vue d'ensemble (snapshot, à affiner)

Chapitre ASVS	Couverture estimée	Commentaire
V1 — Architecture, design and threat modeling	⚠️	C4, DFD, trust boundaries en place ; threat models par service à compléter
V2 — Authentication	⚠️	Firebase tokens OK ; MFA admin à confirmer
V3 — Session management	⚠️	Sessions Auth en place ; rotation et invalidation à documenter
V4 — Access control	⚠️	RBAC + merchant_members en place ; matrice complète draft
V5 — Validation, sanitization and encoding	✅	DTO + class-validator côté Nest, ValidationPipe
V6 — Stored cryptography	⚠️	bcrypt PIN ✅ ; encryption at-rest à confirmer
V7 — Error handling and logging	⚠️	erreurs domain custom ✅ ; logging structuré JSON ; masquage PII à formaliser
V8 — Data protection	⚠️	classification définie ; rétention et droit à l'oubli à formaliser
V9 — Communication	✅	TLS 1.2+ partout
V10 — Malicious code	⚠️	Trivy CI ✅ ; SCA dépendances à intégrer (Snyk/Dependabot)
V11 — Business logic	⚠️	risk engine ✅ ; maker-checker à enforce sur paiements bulk
V12 — Files and resources	⚠️	file-service OK ; MIME whitelist OK ; scan antivirus à confirmer
V13 — API and Web services	⚠️	NestJS guards/scopes OK ; CORS permissif à durcir
V14 — Configuration	⚠️	Doppler OK ; Helmet / CSP / headers sécurité à activer

Cible : produire un SoA détaillé par contrôle dans un fichier dédié (/security/asvs-soa.md) après gap analysis complète.

4. Outils

Outil	Étape	Statut
TypeScript strict	Code	✅
ESLint @nex/eslint-config	Code	✅
Commitlint	Commit	✅
Husky pre-commit	Commit	✅
Jest	Test	✅
class-validator + ValidationPipe	Code/Test	✅
Trivy (container scan)	Build	✅
pnpm audit / npm audit	Build	⚠️ exécuté ? non systématique
Snyk / Dependabot / Renovate	Continu	❌ à intégrer
Semgrep / SonarQube (SAST)	CI	❌ à évaluer
gitleaks (secrets scan)	Pre-commit + CI	❌ à intégrer
OWASP ZAP / Burp (DAST)	Pré-prod ou pentest	❌ à intégrer (pentest annuel)

5. Formation

• Onboarding dev inclut une revue des conventions sécurité (CLAUDE.md, /security/known-gaps).
• Refresh annuel obligatoire sur les 10 OWASP API Security.
• Sessions sur les incidents passés (RCA) ouvertes à toute l'équipe.

6. Roadmap

Court terme (≤ 1 trimestre) :

• Intégrer Renovate ou Dependabot pour la veille dépendances.
• Intégrer gitleaks en pre-commit + CI.
• Réaliser un SoA ASVS L2 complet documenté.
• Mettre en place Helmet + CSP + X-Frame-Options sur tous les services exposés (cf. known-gaps).

Moyen terme (≤ 2 trimestres) :

• Premier pentest externe.
• SAST (Semgrep ou équivalent).
• DAST sur staging (OWASP ZAP).
• Maker-checker enforced sur paiements bulk.

Long terme (≤ 1 an) :

• Certification ISO 27001.
• Audit SOC 2 Type II.