Tests de sécurité automatisés

L'exploitation d'une vulnérabilité est devenue le premier vecteur d'intrusion, devant le vol d'identifiants. Le Verizon DBIR 2026, qui couvre plus de 31 000 incidents et 22 000 brèches confirmées dans 145 pays entre novembre 2024 et octobre 2025, la mesure à 31 % des brèches contre 13 % pour l'abus d'identifiants : c'est la première bascule en dix-neuf éditions. En face, 26 % seulement des vulnérabilités du catalogue CISA KEV ont été entièrement corrigées en 2025, contre 38 % l'année précédente, et la médiane de résolution complète est montée de 32 à 43 jours. Ce décalage entre vitesse d'exploitation et 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 familles les plus répandues (SAST, DAST, SCA, fuzzing) et leurs angles morts respectifs
Identifier la classe de défauts qu'aucun scanner ne détecte, et ce qu'il faut mettre en face
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)

SAST, DAST, SCA et fuzzing : quelles différences ?

Ces quatre familles se distinguent par ce qu'elles lisent : le texte du code, l'arbre des dépendances, le service en marche, ou des entrées fabriquées. Tout le reste en découle, à commencer par leurs angles morts. Ce sont les plus répandues, pas une liste exhaustive : on les présente souvent comme « les quatre piliers », ce qui laisse croire à une couverture complète.

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.

Les familles que cette liste laisse de côté

Présenter SAST, DAST, SCA et fuzzing comme « les quatre piliers » revient à déclarer le sujet couvert. Ce n'est pas le cas : les guides de l'OWASP recensent plusieurs autres familles, de l'analyse de secrets à la modélisation de menaces, qui répondent chacune à un besoin que les quatre premières laissent entier. Deux références font autorité sur ce périmètre, l'OWASP DevSecOps Guideline pour l'outillage du pipeline, et le Web Security Testing Guide pour la méthode de test applicatif.

Famille	Ce qu'elle apporte en plus
Analyse de secrets	Lit l'historique du dépôt, pas seulement les fichiers courants : une clé retirée hier y est toujours
IAST	Instrumente l'application pendant ses tests fonctionnels, donc observe le flux réel de données au lieu de le déduire
Analyse d'images de conteneurs	Couvre le système de base et les binaires installés, que l'arbre des dépendances applicatives ignore
Analyse de vulnérabilités d'infrastructure	Balaie les machines et les services exposés, y compris ceux que personne n'a déclarés : l'hôte oublié ne figure dans aucun dépôt
Analyse d'IaC	Lit Terraform, Kubernetes et les fichiers de configuration, où vivent les erreurs d'exposition réseau et de droits
Modélisation de menaces	Raisonne sur les règles métier, que le code n'exprime nulle part, et oriente ce qu'il faudra tester

La dernière ligne n'est pas un ajout de complaisance, c'est la conclusion d'une mesure : sur une même application, cinq scans lancés par défaut passent à côté d'un défaut d'autorisation qu'un relecteur humain repère en trente secondes. Un scanner bien configuré le trouve aussi, mais encore faut-il savoir qu'il faut le configurer ainsi.

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 une composante critique du DevSecOps moderne, et c'est aussi celle 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. Le 19 mars 2026, le scanner Trivy a lui-même été compromis, les attaquants ayant réutilisé l'accès d'un incident antérieur mal refermé. L'avis officiel GHSA-69fq-xp46-6x23, publié sous l'identifiant CVE-2026-33634, décrit trois artefacts touchés : le binaire v0.69.4, les images Docker v0.69.5 et v0.69.6, et surtout les deux actions GitHub du projet.

Le détail de cette dernière partie change une recommandation que l'on lit partout. Les attaquants n'ont pas publié une version malveillante de plus : ils ont redéplacé 76 des 77 étiquettes de version de trivy-action vers des commits piégés, et remplacé les 7 étiquettes de setup-trivy. Un projet qui écrivait trivy-action@v0.35.0, une référence pourtant précise et figée en apparence, se retrouvait à exécuter un voleur d'identifiants. Pire, celui-ci s'exécutait avant le scan légitime, si bien que le pipeline restait vert et que la sortie paraissait normale.

D'où la règle, plus exigeante qu'un simple « épinglez vos versions » : une étiquette se redéplace, un SHA de commit non. Une action GitHub s'épingle sur le SHA du commit, une image de conteneur sur son digest sha256:, et cela vaut d'abord pour les outils de sécurité, qui tournent avec les droits du pipeline et l'accès à tous ses secrets. 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

Ce que le catalogue KEV change dans la priorisation

Le catalogue KEV (Known Exploited Vulnerabilities) de la CISA ne liste pas les failles graves : il liste celles dont l'exploitation a été constatée. C'est une différence de nature, pas de degré, et c'est ce qui en fait le critère le plus tranchant du tableau ci-dessus. Une CVE au KEV avec un CVSS modéré passe devant une CVE à 9.8 que personne n'exploite.

Relevé dans le flux officiel le 18 septembre 2026, version de catalogue 2026.09.18, il porte 1 716 entrées, dont 245 ajoutées en 2025 et 232 depuis janvier 2026, soit une vingtaine par mois en moyenne, avec des rafales lors d'une campagne active. Le compte se vérifie en une commande, ce qui évite de reprendre un chiffre périmé dans un tableau de bord :

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | python3 -c 'import json,sys; d=json.load(sys.stdin); print(d["catalogVersion"], d["count"])'
# 2026.09.18 1716

Chaque entrée porte d'ailleurs un champ dueDate, renseigné sur les 1 716 : c'est l'échéance de remédiation opposable aux agences fédérales américaines. Depuis la directive BOD 26-04, du 10 juin 2026, qui remplace et révoque la BOD 22-01 fondatrice, cette échéance n'est plus un délai unique mais le résultat d'une matrice de risque à quatre facteurs : exposition de l'actif, présence au KEV, existence d'un exploit automatisable et impact technique. Les délais vont de 3 jours pour un actif exposé publiquement avec exploit automatisable, jusqu'à « fix on system upgrade » pour le reste. L'entrée relevée le 18 septembre portait précisément une échéance à trois jours.

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.

Pour aller au-delà de la théorie, le guide concept sur le fuzzing détaille le fonctionnement d'un harnais, et deux guides pratiques le mettent en oeuvre : en Python avec Atheris et en Go natif.

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

Que trouve réellement chaque outil sur une même application ?

Aucun de ces outils ne trouve ce que trouve son voisin, et la façon dont on les lance change autant le résultat que le choix de l'outil. L'affirmation se vérifie plutôt qu'elle ne se raconte : les chiffres ci-dessous viennent d'un service de notes de frais d'une cinquantaine de lignes, portant six défauts plantés volontairement, analysé le 20 septembre 2026 sur Debian 13 avec bandit 1.9.4 pour le SAST, osv-scanner 2.6.0 pour le SCA, gitleaks 8.30.1 pour les secrets, des requêtes en boîte noire pour le DAST, et des entrées fabriquées pour le fuzzing.

Contrôle	Ce qu'il a vu	Ce qu'il n'a pas vu	Moment	Signal exploitable
SAST	La requête SQL concaténée (`B608`) et le mode debug actif (`B201`)	Les 30 avis pesant sur les dépendances, le plantage, le défaut d'autorisation	Au commit	4 constats, dont 1 faux positif
SCA	30 avis sur 5 paquets, dont un non déclaré	Pas une ligne du code applicatif	Au build	Liste de paquets, jamais de fichier
Secrets, fichiers	Rien	Le jeton retiré du code au commit précédent	Pré-commit	0 trouvaille
Secrets, historique	Le jeton GitHub, règle `github-pat`	Tout le reste	À la demande	1 trouvaille
DAST anonyme	L'injection rendant 3 lignes au lieu d'1, l'absence d'en-têtes, les versions du serveur divulguées	Toute la surface authentifiée, qui lui répond 401	En recette	Preuve d'exploitation
DAST authentifié, 1 compte	Ce que voit ce compte, et rien d'anormal	Le défaut d'autorisation, invisible depuis un seul point de vue	En recette	Aucun signal
DAST authentifié, 2 comptes	Le défaut d'autorisation, seul dispositif automatique du lab à le lever	Ce qui ne dépend pas de l'identité	En recette	Preuve d'accès croisé
Fuzzing	3 entrées sur 4 font tomber la route en erreur 500	Tout ce que son corpus n'atteint pas	La nuit	Trace de plantage

Deux colonnes méritent qu'on s'y arrête, parce qu'elles décident de l'usage qu'on fait d'un scanner. Le signal n'a pas la même valeur selon l'outil : le SAST dit « ce motif est dangereux », le DAST dit « cette requête précise a rendu les trois notes ». Le premier ouvre une discussion, le second clôt le débat. Et le moment commande le reste : un contrôle qui exige un service déployé ne peut pas bloquer un commit.

Le même outil, deux périmètres, deux verdicts opposés

Le résultat le plus instructif de la mesure ne vient pas de la comparaison entre outils, mais d'un seul outil joué deux fois. Sur le même dépôt, avec la même configuration, gitleaks dir ne rapporte rien et gitleaks git rapporte le jeton. Rien n'a changé sauf ce qu'on lui a donné à lire : l'arborescence dans un cas, l'historique dans l'autre.

gitleaks dir .   # 0 trouvaille : le jeton a été retiré du code
gitleaks git .   # 1 trouvaille : il est toujours dans le commit précédent

C'est le scénario réel du secret « corrigé » : quelqu'un a sorti la clé du fichier, poussé le correctif, et le scan de pré-commit est vert depuis. Le jeton, lui, reste lisible par quiconque clone le dépôt. Retirer un secret d'un fichier ne le révoque pas : seule la rotation le fait.

Un constat n'est pas un défaut

Sur les 4 constats du SAST, l'un vise un chemin de fichier sous /var/tmp jugé peu sûr (B108). Dans cette application, ce chemin est un choix assumé de l'environnement de test : le constat est exact, le défaut n'existe pas. C'est la définition même du faux positif, et il représente ici un quart des remontées.

Ce ratio explique pourquoi un seuil de blocage posé sans tri paralyse une équipe en quelques jours. La parade tient en deux gestes : établir une baseline des constats existants pour ne bloquer que les nouveaux, et n'élever en quality gate que les règles dont on a vérifié qu'elles ne produisent pas de bruit sur votre code.

Le défaut qu'aucun scan par défaut n'a trouvé

Le service authentifie son appelant, puis lui rend n'importe quelle note, sans jamais vérifier qu'il en est le propriétaire. C'est une fuite de données directe, et pourtant les scans joués tels qu'on les lance d'ordinaire sont tous passés à côté :

le SAST ne voit rien de suspect, car la requête est correctement paramétrée et aucune fonction dangereuse n'est appelée ;
le SCA ne trouve aucune dépendance en cause, puisqu'il n'y en a pas ;
l'analyse de secrets n'a rien à signaler, aucun secret n'étant exposé ;
le DAST anonyme reçoit un HTTP 401 sur toute la surface concernée : il ne conclut pas qu'elle est saine, il ne l'atteint pas ;
le fuzzing ne provoque aucun plantage, la route étant parfaitement robuste.

Le code est techniquement irréprochable. Il viole une règle métier, et une règle métier ne se déduit pas du texte du programme : rien, dans le code, ne dit qu'une note appartient à quelqu'un. C'est la catégorie A01, Broken Access Control, restée en tête de l'OWASP Top 10:2025.

Le dispositif qui le trouve : le DAST authentifié

Conclure que « l'outillage ne peut rien » serait faux, et c'est l'erreur à ne pas commettre. Un DAST authentifié avec deux comptes distincts détecte ce défaut, à condition d'être configuré pour cela. La mesure le montre en trois temps :

Façon de lancer le scan	Requête sur la note d'un tiers	Ce que le scanner peut conclure
Sans identifiants	401	Rien, la surface est hors de portée
Avec un compte	200, ses propres données	Rien, la réponse est légitime
Avec deux comptes comparés	200, les données de l'autre	Accès croisé, donc défaut d'autorisation

La détection ne vient d'aucune requête prise isolément : les trois réponses sont individuellement valides. Elle vient de la comparaison entre ce qu'un compte devrait voir et ce qu'il obtient réellement. C'est exactement ce que fait un scanner à qui l'on fournit deux jeux d'identifiants et la liste des ressources de chacun.

D'où deux conséquences pratiques. D'abord, un DAST lancé sans identifiants sur une application dont l'essentiel vit derrière authentification ne mesure presque rien, et son rapport vide est trompeur. Ensuite, la configuration qui compte n'est pas le nombre de règles activées mais le fait de lui donner plusieurs rôles à comparer.

La couverture du fuzzing, ou pourquoi zéro plantage ne prouve rien

Le plantage sur entrée malformée illustre la même dépendance au périmètre, côté fuzzing. Deux corpus de six entrées ont été envoyés à la même route :

Corpus	Entrées	Plantages
Numérique	`0`, `1`, `2`, `99`, `-1`, `2147483647`	0
Textuel	`abc`, `0x10`, `1e999`, `%00`, `null`, `[]`	3 sur 6

Le même code, le même défaut, et deux verdicts opposés selon ce qu'on lui envoie. C'est la couverture du fuzzing : un taux de plantage nul ne dit pas « le code est sain », il dit « mon corpus n'atteint pas ce chemin ». Les fuzzers modernes traitent ce problème en se guidant par la couverture de code, c'est-à-dire en gardant les entrées qui font emprunter des branches jamais visitées, plutôt qu'en tirant au hasard. Sans cette boucle, la question à se poser devant un rapport vide n'est pas « est-ce sain ? » mais « quelle fraction du code a seulement été exécutée ? ».

Ce défaut relève de A10, Mishandling of Exceptional Conditions, la catégorie introduite par l'édition 2025 précisément pour ce type de défaillance.

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.30.1
    hooks:
      - id: gitleaks
```
rev accepte aussi un SHA de commit, et c'est la forme robuste : une étiquette peut être redéplacée, comme l'a montré la compromission de trivy-action. La contrepartie est que pre-commit autoupdate réécrit alors une étiquette par-dessus.

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@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
      with:
        persist-credentials: false

    # SAST avec Semgrep
    - name: Run Semgrep
      uses: semgrep/semgrep-action@713efdd345f3035192eaa63f56867b88e63e4e5d # 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). Le DBIR 2026 donne les ordres de grandeur à battre : 43 jours de médiane pour une résolution complète, 26 % des vulnérabilités du catalogue CISA KEV effectivement traitées, et, dans le cas médian, 50 % de vulnérabilités critiques de plus à corriger que l'année précédente. Autrement dit, la charge monte plus vite que la capacité à la traiter, ce qui rend le tri plus déterminant que le volume de scans. 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, et leur somme ne l'est pas non plus. Mesuré sur une même application, les cinq familles lancées par défaut sont passées à côté d'un défaut d'autorisation.
La façon de lancer l'outil compte autant que l'outil. Ce même défaut est détecté par un DAST authentifié avec deux comptes, et par lui seul : la détection naît de la comparaison entre rôles, pas d'une requête isolée.
Un rapport vide se lit comme une question, pas comme un verdict. Zéro plantage au fuzzing signifie « mon corpus n'atteint pas ce chemin », d'où le guidage par la couverture de code. Zéro constat au DAST anonyme signifie « je n'ai pas atteint la surface authentifiée », qui rendait ici 401.
Un pipeline vert ne dit pas « pas de vulnérabilité », il dit « aucun motif que mes outils reconnaissent, dans le périmètre où je les ai lancés ».
Le périmètre de lecture décide du résultat : le même scanner de secrets rend 0 trouvaille sur les fichiers et 1 sur l'historique. Retirer un secret d'un fichier ne le révoque pas.
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. La compromission de Trivy du 19 mars 2026 a redéplacé 76 des 77 étiquettes de son action GitHub : une étiquette bouge, un SHA de commit non. Épinglez les actions sur le SHA et les images sur leur digest, à commencer par vos outils de sécurité.

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.