Tests de sécurité automatisés

Une faille critique publiée aujourd'hui a une probabilité médiane d'être exploitée en moins de cinq jours, selon les rapports de vulnérabilités 2025-2026 (Edgescan, Synack). Pourtant, le délai moyen de remédiation d'une faille critique dépasse encore 50 jours dans la plupart des organisations. Ce décalage entre la vitesse d'exploitation et la vitesse de correction est le problème que les tests de sécurité automatisés cherchent à résorber.

Cette page s'adresse aux équipes qui veulent comprendre les quatre familles de tests de sécurité, SAST, DAST, SCA et fuzzing, et savoir quand chacune s'intègre dans le cycle de développement. Vous repartirez avec une grille de lecture pour choisir les bons outils et les orchestrer dans un pipeline CI/CD, sans opposer vélocité et sécurité.

Ce que vous allez apprendre

Distinguer les quatre piliers des tests de sécurité (SAST, DAST, SCA, fuzzing) et leurs angles morts respectifs
Choisir le bon type de test selon la phase du cycle de développement
Prioriser les vulnérabilités détectées avec des critères objectifs (CVSS, EPSS, KEV)
Intégrer ces tests dans un pipeline CI/CD sans ralentir les livraisons
Éviter les pièges classiques (faux positifs, scans qui bloquent tout, angle mort sur la supply chain)

Les quatre piliers des tests de sécurité

L'analyse de sécurité repose sur quatre approches complémentaires. Chacune détecte des catégories de vulnérabilités différentes, à des moments différents du cycle de développement. Comprendre leurs forces et limites est essentiel pour construire une stratégie efficace.

Approche	Cible	Moment	Ce qu'elle détecte	Limites
SAST	Code source	Développement	Injections, secrets, patterns dangereux	Faux positifs, contexte d'exécution ignoré
DAST	Application déployée	Staging/Prod	Failles exploitables, misconfigurations	Couverture limitée, lent
SCA	Dépendances	Build	CVE dans les bibliothèques tierces	Ne détecte que les vulnérabilités connues
Fuzzing	Entrées/APIs	Tests	Comportements inattendus, crashs, edge cases	Gourmand en ressources

Ces catégories ne sont pas figées : le référentiel OWASP Top 10:2025, publié début 2026 en remplacement de l'édition 2021, illustre ce mouvement. Il introduit deux catégories inédites, les échecs de la chaîne d'approvisionnement logicielle et la mauvaise gestion des conditions exceptionnelles, et fusionne le SSRF dans le contrôle d'accès défaillant. Voir OWASP Top 10 appliqué au DevSecOps pour le détail des dix catégories et leur cartographie avec vos outils.

SAST : analyse statique du code source

Le SAST (Static Application Security Testing) analyse le code sans l'exécuter. Il parse le code source, construit un modèle abstrait et recherche des patterns connus de vulnérabilités.

Ce que SAST détecte

Le SAST excelle à trouver certaines catégories de problèmes. Le point commun : ce sont des motifs reconnaissables directement dans le texte du code, sans avoir besoin d'exécuter l'application pour les repérer.

Catégorie	Exemples	Pourquoi SAST est efficace
Injections	SQL, XSS, Command injection	Patterns reconnaissables : concaténation de strings avec input utilisateur
Secrets hardcodés	API keys, tokens, passwords	Patterns regex : `password = "..."`, formats connus (AWS, GitHub)
Crypto faible	MD5, SHA1, DES	Appels à des fonctions connues comme obsolètes
Mauvaises pratiques	`eval()`, `exec()`, désérialisation non sécurisée	Fonctions spécifiques blacklistées

Limites du SAST

Le SAST a des angles morts importants :

Contexte d'exécution : Le code user_input = request.get('name') suivi de db.query(f"SELECT * FROM users WHERE name = '{user_input}'") est une injection SQL évidente. Mais si l'input est validé trois fichiers plus loin, SAST peut ne pas faire le lien.
Faux positifs : Sans contexte, SAST signale des problèmes qui n'en sont pas. Un eval() utilisé sur une constante n'est pas dangereux.
Logique métier : SAST ne comprend pas que "un utilisateur ne devrait pas pouvoir voir les commandes d'un autre".

Intégration dans le cycle

Le SAST s'intègre à plusieurs niveaux du cycle de développement :

Point d'intégration	Avantage	Inconvénient
IDE (temps réel)	Feedback immédiat, contexte frais	Peut ralentir l'éditeur
Pre-commit	Bloque avant le push	Peut frustrer si trop strict
CI (Pull Request)	Revue systématique	Feedback plus tardif
Scheduled (nightly)	Analyse approfondie	Détection retardée

DAST : tests dynamiques en exécution

Le DAST (Dynamic Application Security Testing) teste l'application en cours d'exécution. Il simule les actions d'un attaquant : envoie des requêtes malformées, tente des injections, explore les endpoints.

Ce que DAST détecte

Le DAST trouve ce que le SAST manque. Ces failles ont un point commun : elles n'existent que lorsque l'application tourne réellement, avec sa configuration et son environnement d'exécution, ce qu'une simple lecture du code ne peut pas révéler.

Catégorie	Exemples	Pourquoi DAST est nécessaire
Injections exploitables	SQL, XSS qui passent vraiment	Valide que la faille est réellement exploitable
Misconfigurations	Headers manquants, CORS permissif	Configuration runtime, pas dans le code
Authentification faible	Session fixation, tokens prédictibles	Comportement runtime
Fuites d'information	Stack traces, versions exposées	Réponses HTTP réelles

Limites du DAST

Le DAST a aussi ses angles morts :

Couverture : Il ne teste que ce qu'il peut atteindre. Un endpoint non documenté ou une fonctionnalité derrière une authentification complexe peut être ignoré.
Lenteur : Contrairement au SAST qui analyse du texte, le DAST envoie des requêtes réelles. Un scan complet peut prendre des heures.
Environnement : Il faut une application déployée et fonctionnelle. Impossible de tester du code non encore intégré.

Quand utiliser DAST

Le DAST s'utilise plus tard dans le cycle que le SAST. Une tendance récente mérite d'être connue : des outils DAST nouvelle génération analysent désormais la spécification OpenAPI d'une API pour déduire son usage prévu, et testent la logique métier plutôt que de se limiter à une liste d'endpoints devinés. Cela réduit la configuration manuelle, mais ne remplace pas un pentest humain sur les scénarios les plus critiques.

Environnement	Usage	Fréquence
Développement local	Tests ciblés sur nouvelles fonctionnalités	À la demande
Staging/Pre-prod	Scan complet avant release	Chaque release candidate
Production	Monitoring continu, pentest	Hebdomadaire/mensuel

SCA : analyse des dépendances

Le SCA (Software Composition Analysis) analyse les bibliothèques tierces utilisées par votre application. Il compare vos dépendances aux bases de données de vulnérabilités connues (CVE). C'est un pilier critique du DevSecOps moderne, et c'est aussi celui qui a le plus évolué ces deux dernières années sous la pression des attaques de chaîne d'approvisionnement.

Pourquoi SCA est critique

Le code que vous écrivez représente souvent moins de 20 % de votre application. Le reste vient de dépendances : frameworks, bibliothèques, utilitaires. Chaque dépendance est un vecteur potentiel de vulnérabilités, et le rythme des incidents s'est nettement accéléré.

Le rapport 2026 de Sonatype recense plus de 454 000 nouveaux paquets open source malveillants publiés en 2025, portant le total cumulé bloqué à plus de 1,2 million, soit une hausse de 75 % sur un an. Quelques incidents marquants illustrent cette dynamique :

Log4Shell (2021) : vulnérabilité dans Log4j, présente dans des millions d'applications Java.
Spring4Shell (2022) : faille dans Spring Framework, framework Java le plus utilisé.
Polyfill.io (2024) : supply chain attack via un CDN JavaScript largement utilisé.
Shai-Hulud (septembre 2025) : ver auto-réplicant ayant compromis plusieurs centaines de paquets npm en quelques jours, en volant des tokens de publication pour se propager de dépôt en dépôt sans même nécessiter de serveur de commande et contrôle.
Compromission d'axios (mars 2026) : un seul compte mainteneur compromis a transformé cette bibliothèque HTTP très populaire, plus de 100 millions de téléchargements par semaine, en vecteur de diffusion d'un cheval de Troie d'accès distant pendant environ trois heures.

Ce dernier point mérite un détour : même les outils de sécurité ne sont pas à l'abri. Début 2026, le scanner Trivy a lui-même été compromis à deux reprises en trois semaines, des attaquants ayant réutilisé des identifiants volés pour injecter du code malveillant dans des releases, dans l'action GitHub trivy-action et dans des images Docker officielles, avec exfiltration de secrets vers un domaine de commande et contrôle typosquatté. La leçon : épingler les versions (par tag précis, idéalement par digest) et surveiller les mainteneurs s'applique aussi aux outils qui servent à détecter les vulnérabilités, pas seulement aux dépendances applicatives. Voir Sécurité de la supply chain logicielle pour approfondir ces mécanismes de défense.

Ce que SCA détecte

Au-delà du simple constat « cette bibliothèque a une faille connue », un bon outil SCA remonte plusieurs informations complémentaires qui servent ensuite à prioriser le patch : la sévérité technique, la probabilité réelle d'exploitation, la conformité de licence et la profondeur de la dépendance dans votre arborescence.

Information	Description	Utilité
CVE	Vulnérabilités publiées avec identifiant unique	Identifier les failles connues
CVSS	Score de sévérité (0-10)	Prioriser par criticité
EPSS	Probabilité d'exploitation sous 30 jours (v4, depuis mars 2025)	Prioriser par risque réel
Licence	Type de licence (MIT, GPL, propriétaire)	Conformité juridique
Dépendances transitives	Dépendances de vos dépendances	Visibilité sur la supply chain

Stratégie de priorisation

Toutes les CVE ne se valent pas. Une stratégie efficace priorise selon plusieurs critères, pour éviter que l'équipe passe autant de temps sur une faille théorique que sur une faille activement exploitée. Voir aussi Gestion des vulnérabilités CVE, du triage au patch pour un processus détaillé.

Priorité	Critères	Action
P0 - Critique	CVSS ≥ 9.0 ET (EPSS > 10 % OU KEV)	Patch immédiat, bloquer le déploiement
P1 - Haute	CVSS ≥ 7.0 ET dépendance directe	Patch sous 7 jours
P2 - Moyenne	CVSS ≥ 4.0 OU dépendance transitive critique	Patch sous 30 jours
P3 - Basse	CVSS < 4.0, pas d'exploit connu	Inclure dans maintenance régulière

Fuzzing : tests par injection de données aléatoires

Le fuzzing (ou fuzz testing) consiste à envoyer des données aléatoires ou semi-aléatoires à une application pour provoquer des comportements inattendus : crashs, fuites mémoire, exceptions non gérées.

Pourquoi fuzzer

Le fuzzing trouve ce que les autres méthodes manquent :

Edge cases : Que se passe-t-il avec une string de 10 millions de caractères ? Un entier négatif là où on attend un positif ?
Vulnérabilités inconnues : Contrairement au SAST/SCA qui cherchent des patterns connus, le fuzzing peut découvrir des vulnérabilités nouvelles (0-days).
Robustesse : Au-delà de la sécurité, le fuzzing améliore la qualité générale en trouvant des bugs de stabilité.

Types de fuzzing

Le fuzzing a lui aussi évolué : au-delà des générateurs purement aléatoires, une génération d'outils guidés par l'IA propose désormais des mutations construites à partir d'une compréhension sémantique de la cible, ce qui permet de découvrir des classes de vulnérabilités que les seules métriques de couverture de code manquent.

Type	Description	Exemple
Dumb fuzzing	Données totalement aléatoires	Bytes aléatoires envoyés à un parser
Smart fuzzing	Données aléatoires respectant un format	JSON valide avec valeurs aléatoires
Coverage-guided	Adapte les inputs pour explorer plus de code	AFL, libFuzzer
API fuzzing	Teste les endpoints REST/GraphQL en s'appuyant sur les specs OpenAPI	Burp, RESTler

Quand utiliser le fuzzing

Le fuzzing est gourmand en ressources. Il est particulièrement pertinent pour :

Code critique : Parsers, cryptographie, validation d'entrées
Bibliothèques partagées : Code utilisé par de nombreux projets
Avant release majeure : Validation approfondie
Nightly builds : En parallèle du développement

Intégration dans le pipeline CI/CD

La question n'est pas si intégrer ces tests, mais comment les orchestrer efficacement. Une intégration mal pensée génère plus de friction que de sécurité : bloquer chaque commit avec un scan complet ralentit l'équipe, alors qu'un scan trop léger laisse passer l'essentiel. Voici une stratégie éprouvée, détaillée dans Pipeline CI/CD sécurisé :

Pre-commit : détection de secrets

Premier rempart, le plus à gauche. Bloque les commits contenant des secrets avant qu'ils n'atteignent le dépôt.
.pre-commit-config.yaml
```
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.28.0
    hooks:
      - id: gitleaks
```

CI (Pull Request) : SAST + SCA

Chaque PR est analysée automatiquement. Les vulnérabilités critiques bloquent le merge.

# GitHub Actions
security-scan:
  runs-on: ubuntu-latest
  permissions:
    contents: read
  steps:
    - uses: actions/checkout@v4
      with:
        persist-credentials: false

    # SAST avec Semgrep
    - name: Run Semgrep
      uses: semgrep/semgrep-action@v1
      with:
        config: p/security-audit

    # SCA avec Trivy
    - name: Run Trivy
      run: |
        trivy fs --severity HIGH,CRITICAL --exit-code 1 .

Staging : DAST

Une fois l'application déployée en staging, les tests dynamiques peuvent s'exécuter.

dast-scan:
  needs: deploy-staging
  runs-on: ubuntu-latest
  steps:
    - name: DAST scan
      run: |
        nuclei -u https://staging.example.com -t cves/ -severity critical,high

Nightly : fuzzing et scans approfondis

Les analyses longues s'exécutent la nuit, sans bloquer le développement.

on:
  schedule:
    - cron: '0 2 * * *'  # Tous les jours à 2h

jobs:
  deep-scan:
    # Analyse complète, tous les seuils

Métriques à suivre

Mesurer l'efficacité de vos tests de sécurité évite de confondre activité (nombre de scans lancés) et résultat (vulnérabilités réellement corrigées). Les rapports 2025-2026 (Edgescan, Synack) situent le délai moyen de remédiation des failles critiques autour de 55 jours, et près d'un tiers des vulnérabilités restent ouvertes plus de 180 jours ; ce sont les seuils à challenger avec les métriques suivantes. Voir aussi KPIs sécurité DevSecOps pour un tableau de bord complet.

Métrique	Description	Cible
MTTD (Mean Time To Detect)	Délai entre introduction et détection	< 24h pour critique
MTTR (Mean Time To Remediate)	Délai entre détection et correction	< 7 jours pour critique
Taux de faux positifs	Alertes non pertinentes	< 10 %
Couverture	% du code analysé par SAST	> 90 %
Dette de vulnérabilités	Vulnérabilités connues non corrigées	Tendance descendante

À retenir

SAST : analyse le code source, rapide, beaucoup de faux positifs, adapté au développement.
DAST : teste l'application réelle, lent, peu de faux positifs, adapté au staging/prod.
SCA : analyse les dépendances, critique pour la supply chain, adapté au CI/CD.
Fuzzing : trouve les edge cases et 0-days, adapté aux phases nightly/release.
Combinaison : aucune approche n'est suffisante seule.
OWASP Top 10:2025 a introduit deux catégories inédites, échecs de la supply chain et mauvaise gestion des conditions exceptionnelles : vos règles SAST/DAST doivent suivre cette évolution.
Même les scanners de sécurité peuvent être compromis (cas Trivy en 2026) : épingler les versions et vérifier les mainteneurs reste indispensable, y compris pour vos propres outils.

FAQ : questions fréquentes

Qu'est-ce qu'un test de sécurité automatisé ?

Un test de securite automatise est une analyse executee sans intervention humaine pour detecter des vulnerabilites dans le code, l'application ou ses dependances. Les quatre familles principales sont SAST, DAST, SCA et fuzzing, chacune couvrant une phase differente du cycle de developpement.

Quelle est la différence entre SAST et DAST ?

Le SAST analyse le code source sans l'executer, au moment du developpement, et detecte des patterns comme les injections ou les secrets hardcodes. Le DAST teste l'application deployee et en cours d'execution, plus tard dans le cycle, pour valider que les failles sont reellement exploitables.

Qu'est-ce que le SCA en sécurité applicative ?

Le SCA, Software Composition Analysis, analyse les bibliotheques tierces d'une application et les compare aux bases de CVE connues. Il est critique car le code propre represente souvent moins de 20 pour cent d'une application, le reste venant de dependances.

Comment prioriser les vulnérabilités détectées avec CVSS, EPSS et KEV ?

Le CVSS mesure la severite technique d'une faille sur 10, l'EPSS estime sa probabilite d'exploitation sous 30 jours, et le catalogue KEV de la CISA liste les vulnerabilites deja exploitees activement. Une faille critique combine CVSS eleve et EPSS eleve ou presence dans KEV, elle exige un patch immediat.

Pourquoi utiliser le fuzzing en plus du SAST et du DAST ?

Le fuzzing envoie des donnees aleatoires ou semi-aleatoires a une application pour provoquer des comportements inattendus. Contrairement au SAST et au SCA qui cherchent des patterns connus, il peut decouvrir des vulnerabilites inconnues, y compris des failles de type 0-day.

Comment intégrer les tests de sécurité dans un pipeline CI/CD ?

L'integration suit une progression en quatre etapes : detection de secrets en pre-commit, SAST et SCA a chaque pull request, DAST une fois l'application deployee en staging, puis fuzzing et scans approfondis en tache planifiee la nuit pour ne pas ralentir les livraisons.

Mettre en pratique

Shift-left Déplacer les tests de sécurité au plus tôt dans le cycle.

Pipeline sécurisé Construire un pipeline CI/CD avec security gates intégrés.

OWASP Top 10 appliqué au DevSecOps Les dix catégories de risques, édition 2025, et comment les cartographier avec vos scanners.

Gestion des vulnérabilités CVE Du triage au patch : processus complet de gestion des CVE.

Guides d'implémentation SAST, DAST, SCA : guides pas à pas avec les outils.