569 354 constats, 202 réels : ce que chaque contrôle de sécurité vaut une fois calibré

« On a activé les outils. » C’est vrai, et c’est précisément le problème.

L’organisation moyenne porte 569 354 constats de sécurité. Après priorisation fondée sur des preuves, il en reste 11 836. Ceux qui exigeaient réellement une action : 202. Ces chiffres viennent d’une mesure sur 101 millions de constats répartis sur 178 organisations, publiée par OX Security en 2025.

Entre 95 et 98 % du signal est donc du bruit. Et le coût de ce bruit ne se compte pas en temps de triage : il se compte en crédibilité. Une fois qu’une équipe de développement a appris qu’un tableau de bord de sécurité ne contient rien d’actionnable, elle cesse de le lire — y compris le jour où il contient quelque chose. Huit équipes sur dix livrent aujourd’hui du code qu’elles savent vulnérable (Checkmarx, 2025). Ce n’est pas de la négligence. C’est ce qu’on obtient quand on demande à quelqu’un de lire une liste illisible.

La conclusion tentante — « les outils ne servent à rien » — est fausse. Chacun des six contrôles ci-dessous répond à une menace mesurée. Mais aucun ne produit un livrable utilisable sans calibrage. La sortie brute d’un scanner est une matière première, pas un rapport.

Voici, pour chacun : pourquoi il est nécessaire, pourquoi sa sortie brute est inexploitable, et la technique précise qui la rend actionnable.

1. SAST — l’analyse statique

Pourquoi. Les vulnérabilités exploitées ont causé 20 % des brèches l’an dernier, en hausse de 34 % (Verizon DBIR, 2025). L’analyse statique est le dernier moment où corriger un défaut ne coûte presque rien : après la fusion, le même défaut se paie en incident, en correctif d’urgence et en fenêtre de déploiement.

Pourquoi c’est inutilisable brut. Une étude portant sur près de 3 000 dépôts a relevé 2 116 alertes contenant 180 défauts réels — 91 % de bruit (Ghost Security, 2025). Le détail est pire que la moyenne : sur Python/Flask, 99,5 % des alertes d’injection de commande étaient fausses. À dix minutes de revue manuelle par constat, une seule combinaison langage/cadriciel représentait près de 200 heures de triage.

Ajoutez-y le déclenchement initial : activé sur une base de code existante, l’outil signale dix ans d’historique le premier jour.

Ce qui le rend utilisable. Deux décisions.

D’abord, établir une base de référence sur l’existant : ce qui est déjà là est enregistré, mais ne bloque personne. Ensuite, ne poser la barrière que sur le code neuf — les lignes que cette demande de tirage a touchées. Le nombre reste petit, la barrière tient, et le constat arrive à un développeur qui a encore le contexte en tête.

Troisième geste, moins visible : désactiver les catégories de règles inapplicables à votre pile. C’est de là que vient l’essentiel des faux positifs, et une règle d’injection SQL brute n’a rien à dire d’un dépôt qui passe exclusivement par un ORM.

2. SCA — les dépendances

Pourquoi. 70 % de votre code est open source, et 86 % des bases de code livrent au moins un composant vulnérable connu (Black Duck OSSRA, 2025). L’application typique contient 911 composants, dont 64 % sont des dépendances transitives — celles que personne n’a choisies explicitement.

Et le terrain s’est durci : les paquets malveillants ont augmenté de 73 % en 2025, et le ver Shai-Hulud a compromis plus de 500 paquets npm en se servant des jetons volés des mainteneurs eux-mêmes.

Pourquoi c’est inutilisable brut. L’outil signale les 911 composants sans distinguer ceux que votre code appelle. Or 70 à 80 % des dépendances ne sont jamais référencées. Vous recevez donc une liste dont la majorité décrit un risque théorique : la bibliothèque est présente, la fonction vulnérable ne sera jamais atteinte.

Ce qui le rend utilisable. Trois filtres, dans cet ordre.

L’atteignabilité d’abord. La question n’est pas « cette bibliothèque est-elle vulnérable ? » mais « mon code appelle-t-il la fonction vulnérable ? ». Ce seul filtre retire environ 92 % des constats (Endor Labs, 2025).

Puis l’exploitation réelle. L’EPSS évalue la probabilité qu’une vulnérabilité soit exploitée dans la nature ; le catalogue CISA KEV nomme celles qui le sont déjà. Environ 80 % des vulnérabilités dont le score EPSS dépasse 0,6 finissent effectivement exploitées.

Puis la disponibilité d’un correctif. Une vulnérabilité sans correctif n’est pas un billet à assigner : c’est une décision à prendre — accepter, contourner, ou remplacer le composant. La mélanger aux autres garantit qu’elle sera reportée sans que personne ne l’ait décidé.

3. L’analyse des secrets

Pourquoi. Les identifiants volés sont la première porte d’entrée : 22 % de toutes les brèches (Verizon DBIR, 2025). Un secret exposé n’est pas une vulnérabilité qu’un attaquant doit exploiter — c’est un identifiant fonctionnel qu’il lui suffit d’utiliser.

Le volume progresse : 28,6 millions de secrets ont fuité dans des commits publics en 2025, une hausse de 34 % (GitGuardian, 2026). Et 70 % des secrets ayant fuité en 2022 authentifiaient toujours des années plus tard. Personne ne fait tourner ce qu’il ignore.

Pourquoi c’est inutilisable brut. Un scanner de secrets fonctionne par motif et par entropie. Un UUID, une empreinte, une valeur d’exemple dans un test : tout cela ressemble exactement à une clé de production active. Et aucun scanner, en regardant la chaîne seule, ne peut dire si la clé fonctionne encore.

Ce qui le rend utilisable. La vérification de validité : chaque candidat est soumis au service émetteur pour voir s’il authentifie encore.

Le tri qui en découle est net. Une clé qui ne fonctionne plus relève du ménage — on la retire du dépôt, sans urgence. Une clé qui fonctionne est un incident, avec la chaîne d’escalade correspondante. Les deux cessent de partager la même file, et c’est cette séparation qui rend la liste lisible.

Un point de méthode : ne vous fiez pas au code HTTP. Plusieurs API renvoient 200 pour une requête portant un identifiant invalide. La vérification doit interpréter la réponse, pas seulement son statut.

Enfin, tout ce qui est trouvé doit être considéré comme brûlé : roté, pas supprimé puis oublié. Effacer le commit n’a jamais fait tourner la clé.

4. DAST — l’application en exécution

Pourquoi. Le contrôle d’accès défaillant est premier au OWASP Top 10 (2025) et a été trouvé dans pratiquement toutes les applications testées. Surtout : il est structurellement invisible à l’analyse statique. Savoir si le rôle A peut lire les données du rôle B ne se répond qu’en posant la question à une application qui tourne.

Il en va de même de la gestion des sessions, de ce que votre API renvoie à qui, et de la configuration qui n’est fautive qu’une fois déployée — en-têtes, TLS, erreurs verbeuses, points d’accès oubliés.

Pourquoi c’est inutilisable brut. Un scanner non authentifié ne dépasse jamais la page de connexion. Or c’est derrière l’authentification que vit presque tout ce qui mérite un test. Il explore ce qu’il peut atteindre, devine le reste, et ce sont ces suppositions qui remplissent le rapport.

Ce qui le rend utilisable. Trois réglages.

Authentifier le scanner correctement — jetons, sessions, renouvellement. C’est là que la sortie DAST dérape le plus souvent, et c’est la correction qui change le plus de choses.

Le piloter par votre schéma OpenAPI ou GraphQL plutôt que par exploration de liens. La couverture suit alors ce que vous publiez réellement, y compris les points d’accès qu’aucun crawler ne découvrirait dans une application monopage.

Ne bloquer que sur des constats confirmés. Soit le scanner l’a prouvé, soit il ne bloque pas le build. Tout ce qui n’est pas prouvé devient une question pour la prochaine analyse, non un billet pour un développeur aujourd’hui.

5. Conteneurs et code d’infrastructure

Pourquoi. 87 % des images de conteneurs en production portent une vulnérabilité élevée ou critique (Sysdig, 2025). L’image est ce qui s’exécute réellement — pas le dépôt, pas la branche que vous avez revue — et elle embarque un système d’exploitation que personne dans votre équipe n’a choisi, corrigé au rythme d’un tiers.

Le code d’infrastructure est l’autre moitié : une seule règle permissive dans un fichier Terraform déploie un stockage public plus vite qu’aucun humain ne le ferait.

Pourquoi c’est inutilisable brut. C’est le contrôle où l’écart entre volume et risque est le plus large. Sysdig a mesuré que 85 % des vulnérabilités critiques et élevées logent dans des paquets qui ne sont jamais chargés à l’exécution. Le scanner les signale toutes. Une image de base complète arrive d’ailleurs avec 70 à 250 vulnérabilités ouvertes avant la moindre ligne de votre code.

Ce qui le rend utilisable. Ici, la bonne réponse n’est pas de trier plus vite.

Classer selon ce qui se charge réellement à l’exécution. Quatre-vingt-cinq pour cent de la liste sort du champ immédiat — non pas ignorée, mais reclassée pour ce qu’elle est.

Changer l’image de base plutôt que le retard accumulé. L’essentiel de ces vulnérabilités réside dans des shells, gestionnaires de paquets et utilitaires système que votre conteneur n’a aucune raison de contenir. La même application rebâtie sur une base allégée tombe sous 20 vulnérabilités ; sur une base distroless, souvent près de zéro. C’est une décision de conception, pas un exercice de correction — et c’est ce qui la rend durable.

Attester le reste. Ce qui subsiste et n’est réellement pas exploitable reçoit une attestation VEX, pour cesser d’être re-signalé à chaque build.

6. Le pipeline lui-même

Pourquoi. Votre pipeline détient les clés de la production. En mars 2025, la compromission d’une seule GitHub Action — tj-actions/changed-files — a exposé les secrets de dépôts qui en dépendaient, plus de 23 000 au moment des faits. Les attaquants ne visent plus le code : ils visent le système qui le construit, parce qu’il se situe entre la source et la production.

Pourquoi c’est inutilisable brut. Ce n’est pas un problème de volume, mais de durée. Chaque décision de calibrage décrite plus haut se dégrade dès qu’une équipe désactive une règle pour une livraison urgente. Une barrière qu’on peut désactiver d’un clic n’est pas une barrière ; c’est une convention.

Ce qui le rend utilisable. Le calibrage doit vivre dans une politique que la plateforme applique, pas dans la configuration d’un dépôt que chacun modifie. Protection des branches et règles de revue qu’une échéance ne peut lever, permissions de build et connexions de service limitées à la tâche plutôt qu’à l’organisation, et surtout : des exceptions qui expirent à une date plutôt que de devenir permanentes par inadvertance.

Le choix de l’outil compte — mais moins que sa configuration

Une question revient à chaque mandat : « lequel fait le moins de faux positifs ? » Les mesures publiées permettent d’y répondre en partie. Elles disent surtout autre chose : l’écart entre un outil bien configuré et le même outil sorti de sa boîte dépasse l’écart entre deux outils concurrents.

C’est aussi ce que nous observons sur le terrain. Les chiffres ci-dessous viennent de bancs d’essai publiés, pas de nos mandats — mais ils correspondent à ce que nous voyons en pratique, et nous les citons pour cette raison. Quand une mesure indépendante et l’expérience disent la même chose, c’est généralement que la chose est vraie.

SAST. Le banc d’essai CASTLE (2025) a mesuré la précision des analyseurs sur un jeu de cas étiquetés : CodeQL arrive en tête à 60,3 %, devant Semgrep à 56,3 % et SonarQube à 51,9 % — ce dernier signalant 94,6 % des cas non vulnérables. Checkmarx, mesuré séparément par le rapport Tolly de 2024, affiche 36,3 % de faux positifs sur des applications de référence.

Aucun de ces chiffres n’est bon dans l’absolu, et c’est le point. La donnée utile est ailleurs : les mêmes analyses relèvent qu’un outil non calibré produit 60 à 90 % de faux positifs, contre 10 à 20 % une fois réglé. Checkmarx documente jusqu’à 80 % de réduction par la personnalisation des requêtes, et son préréglage de base retire à lui seul jusqu’à 70 % des constats.

Autrement dit : changer d’outil vous fait gagner quelques points de précision ; le configurer vous en fait gagner cinquante. Si vous exploitez déjà SonarQube ou Checkmarx, le calibrer est presque toujours plus rentable qu’un remplacement — et bien moins perturbant pour les équipes.

DAST. C’est ici que l’architecture de l’outil change réellement les choses. Les scanners par exploration testent large et devinent le reste ; les scanners par modèle ne signalent que ce qui correspond à une condition connue. Nuclei appartient à la seconde catégorie : ses modèles YAML exigent une correspondance explicite — statut HTTP, expression régulière, chaîne attendue — avant de déclarer un constat. Le taux de faux positifs s’en trouve structurellement bas.

La contrepartie est réelle : Nuclei ne trouve que ce que ses modèles décrivent. Il ne remplace pas ZAP ou Burp pour l’exploration d’une application inconnue. La combinaison qui fonctionne en pipeline : Nuclei pour les vérifications répétées à chaque livraison, où le bruit coûte le plus cher, et un scanner complet — authentifié, piloté par le schéma — sur une cadence plus lente.

Secrets. L’écart tient à un seul mécanisme : la vérification. TruffleHog exécuté avec --only-verified tente une authentification auprès du service émetteur et écarte automatiquement ce qui ne fonctionne plus ; les retours de terrain évoquent jusqu’à 90 % de volume de triage en moins sur des dépôts bruyants. Gitleaks, plus rapide, fonctionne par motif et entropie : chaque constat demande un jugement humain.

Ce n’est pas un classement, c’est une répartition. Gitleaks en crochet pré-commit, où la vitesse prime et où le développeur tranche immédiatement ; TruffleHog vérifié en intégration continue, où c’est le volume qu’il faut maîtriser.

Conteneurs. Trivy et Grype partagent leurs sources principales mais divergent par leur base et leur logique d’appariement. Grype est reconnu pour un appariement version-paquet précis, hérité de sa base normalisée ; Trivy couvre plus large, parfois au prix de bruit sur des cas limites. Une analyse de 2025 portant sur huit images Docker Hub très téléchargées a d’ailleurs relevé des faux négatifs chez les deux — un rappel utile qu’aucun scanner d’images n’est exhaustif.

Sur les images critiques, les exécuter tous les deux reste défendable. Mais le gain le plus important ne vient d’aucun des deux : il vient du classement par ce qui se charge à l’exécution, et du changement d’image de base.

Ce qu’il faut en retenir. Un outil se choisit sur son architecture — vérification pour les secrets, modèles pour le DAST répétitif, analyse de flux pour le SAST. Il se rentabilise sur sa configuration. Une équipe qui change d’outil sans changer de méthode obtient le même volume, sous une autre marque.

C’est la raison pour laquelle nos mandats commencent presque toujours par calibrer ce qui est déjà en place plutôt que par un remplacement. Le remplacement se voit dans un budget ; le calibrage se voit dans la liste que l’équipe accepte enfin de lire.

Le fil conducteur

Les six contrôles répondent à des menaces différentes, mais le calibrage suit partout la même forme : ne montrer que ce qui est réellement atteint, réellement exploité, réellement corrigeable.

Ce qui a changé, c’est l’urgence. Les développeurs assistés par IA livrent trois à quatre fois plus vite et introduisent des constats de sécurité dix fois plus souvent (Apiiro, 2025). Aucune équipe de revue ne suit ce rythme — et attendre de meilleurs modèles n’est pas une stratégie : Veracode a testé plus de 100 modèles et constaté que 45 % du code généré échoue aux tests de sécurité, sans amélioration selon la taille ou la génération du modèle.

Il n’y a pas de miracle. Soit les contrôles s’exécutent à chaque commit et sont calibrés jusqu’à une liste que quelqu’un lira, soit ils s’exécutent une fois par an et se dégradent entre-temps.

Installer l’outil prend un après-midi. Le calibrer est le travail — et c’est la différence entre 569 354 constats et les 202 qui comptaient.