SDLC sécurisé, outils SAST et DAST

Le cycle de vie sécurisé du développement logiciel (SSDLC) intègre les activités de sécurité à chaque phase du développement logiciel : des exigences à la conception, au codage, aux tests, au déploiement et à la maintenance. Le SDLC traditionnel traite la sécurité comme une étape de contrôle finale, ce qui est coûteux et inefficace. La philosophie du SDLC sécurisé consiste à trouver et corriger les vulnérabilités le plus tôt possible, car les défauts détectés pendant la conception coûtent bien moins cher à corriger que ceux découverts en production.

Déplacer la sécurité vers la gauche signifie intégrer la sécurité plus tôt (vers la gauche sur la chronologie du développement) plutôt que de l’ajouter à la fin. En pratique, cela consiste à inclure les exigences de sécurité dans les récits utilisateur, à réaliser une modélisation des menaces pendant la conception, à effectuer une revue du code et du SAST pendant le développement, et à exécuter le DAST avant la mise en production. Les équipes qui déplacent la sécurité vers la gauche découvrent les vulnérabilités au moment où elles sont les moins coûteuses à corriger : pendant le développement, et non en production.

La modélisation des menaces identifie et documente systématiquement les menaces de sécurité pendant la phase de conception. Le modèle STRIDE classe les menaces en : Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service et Elevation of Privilege. PASTA (Processus de simulation d’attaque et d’analyse des menaces) est une méthodologie centrée sur les risques qui simule les objectifs d’un attaquant. Les modèles de menaces produisent des mesures d’atténuation hiérarchisées avant même l’écriture de la première ligne de code.

Le SAST (tests en boîte blanche) analyse le code source, le bytecode ou les fichiers binaires sans exécuter l’application, à la recherche de modèles de codage associés à des vulnérabilités connues. Les outils SAST peuvent analyser rapidement l’intégralité de la base de code et signaler des problèmes tels que des identifiants codés en dur, des points d’injection SQL et une désérialisation non sécurisée. Ils s’exécutent dans l’IDE ou le pipeline d’intégration continue et indiquent les problèmes avec les numéros de fichier et de ligne, ce qui facilite leur correction.

Une limite importante du SAST est sa tendance à produire des faux positifs : il signale du code comme vulnérable alors qu’il est en réalité sûr. Cette lassitude liée aux alertes amène les développeurs à écarter les résultats sans les examiner. Les outils SAST ne peuvent pas non plus détecter les problèmes de configuration à l’exécution, les failles d’authentification qui dépendent du comportement à l’exécution, ni les vulnérabilités des appels d’API tierces. Le SAST est plus efficace lorsqu’il est associé à une formation des développeurs afin que les résultats soient correctement évalués.

Le DAST (tests en boîte noire) teste une application en cours d’exécution en envoyant des charges utiles d’attaque à ses points de terminaison HTTP et en analysant les réponses à la recherche d’indicateurs de vulnérabilité. Le DAST ne nécessite pas l’accès au code source : il teste l’application comme le ferait un attaquant. Il est particulièrement efficace pour détecter les problèmes à l’exécution, comme le contournement de l’authentification, les XSS réfléchies dans les réponses et les erreurs de configuration du Server. Les outils DAST comprennent OWASP ZAP, Burp Suite et Netsparker.

Le SAST et le DAST sont complémentaires plutôt que concurrents. Le SAST détecte tôt les problèmes au niveau du code et s’intègre à l’IDE, mais il n’a aucune visibilité sur le comportement à l’exécution. Le DAST détecte les vulnérabilités à l’exécution et ne nécessite aucun code source, mais il ne peut pas analyser les chemins de code qui ne sont pas déclenchés par ses sondes automatisées. Utiliser les deux ensemble — le SAST dans le pipeline d’intégration continue et le DAST contre un environnement de préproduction — maximise la couverture des vulnérabilités dans l’ensemble du SDLC.

Le IAST combine des aspects du SAST et du DAST en instrumentant l’application à l’exécution. Un agent IAST s’exécute dans l’application (sur le Server) et observe l’exécution du code tandis que le trafic de test la traverse. Il peut établir une corrélation entre une entrée utilisateur contaminée, les chemins de code et les points sensibles, afin de détecter les vulnérabilités avec moins de faux positifs qu’un SAST seul. L’IAST est particulièrement efficace dans les applications Java et .NET et s’intègre naturellement aux exécutions de tests fonctionnels.

L’analyse de la composition logicielle (SCA) identifie les bibliothèques open source et les dépendances tierces d’une application, puis les compare aux bases de données de vulnérabilités (NVD, OSV). Comme les applications modernes peuvent intégrer des centaines de dépendances — dont beaucoup de manière transitive — des outils SCA tels que OWASP Dependency-Check, Snyk et Renovate sont essentiels pour détecter les CVEs connues avant que des attaquants ne les exploitent dans votre chaîne d’approvisionnement.

L’intégration des outils de sécurité dans les pipelines CI/CD garantit qu’aucun code n’atteint la production sans franchir les contrôles de sécurité. Un pipeline DevSecOps typique exécute : le SAST à chaque validation, le SCA lors des modifications de dépendances, l’analyse des images de Container avant leur envoi vers le registre, l’analyse de l’IaC pour Terraform/CloudFormation, et le DAST contre un déploiement de préproduction. Les contrôles de sécurité échoués bloquent la compilation et imposent une culture où la sécurité est activée par défaut.

Les outils automatisés ne peuvent pas remplacer une revue du code humaine axée sur la logique de sécurité. La revue par les pairs doit vérifier que : les contrôles d’authentification et d’autorisation sont placés au bon endroit, la gestion des erreurs ne divulgue pas d’informations sensibles, les fonctions cryptographiques utilisent des algorithmes et des paramètres approuvés, et la logique métier ne peut pas être contournée. Les référents sécurité au sein des équipes de développement — des développeurs formés à la sécurité — font le lien entre l’équipe de sécurité et les équipes d’ingénierie.

Testez votre compréhension des concepts de CompTIA Security+ (SY0-701) présentés dans cette leçon.

Dans cette leçon, vous avez appris que : le SDLC sécurisé intègre la sécurité à toutes les phases du développement au lieu de l’ajouter à la fin, le SAST analyse le code sans l’exécuter tandis que le DAST teste les applications en cours d’exécution, et le SCA identifie les dépendances open source vulnérables et les contrôles de sécurité CI/CD appliquent automatiquement les résultats. Nous allons ensuite étudier les services d’annuaire avec LDAP et Active Directory.