SSDLC : intégrer la sécurité dans le cycle de développement logiciel

La grande majorité des incidents de sécurité impliquent une vulnérabilité dans le code applicatif ou ses dépendances :

• Injections (SQL, XSS, Command) : des entrées non validées passées directement aux interprètes. Restent dans le OWASP Top 10 depuis 2010 malgré leur prévention triviale.
• Dépendances vulnérables : Log4Shell, Spring4Shell, XZ Utils — des bibliothèques tierces avec des CVE critiques présentes dans des milliers d'applications. La supply chain logicielle est devenue un vecteur d'attaque majeur.
• Secrets codés en dur : clés API, mots de passe, tokens dans le code source ou les fichiers de configuration commités dans Git. Visibles pour toujours dans l'historique Git même après suppression.
• Logique métier défaillante : contournement de workflows, race conditions, IDOR — des vulnérabilités liées à des erreurs de conception que les scanners automatiques ne détectent pas.
• Composants open source non maintenus : des projets abandonnés utilisés en production, sans correctifs pour les nouvelles CVE.

Le threat modeling identifie les menaces potentielles avant d'écrire la première ligne de code. Réaliser cette analyse en phase de design est la mesure la plus rentable du SSDLC.

Méthode STRIDE

• S - Spoofing : usurpation d'identité (attaquant se faisant passer pour un utilisateur légitime). Contre-mesure : authentification forte.
• T - Tampering : modification non autorisée de données. Contre-mesure : intégrité des données, signatures.
• R - Repudiation : nier avoir effectué une action. Contre-mesure : logs d'audit non répudiables.
• I - Information Disclosure : fuite de données sensibles. Contre-mesure : chiffrement, contrôle d'accès.
• D - Denial of Service : rendre le service indisponible. Contre-mesure : rate limiting, scalabilité.
• E - Elevation of Privilege : accès non autorisé à des fonctions élevées. Contre-mesure : moindre privilège, RBAC.

Process STRIDE en pratique

• Créer un diagramme de flux de données (DFD) de la feature : acteurs, processus, datastores, flux de données
• Identifier les limites de confiance (trust boundaries) entre les composants
• Pour chaque flux traversant une limite de confiance, appliquer la grille STRIDE
• Documenter les menaces identifiées avec leur probabilité et impact
• Définir les contre-mesures et les stories de sécurité à ajouter au backlog
• Outils : Microsoft Threat Modeling Tool (gratuit), OWASP Threat Dragon, draw.io

L'analyse statique (SAST — Static Application Security Testing) analyse le code source sans l'exécuter pour détecter des patterns vulnérables.

• Semgrep : outil SAST open source multi-langages avec des règles communautaires pour détecter les injections SQL, XSS, désérialisations non sécurisées, et OWASP Top 10. Rapide, faible taux de faux positifs, intégrable dans la CI/CD.
• SonarQube / SonarCloud : plateforme d'analyse statique complète avec qualité de code + sécurité. Quality Gates pour bloquer les builds avec des "Security Hotspots" non résolus.
• CodeQL (GitHub Advanced Security) : analyse sémantique du code permettant de détecter des vulnérabilités complexes en traitant le code comme une base de données requêtable. Intégré dans GitHub Actions.
• Bandit (Python) / Gosec (Go) / ESLint-plugin-security (JavaScript) : analyseurs spécifiques aux langages pour les vulnérabilités communes.

Intégration SAST dans les IDE

• Plugin Semgrep ou SonarLint dans VS Code / IntelliJ pour détecter les vulnérabilités en temps réel pendant le développement
• Pre-commit hooks : exécuter un scan SAST rapide avant chaque commit (Semgrep en mode rapide)
• GitHub Actions / GitLab CI : scan SAST complet sur chaque PR avec annotations dans la code review
• Principe : détecter le plus tôt possible — "shift left security"

Software Composition Analysis (SCA)

• Snyk : détection des CVE dans les dépendances (npm, pip, Maven, Go modules) avec des corrections automatiques via PRs. Intégration GitHub/GitLab/Azure DevOps native.
• OWASP Dependency-Check : outil open source qui analyse les dépendances contre la NVD (National Vulnerability Database). Plugin Maven, Gradle, et CLI.
• Dependabot (GitHub) : mises à jour automatiques des dépendances vulnérables avec PRs. Gratuit pour les repos GitHub.
• SBOM generation : générer un Software Bill of Materials (SPDX ou CycloneDX) à chaque build pour tracer toutes les dépendances et versions exactes.

Secrets Scanning

• Gitleaks : outil open source qui scanne l'historique Git complet pour détecter les secrets commités (clés AWS, tokens GitHub, API keys, passwords). Utilisable en pre-commit hook et en CI/CD.
• TruffleHog : scanne Git, S3, GitHub, GitLab, CircleCI pour les secrets exposés. Version Enterprise avec vérification active des secrets (teste si le secret est encore valide).
• GitHub Secret Scanning : protection native GitHub qui détecte automatiquement les secrets connus dans les repos et les bloque avant le push.
• Rotation immédiate : quand un secret est détecté dans Git, le considérer comme compromis et le révoquer immédiatement — même si le commit est supprimé, il reste dans l'historique et peut avoir été forké.

• DAST (Dynamic Application Security Testing) : tests d'une application en cours d'exécution. OWASP ZAP (gratuit) ou Burp Suite Enterprise pour scanner automatiquement les endpoints HTTP, détecter les injections, XSS, et mauvaises configurations.
• ZAP dans la CI/CD : OWASP ZAP en mode automatisé dans les pipelines pour les tests de régression de sécurité — idéal pour les environnements de staging.
• Pentest à chaque release majeure : faire appel à des pentesters externes (PASSI) pour les fonctionnalités critiques (paiement, authentification, accès données sensibles) avant chaque version majeure.
• Bug Bounty : programme de divulgation responsable via HackerOne ou Bugcrowd pour les applications publiques — complément aux tests internes.

• Security Champions : désigner un développeur référent sécurité par équipe (Security Champion) — pont entre l'équipe sécurité et les développeurs, pas un expert mais un relais formé.
• Formation OWASP Top 10 : formation obligatoire aux 10 vulnérabilités les plus critiques pour tous les développeurs, avec des labs pratiques (DVWA, WebGoat, HackTheBox).
• Code review sécurité : checklist de sécurité incluse dans le processus de code review (validation des entrées, cryptographie, gestion des erreurs, logs sensibles).
• Secure coding standards : guidelines spécifiques au langage (OWASP Cheat Sheet Series) intégrées dans les standards de développement de l'équipe.
• Métriques SSDLC : mesurer le temps moyen de correction des vulnérabilités, le taux de faux positifs des outils SAST, le nombre de vulnérabilités détectées par phase.