Points clés
- Les tests de sécurité couvrent un spectre large : SAST, DAST, IAST, SCA, fuzzing, tests d'intrusion — chaque approche détecte des catégories différentes de vulnérabilités.
- Les tests de sécurité automatisés dans le CI/CD fournissent un feedback continu mais ne remplacent pas les tests manuels (threat modeling, revues d'architecture, pentests).
- Le taux de faux positifs est le paramètre critique de l'efficacité opérationnelle des scanners — un outil avec trop de faux positifs sera ignoré.
- Les tests de sécurité doivent couvrir à la fois l'application et son infrastructure (configuration cloud, permissions IAM, règles réseau).
La taxonomie des tests de sécurité applicative
Les tests de sécurité applicative couvrent un spectre de techniques complémentaires. Le SAST (Static Application Security Testing) analyse le code source sans l'exécuter — il détecte des patterns de code vulnérable (injections, gestion incorrecte des données sensibles, appels à des fonctions dangereuses) mais peut générer des faux positifs et ne détecte pas les vulnérabilités liées à la configuration de l'environnement. Le DAST (Dynamic Application Security Testing) teste l'application en cours d'exécution via des requêtes automatisées — il détecte les vulnérabilités qui ne sont visibles qu'au runtime (XSS, CSRF, problèmes de gestion de session) mais nécessite un environnement de test accessible. L'IAST (Interactive Application Security Testing) combine les deux approches en instrumentant l'application pendant son exécution pour détecter les vulnérabilités lors des tests fonctionnels.
Le SCA (Software Composition Analysis) évalue les vulnérabilités connues dans les dépendances tierces. Le fuzzing soumet l'application à des entrées aléatoires ou semi-aléatoires pour identifier des comportements inattendus. Les tests d'intrusion (pentests) combinent des techniques automatisées et manuelles pour tester la résistance de l'application à des attaques réalistes.
Tests automatisés et tests manuels : complémentarité
Les tests automatisés intégrés dans le pipeline CI/CD fournissent un feedback rapide et continu — chaque commit déclenche un scan SAST, chaque nuit un scan DAST sur l'environnement de staging. Ils sont indispensables à l'échelle mais présentent des limites structurelles : ils ne détectent que les patterns connus, sont moins efficaces sur les vulnérabilités logiques (une autorisation incorrecte qui respecte syntaxiquement les appels à l'API de contrôle d'accès), et ne peuvent pas évaluer l'architecture de sécurité globale.
Les tests manuels (threat modeling réalisé par des experts, revues d'architecture de sécurité, tests d'intrusion par des pentesters expérimentés) détectent les vulnérabilités complexes, les problèmes de logique d'autorisation, et les faiblesses architecturales que les outils automatiques manquent systématiquement. La combinaison des deux approches est nécessaire — les tests automatisés assurent la couverture continue, les tests manuels assurent la profondeur.
La gestion du ratio signal/bruit
L'obstacle pratique le plus fréquent à l'adoption des tests de sécurité automatisés est le volume de faux positifs qu'ils génèrent. Un scanner SAST mal configuré peut produire des centaines d'alertes par jour, dont la majorité sont des faux positifs ou des vulnérabilités de faible criticité. Les équipes de développement, submergées par ces alertes, finissent par les ignorer — et les vraies vulnérabilités se perdent dans le bruit.
La configuration des règles et des seuils de qualité (quality gates) est donc un travail initial critique. Il faut commencer par activer uniquement les règles les plus fiables (faible taux de faux positifs), définir des seuils d'acceptation réalistes (bloquer le pipeline uniquement pour les vulnérabilités critiques confirmées), et itérer progressivement pour réduire le bruit tout en augmentant la couverture.
Tester l'infrastructure applicative, pas seulement le code
Une erreur fréquente est de concentrer les tests de sécurité sur le code applicatif en négligeant l'infrastructure sur laquelle l'application s'exécute. La configuration des services cloud (permissions IAM, règles de sécurité des groupes, paramètres de chiffrement), les règles de pare-feu, les configurations des serveurs web (headers de sécurité, TLS), et les paramètres des bases de données ont un impact de sécurité aussi important que le code lui-même — et les vulnerabilités de configuration (misconfigurations) sont aujourd'hui l'une des principales causes d'incidents cloud.
Des outils d'IaC scanning (Checkov, tfsec, KICS pour Terraform, CloudFormation, Kubernetes) permettent d'intégrer la vérification des configurations d'infrastructure dans le pipeline CI/CD, en traitant la configuration de l'infrastructure comme du code soumis aux mêmes contrôles de qualité.