Intégrer la sécurité dans le SDLC - Guide par phase

Intégrer la sécurité dans le Software Development Lifecycle (SDLC) ne consiste pas à ajouter un scanner en fin de pipeline. C'est une démarche qui touche chaque phase - des exigences au runtime - avec des activités, des livrables et des points de contrôle différents à chaque étape. Ce guide décrit ce qu'il faut faire, par phase, avec les frameworks de référence (NIST SSDF, OWASP SAMM, BSIMM) et les livrables concrets à produire.

1. Pourquoi raisonner par phase du SDLC

1.1 Chaque phase a ses failles caractéristiques

Une vulnérabilité n'apparaît jamais par hasard. Elle a toujours une origine traçable à une phase précise :

• Requirements manquantes : feature lancée sans penser à l'authentification multi-facteur, MFA rétro-ajouté dans la douleur.
• Design défaillant : choix d'architecture qui expose la surface (monolithe sans zone DMZ, API publique par défaut).
• Coding : injection SQL par concaténation, secret en dur, crypto faible.
• Build : dépendance vulnérable embarquée, image de base obsolète.
• Test : cas d'abus non couverts, tests fonctionnels seulement.
• Release : config de production relâchée, secrets mal injectés.
• Run : absence de logs, pas de détection d'intrusion, patch management négligé.

Un scanner SAST en CI ne corrige que les failles de la phase "coding". Il laisse entières celles des autres phases.

1.2 Les frameworks de référence

Trois frameworks structurent la pensée SDLC sécurisé :

• NIST SP 800-218 (Secure Software Development Framework - SSDF) : référence gouvernementale US, adoptée dans les appels d'offres fédéraux et de plus en plus en Europe. 42 pratiques classées en 4 catégories : Prepare the Organization, Protect Software, Produce Well-Secured Software, Respond to Vulnerabilities.
• OWASP SAMM v2 : Software Assurance Maturity Model. Modèle orienté maturité (3 niveaux par pratique), adapté pour auto-évaluation et roadmap.
• BSIMM (Building Security In Maturity Model) : étude empirique annuelle sur les pratiques réellement observées dans plus de 130 organisations. Pas un framework prescriptif mais un benchmark.

À ces trois s'ajoute le Microsoft SDL, historique (depuis 2004) et très complet, plus lourd mais toujours pertinent pour les projets longue durée.

2. Phase 1 - Requirements et planning

La sécurité commence avant la première ligne de code, au moment où on décide quoi construire.

2.1 Security requirements explicites

Chaque feature doit avoir des exigences de sécurité documentées, au même titre que les exigences fonctionnelles. Formulation type :

• "Les identifiants utilisateur doivent être hachés avec Argon2id, cost ≥ 3, mémoire ≥ 64 MiB."
• "Aucune donnée personnelle ne doit apparaître dans les logs applicatifs."
• "L'API doit rejeter toute requête non authentifiée en moins de 100 ms sans consommer de ressource downstream."

Référentiel utile : ASVS (Application Security Verification Standard) de l'OWASP, qui fournit un catalogue d'exigences classées en 3 niveaux (L1 basique, L2 standard, L3 sensible).

2.2 Abuse cases et security user stories

Pour chaque user story fonctionnelle, écrire au moins une abuse story qui décrit comment un attaquant tenterait de la détourner.

Exemple, user story : "En tant qu'utilisateur, je veux réinitialiser mon mot de passe par email."

Abuse stories associées :

• En tant qu'attaquant, je veux énumérer les comptes valides via le formulaire de reset (timing attack, message différencié).
• En tant qu'attaquant, je veux prendre le contrôle d'un compte via un lien de reset prédictible.
• En tant qu'attaquant, je veux déclencher un DoS en spammant les demandes de reset.

Ces abuse stories deviennent des cas de test obligatoires plus tard.

2.3 Cartographie des données et classification

Avant de concevoir, savoir quelles données le système va manipuler et leur sensibilité :

2.4 Mapping compliance

Si le produit est soumis à régulation, cartographier les exigences dès le départ :

• RGPD : minimisation, consentement, droit à l'oubli, PIA si risque élevé.
• NIS 2 (EU, transposée en France en 2024) : obligations de sécurité pour les entités essentielles et importantes.
• PCI-DSS : si données cartes bancaires manipulées.
• HDS : si données de santé hébergées en France.
• DORA (finance EU, applicable depuis janvier 2025) : résilience opérationnelle numérique.
• Cyber Resilience Act (EU, exigences à partir de 2027) : produits avec éléments numériques commercialisés dans l'UE.

2.5 Livrables de la phase

• Document d'exigences sécurité (ASVS-mapped).
• Classification des données.
• Liste des obligations réglementaires applicables.
• Abuse cases par feature critique.

3. Phase 2 - Design et architecture

3.1 Threat modeling

Activité centrale. Pour chaque feature significative ou module nouveau :

STRIDE est la méthode la plus répandue. Six catégories de menaces :

• Spoofing (usurpation d'identité)
• Tampering (altération de données)
• Repudiation (déni d'une action)
• Information disclosure (fuite d'information)
• Denial of Service
• Elevation of privilege (escalade)

Workflow light (1h par feature) :

1. Dessiner le data flow diagram (DFD) : entités, processus, data stores, frontières de confiance.
2. Pour chaque élément traversant une frontière de confiance, lister les menaces STRIDE applicables.
3. Pour chaque menace pertinente, définir une mitigation.
4. Documenter dans un format léger (ticket Jira, markdown dans le repo).

Outils : OWASP Threat Dragon (open source), Microsoft Threat Modeling Tool (gratuit, Windows), IriusRisk (payant, entreprise).

3.2 Méthodes plus lourdes

• PASTA (Process for Attack Simulation and Threat Analysis) : 7 étapes, très structuré, adapté aux projets sensibles.
• DREAD : scoring de menaces (Damage, Reproducibility, Exploitability, Affected users, Discoverability). Déprécié car trop subjectif, mais encore utilisé comme point de départ.
• Attack Trees : arbres logiques de scénarios d'attaque, utiles pour threat modeling créatif mais lourds à maintenir.

3.3 Principes d'architecture à appliquer

• Zero Trust : aucune identité ni réseau n'est de confiance par défaut. Chaque appel est authentifié et autorisé, y compris est-est.
• Défense en profondeur : plusieurs couches de contrôle (WAF + authN + authZ + validation applicative + chiffrement DB).
• Least privilege : chaque composant n'a que les droits strictement nécessaires.
• Fail-safe defaults : en cas d'échec, le comportement par défaut est restrictif, pas permissif.
• Complete mediation : chaque accès à une ressource protégée passe par un contrôle.
• Economy of mechanism : plus c'est simple, plus c'est auditable.
• Separation of duties : les privilèges critiques sont divisés entre plusieurs rôles.

3.4 Security architecture review

Avant de coder, le design est reviewé par un architecte sécurité ou par le security champion de la squad. Points de vigilance :

• Choix des frameworks : ont-ils des vulnérabilités structurelles connues ?
• Authentification et gestion de sessions : standards (OAuth 2.0, OIDC) vs rouler son propre mécanisme.
• Segmentation réseau : quelles communications traversent quelles zones ?
• Secrets management : où sont stockés les secrets, comment sont-ils injectés, comment sont-ils rotés ?
• Logging et observabilité : les événements sécurité sont-ils traçables ?

3.5 Livrables de la phase

• Data flow diagrams annotés des frontières de confiance.
• Threat model (STRIDE ou PASTA) avec mitigations.
• Security architecture review signée.
• Décisions de technos/frameworks documentées avec justification sécurité.

4. Phase 3 - Implementation et coding

4.1 Secure coding standards

Chaque langage principal du projet doit avoir son guide de secure coding interne, court (5-10 pages) et adapté au contexte. Sources de référence :

• OWASP Secure Coding Practices Quick Reference Guide.
• CERT Secure Coding Standards (CMU) pour C, C++, Java, Perl.
• OWASP Cheat Sheets par sujet (Authentication, Session Management, Input Validation, etc.).

Exemples de règles obligatoires :

• Pas de concaténation de string pour construire des requêtes SQL : paramètres liés uniquement.
• Encodage contextualisé des outputs (HTML, JS, URL, CSS).
• Validation positive (allowlist) plutôt que négative (denylist).
• Pas de eval(), exec(), Function() sur input utilisateur.
• Crypto : utiliser les primitives modernes (Argon2id pour hash mdp, AES-GCM pour chiffrement symétrique, Ed25519 pour signatures).

4.2 IDE plugins et pre-commit hooks

Feedback loop court = adoption réelle.

• Linters sécurité dans l'IDE : Snyk Code, Semgrep LSP, SonarLint, CodeQL. Le développeur voit le problème dans sa fenêtre d'édition, pas 20 minutes plus tard dans le CI.
• Pre-commit hooks via pre-commit framework :

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.2
    hooks:
      - id: gitleaks
  - repo: https://github.com/returntocorp/semgrep
    rev: v1.60.0
    hooks:
      - id: semgrep
        args: ["--config=p/r2c-ci", "--error"]
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.3.0
    hooks:
      - id: ruff
        args: [--select=S]

• Secrets scanning obligatoire sur tous les commits, pas seulement les pushes.

4.3 SAST en continu

• SAST léger en pre-commit et à chaque PR (Semgrep, CodeQL, SonarQube).
• SAST approfondi hebdomadaire sur l'ensemble du repo.
• Remontée des findings directement dans la PR (comments inline), pas dans un outil externe que personne ne consulte.
• Filtrage des faux positifs tracé : chaque suppression doit être justifiée par écrit et revue périodiquement.

4.4 Peer review avec focus sécurité

• Revue de code obligatoire sur branches protégées.
• Checklist de revue incluant points sécurité : validation d'input, gestion d'erreur, logs qui ne fuient pas, choix crypto, gestion de sessions.
• Security champions impliqués sur les PR touchant des zones sensibles (auth, crypto, data access).

4.5 Formation continue des développeurs

• Secure coding training annuel obligatoire (1 à 2 jours).
• Sessions courtes (30 min) mensuelles sur incidents récents ou nouveaux patterns.
• CTFs internes : learning par le faire.
• OWASP Top 10 et CWE Top 25 comme socle partagé.

4.6 Livrables de la phase

• Secure coding standards par langage, versionnés dans le repo.
• Pre-commit config committée.
• Pipeline SAST vert sur toutes les PR avant merge.
• Baseline de faux positifs documentée.

5. Phase 4 - Build et packaging

5.1 Software Composition Analysis (SCA)

Vérification systématique des dépendances tierces pour CVE connues.

• Outils : Dependabot, Renovate, Snyk Open Source, OWASP Dependency-Check, Grype.
• Politique : pas de dépendance critique ou haute non mitigée en main.
• Exceptions documentées et datées (expiration max 30 jours sur haute, 7 jours sur critique).
• Automatisation des PR de mise à jour via Renovate ou Dependabot.

5.2 SBOM automatique

Génération d'un Software Bill of Materials à chaque build :

• Format CycloneDX ou SPDX.
• Outils : Syft (Anchore), CycloneDX CLI, Trivy SBOM.
• Signature cryptographique du SBOM (attestation).
• Matching automatique contre les CVE publiées (ex. Grype sur SBOM).

En 2026, le SBOM n'est plus optionnel : il est exigé par le Cyber Resilience Act et par plusieurs gouvernements dans leurs appels d'offres.

5.3 Container scanning

Si le livrable est une image Docker :

• Scan de l'image avant push au registry (Trivy, Grype, Snyk Container, Anchore).
• Seuils : pas de critique, pas de haute non approuvée.
• Image de base minimale : distroless, Chainguard, Wolfi, Alpine si nécessaire.
• Non-root user par défaut.
• Filesystem read-only si possible.
• Image scannée périodiquement après release (nouvelles CVE publiées).

5.4 IaC scanning

Infrastructure as Code = Terraform, Helm, Kubernetes manifests, Ansible, CloudFormation.

• Outils : Checkov, tfsec, KICS, Terrascan, Datree.
• Règles : pas de bucket S3 public, security groups restreints, RBAC minimal, secrets non inlined.
• Exécuté en CI sur toute modification de terraform/, helm/, k8s/, etc.

5.5 Artifact signing

• Sigstore/Cosign pour signer les images Docker et artefacts binaires.
• Mode keyless recommandé : l'identité est attestée par OIDC (GitHub Actions, GitLab CI, etc.) et enregistrée dans Rekor (transparency log public).
• Vérification obligatoire au déploiement.

5.6 Reproductible builds

• Builds déterministes (même commit → mêmes bytes).
• Nécessite pinning complet : versions du compilateur, versions des libs, ordre de build stable.
• Base solide pour attestation SLSA Level 3.

5.7 Livrables de la phase

• SBOM signé par build.
• Attestation SLSA (minimum Level 2, viser Level 3).
• Image/artefact signé avec Cosign.
• Rapport SCA à jour.

6. Phase 5 - Test et validation

6.1 DAST

Scan de l'application en cours d'exécution depuis l'extérieur :

• OWASP ZAP en mode baseline en CI sur staging.
• Scans complets manuels périodiques (1 à 4 fois par an selon criticité).
• Authenticated scans : configuration de ZAP pour s'authentifier et scanner derrière le login.

6.2 IAST (Interactive Application Security Testing)

Agent instrumenté qui surveille l'application pendant les tests fonctionnels et remonte les vulnérabilités observées.

• Outils : Contrast Security, Seeker (Synopsys), HCL AppScan IAST.
• Avantages : peu de faux positifs (observation réelle), détection des failles de flux complexes.
• Limite : nécessite un agent runtime qui peut impacter les performances.

6.3 Fuzzing

Envoi massif d'inputs aléatoires ou guidés pour trouver des crashs et vulnérabilités :

• Libfuzzer / AFL++ pour binaires natifs.
• go-fuzz / natif Go 1.18+ pour Go.
• Jazzer pour Java.
• Atheris pour Python.
• Fuzzing d'API : Schemathesis, RESTler, APIsec.
• OSS-Fuzz (Google) : programme de fuzzing continu gratuit pour projets open source.

6.4 Security regression tests

Chaque vulnérabilité corrigée doit donner naissance à un test automatisé qui échoue si la faille réapparaît :

• Cas d'abus des user stories en test d'intégration.
• Anciens bugs sécurité rejoués après chaque release.
• Tests négatifs (input malveillant → rejet propre) dans les suites de tests unitaires.

6.5 Penetration testing

Tests manuels par des pentesteurs indépendants.

• Fréquence : annuelle au minimum, plus si le produit évolue rapidement ou a une forte exposition.
• Scope : périmètre clair, règles d'engagement documentées.
• Livrable : rapport avec findings priorisés, mesures de remédiation, re-test inclus.
• Attention : le pentest n'est pas un substitut au DevSecOps courant. Il confirme ou infirme, il ne construit pas la sécurité.

6.6 Bug bounty

Programme d'incitation aux chercheurs externes :

• Plateformes : HackerOne, YesWeHack, Bugcrowd, Intigriti.
• Scope défini, paiements clairs.
• Triage rapide (SLA de 24-48 h sur les critiques).
• Complémentaire au pentest, pas substituable.

6.7 Livrables de la phase

• Rapport DAST automatisé par build.
• Rapport de pentest annuel avec retest.
• Liste des security regression tests active.
• Couverture fuzzing documentée.

7. Phase 6 - Release et déploiement

7.1 Gates de déploiement

Un artefact n'atteint la production que s'il a passé tous les contrôles amont :

• SAST vert sur la branche mergée.
• SCA vert (ou exceptions documentées).
• Container scan vert.
• IaC scan vert.
• SBOM généré et signé.
• Image signée avec Cosign.
• Tests d'intégration verts, y compris sécurité regression.

Ces gates sont configurés dans la CI (GitLab CI, GitHub Actions, Jenkins) et bloquants par défaut.

7.2 Admission controllers

Côté cible (Kubernetes notamment) :

• Kyverno ou OPA Gatekeeper : refuse les pods non conformes (privileged, hostPath, sans resource limits, sans probe, sans label obligatoire).
• Vérification de signature : Kyverno peut refuser de déployer une image non signée ou dont la signature ne correspond pas.
• Policy as Code : toutes les règles sont versionnées dans un repo dédié et testées avant application.

7.3 Release approvals

• Environnements protégés dans GitLab/GitHub : approbation humaine requise avant deploy prod.
• Séparation des rôles : celui qui développe n'est pas celui qui déploie (ou au minimum, approbation par un tiers).
• Change advisory léger pour les changements à risque.

7.4 Déploiement progressif

• Blue-green ou canary pour limiter l'impact d'une régression sécurité.
• Feature flags pour activer progressivement une nouvelle feature sensible.
• Rollback automatisé sur signaux d'alerte (erreurs 5xx, latence, logs de sécurité).

7.5 Livrables de la phase

• Pipeline de release documenté, chaque gate tracé.
• Policies admission controllers dans un repo versionné.
• Procédure de rollback testée.

8. Phase 7 - Run et operations

La sécurité ne s'arrête pas au déploiement. 40 à 60 % du coût de sécurité d'un produit long-terme est post-release.

8.1 Runtime protection

• WAF (Web Application Firewall) : Cloudflare, AWS WAF, ModSecurity. Filtre les attaques connues (OWASP CRS).
• RASP (Runtime Application Self-Protection) : agent dans l'application qui détecte et bloque les attaques (Contrast, Imperva).
• Runtime container security : Falco pour Kubernetes, détecte les syscalls anormaux.
• EDR/XDR sur les serveurs et postes de travail.

8.2 Logging et observabilité sécurité

• Centralisation des logs (ELK, Splunk, Datadog, Grafana Loki).
• Événements sécurité à tracer obligatoirement : authentification (succès/échec), autorisation refusée, création/suppression d'utilisateur, changement de permission, accès aux données sensibles, appels aux APIs admin.
• SIEM : corrélation et détection (Splunk Enterprise Security, Elastic Security, Sentinel, Chronicle).
• Rétention conforme à la réglementation (typiquement 1 an, parfois plus selon secteur).

8.3 Vulnerability management post-release

• Scan des dépendances quotidien sur les versions en production.
• Patch management : SLA par sévérité (critique = 7 jours, haute = 30 jours, moyenne = 90 jours).
• Processus de hotfix documenté et répété en exercice.
• Suivi CISA KEV (Known Exploited Vulnerabilities) pour prioriser les correctifs activement exploités.

8.4 Incident response

• Plan d'incident response versionné, testé annuellement en tabletop exercise.
• Équipe d'astreinte formée, avec escalade définie.
• Runbooks par type d'incident (fuite de credentials, intrusion, ransomware, DoS).
• Communication : porte-parole désigné, modèles de messages préparés, contacts légal/CNIL prêts.
• Post-mortem systématique, sans blame, avec actions correctives trackées jusqu'à clôture.

8.5 Threat intelligence

• Veille CTI (Cyber Threat Intelligence) : flux MISP, OpenCTI, commerciaux (Recorded Future, Mandiant).
• Intégration des IoC (Indicators of Compromise) dans le SIEM et les outils de détection.
• Surveillance des forums et paste sites pour leak de données.

8.6 Red team exercises

Exercices offensifs périodiques par une équipe interne ou externe simulant un attaquant avancé :

• Scope large (pas seulement techniques mais aussi social engineering, accès physique, pivot interne).
• Objectifs définis : atteindre une donnée cible, compromettre un admin, tenir 30 jours sans détection.
• Livrable : rapport, plan d'action pour la blue team, mesures d'amélioration.

8.7 Livrables de la phase

• Procédures d'IR documentées et testées.
• Dashboard sécurité runtime à jour.
• Rapport de vulnérabilités mensuel avec indicateurs de MTTR.
• Calendrier d'exercices red team/blue team.

9. Gouvernance et transverse

Certaines activités ne se logent pas dans une phase unique, mais accompagnent tout le SDLC.

9.1 Security champions program

• Un développeur par squad, formé renforcé en sécurité.
• 10-20 % de son temps dédié aux activités sécurité de l'équipe.
• Relais avec l'équipe AppSec centrale.
• Renouvelé tous les 12-18 mois pour diffuser la culture.

9.2 Formation et éducation

• Onboarding sécurité obligatoire pour tout nouvel arrivant tech.
• Secure coding annuel par langage.
• CTFs internes, hack days, brown bags.
• Newsletter sécurité interne mensuelle : CVE du mois, incidents significatifs publics, nouveaux patterns.

9.3 Métriques qui pilotent vraiment

Mauvaises métriques : "nombre de findings", "coverage scanner". Vaniteuses, ne reflètent pas la sécurité réelle.

Bonnes métriques :

• MTTR (Mean Time To Remediate) par sévérité.
• Vulnerability escape rate : proportion de vulnérabilités détectées en production qui auraient dû être attrapées plus tôt.
• Coverage des threat models sur les nouvelles features critiques.
• Pourcentage de squads avec un champion actif et formé.
• Delta de findings ouverts mois sur mois (tendance, pas valeur absolue).
• Temps moyen entre publication CVE et patch en production.

9.4 Risk management

• Registre des risques tenus à jour.
• Matrice probabilité × impact pour prioriser.
• Décisions d'acceptation de risque documentées et signées par un décideur.
• Revue trimestrielle.

9.5 Third-party risk

• Évaluation sécurité des fournisseurs avant contrat (questionnaires SIG, SOC 2 reports, pentests tiers).
• Clauses contractuelles : obligations de notification d'incident, droit d'audit, exigences RGPD/DORA.
• Re-évaluation annuelle.

10. Modèle de maturité - où viser par où commencer

Pour une équipe qui part d'un SDLC sans intégration sécurité, voici un parcours réaliste sur 18 mois.

Ne pas sauter d'étape : faire du RASP sans SAST en place, c'est mettre une alarme sur un bâtiment sans porte.

11. Pièges fréquents dans l'intégration SDLC

11.1 Tout faire en même temps

Déployer SAST + DAST + SCA + SBOM + Cosign + OPA + Falco en 3 mois, sur toutes les équipes, avec gates bloquantes → protestation, désactivation, programme mort. Itérer.

11.2 Sécurité en silo

L'équipe AppSec qui reste centralisée, produit des tickets Jira, ne forme personne, ne se rapproche pas des squads. Les squads continuent comme avant.

11.3 Oublier la phase requirements

Commencer directement au coding. Les failles de design coûtent 10 fois plus cher à corriger que les failles d'implémentation.

11.4 Pas de boucle de feedback avec la production

Les incidents réels ne remontent pas aux équipes dev, les threat models ne sont pas mis à jour, les mêmes erreurs se répètent.

11.5 Confondre activité et résultat

"Nous avons scanné 100 % du code" ne veut rien dire si 70 % des findings critiques sont ouverts depuis 9 mois. Focus sur les sorties, pas les entrées.

12. Ressources pour approfondir

• NIST SP 800-218 (SSDF v1.1) : framework de référence.
• OWASP SAMM v2 : modèle de maturité.
• BSIMM : benchmark annuel (Synopsys).
• OWASP ASVS : catalogue d'exigences applicatives.
• OWASP Threat Modeling Manifesto : principes de threat modeling.
• Cyber Resilience Act (EU) : exigences produit à venir 2027.
• ISO/IEC 27034 : sécurité des applications.

13. Verdict et posture Zeroday

Intégrer la sécurité dans le SDLC n'est pas une course d'outils. C'est un travail d'ingénierie organisationnelle autant que technique : impliquer les bonnes personnes, aux bons moments, avec les bons livrables. Les outils viennent après.

Un SDLC mature n'élimine pas les vulnérabilités - rien n'y parvient. Il réduit leur coût (détection plus précoce), accélère leur correction (processus rodé), limite leur impact (défense en profondeur, détection runtime).

Pour un développeur, comprendre le SDLC sécurisé ouvre une conversation utile avec le management : la sécurité n'est pas un blocage, c'est une manière d'opérer. Pour une équipe, c'est le différenciateur entre livrer vite et livrer bien. Pour un responsable AppSec, c'est la grille de lecture qui transforme un catalogue d'outils épars en programme cohérent.