DevSecOps

SAST vs DAST vs IAST — approches de test applicatif

Les trois approches complémentaires de test de sécurité applicatif s'appliquent à différentes phases du cycle. SAST (Static Application Security Testing) analyse le code source sans l'exécuter — détecte les vulnérabilités comme les injections SQL, les XSS, et les mauvaises pratiques cryptographiques directement dans le code. Avantage : feedback très tôt (IDE ou PR), pas besoin d'environnement d'exécution. Inconvénient : nombreux faux positifs, ne détecte pas les vulnérabilités de configuration. DAST (Dynamic Application Security Testing) teste l'application en cours d'exécution en envoyant des requêtes malformées — OWASP ZAP, Burp Suite. Avantage : détecte des vulnérabilités réelles de l'application déployée (SQLi, XSS, IDOR). Inconvénient : plus tardif dans le cycle, ne voit pas le code. IAST (Interactive AST) instrumente l'application en cours d'exécution et observe son comportement de l'intérieur — combine les avantages du SAST (visibilité du code) et du DAST (comportement runtime). Moins répandu mais très précis. Une stratégie DevSecOps complète combine idéalement les trois.

Secrets Management dans le CI/CD

La fuite de secrets (credentials, API keys, certificats) dans le code source est l'une des vulnérabilités les plus courantes dans les environnements DevOps. Des études montrent que des milliers de secrets valides sont exposés chaque jour sur GitHub. GitGuardian monitore les repos publics et privés pour détecter les secrets en temps réel. Les bonnes pratiques de gestion des secrets dans le CI/CD : ne jamais stocker de secrets dans le code source ou les configurations versionnées, utiliser les systèmes de secrets management (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GitHub Actions Secrets, GitLab CI Variables chiffrées) pour injecter les secrets au runtime. Les secrets doivent être rotés régulièrement et avoir une durée de vie limitée (secrets éphémères via Vault Dynamic Secrets). La détection de secrets dans les commits (pre-commit hooks via detect-secrets ou gitleaks) est la première ligne de défense — bloquer avant que le secret ne soit poussé dans l'historique git.

Threat Modeling — sécurité dès la conception

Le Threat Modeling (modélisation des menaces) est la pratique qui consiste à identifier et analyser les menaces de sécurité dès la phase de conception d'un système ou d'une feature, avant qu'une seule ligne de code ne soit écrite. STRIDE (Microsoft) est le framework de threat modeling le plus utilisé : Spoofing (usurpation), Tampering (altération), Repudiation (déni), Information Disclosure (fuite d'informations), Denial of Service (déni de service), Elevation of Privilege (élévation de privilèges) — pour chaque composant du système, on évalue les risques selon ces 6 catégories. PASTA (Process for Attack Simulation and Threat Analysis) est une alternative plus formelle utilisée pour des systèmes complexes. Des outils comme OWASP Threat Dragon, Microsoft Threat Modeling Tool, et IriusRisk facilitent le processus de threat modeling graphique. Intégrer le threat modeling dans les "Definition of Ready" (avant le sprint) garantit que les features sont conçues avec la sécurité en tête.