Votre backlog de vulnérabilités n’est plus une dette technique, c’est une surface d’attaque

Chaque programme de sécurité en a une : une file de quelques milliers, voire de quelques centaines de milliers de vulnérabilités, que personne n’a traitées et que personne ne s’attend à traiter. La plupart des équipes la classent dans la dette technique : un coût assumé, remboursé quand le temps le permet, et tolérable parce que son taux d’intérêt reste faible.

Cette comptabilité a longtemps tenu, car elle reposait sur une seule hypothèse : presque rien dans la file ne serait jamais atteint ni exploité par qui que ce soit. Aussi raisonnable cette hypothèse ait-elle pu être comme décision d’ingénierie, elle est devenue le point le plus fragile du modèle.

Le backlog était un pari

Les développeurs sont plus nombreux que les professionnels de la sécurité depuis que ces deux fonctions existent. Dans ces conditions, le triage était la bonne décision — et, franchement, la seule : hiérarchiser les vulnérabilités, fixer un seuil de gravité, traiter ce qui le dépasse et accepter le reste.

Accepter le reste revenait à parier sur la probabilité d’exploitation : un attaquant ne trouverait pas cette vulnérabilité précise de gravité moyenne, dans ce service précis, avant que le code environnant ne change de toute façon. Les vulnérabilités étaient considérées comme réelles ; le pari était qu’elles resteraient sans traitement.

Les programmes utilisent encore les outils de ce pari : le registre des risques, les niveaux de SLA, les statuts « ne corrigera pas » et « risque accepté », les workflows d’exception et de dérogation, ainsi que les seuils de gravité en dessous desquels rien n’est trié. Chacun existe parce qu’une organisation a fait un compromis rationnel et avait besoin de mécanismes pour l’appliquer à grande échelle.

Trois facteurs ont changé simultanément

Un pari ne vaut que par les probabilités sur lesquelles il repose, et trois de ces probabilités ont évolué.

1. Le code arrive plus vite que n’importe quel rythme de revue

Le nombre de lignes de code par développeur a augmenté de 218 %, et 62 % de ce code est défectueux ou non sécurisé. En juin 2026, les données des produits Snyk montrent qu’environ six nouvelles vulnérabilités sont introduites pour chaque vulnérabilité corrigée, et le développement agentique continue d’élargir cet écart.

La tendance compte davantage que le chiffre, car un flux entrant six fois supérieur au flux sortant signifie que le reliquat accepté augmente à chaque sprint sans que personne n’ait décidé de l’augmenter. Chaque seuil, SLA et modèle de staffing du programme avait été dimensionné pour un autre rythme d’arrivée, et aucun n’a été renégocié lorsque ce rythme a changé.

2. Le code arrive sans auteur à qui poser des questions

« Demandez à l’auteur » est le plus ancien outil de la revue de code, et il n’a pas d’équivalent lorsque l’auteur est un agent : personne n’a choisi la dépendance, réfléchi au pattern ou ne peut expliquer la raison de la modification.

Les reviewers approuvent désormais du code qu’ils n’ont pas écrit et qu’ils ne peuvent pas interroger. Le raisonnement qui accompagnait autrefois une modification doit donc être reconstitué à partir de la modification elle-même. Les vulnérabilités qu’une conversation de deux minutes aurait autrefois permis de résoudre finissent dans la file, ce qui augmente une deuxième fois le flux entrant, pour des raisons sans rapport avec le volume de code.

3. Les attaquants ont automatisé leur côté

Le pari sur la probabilité d’exploitation reposait sur une reconnaissance à vitesse humaine, où l’exploration d’une vaste surface coûtait réellement des heures à l’attaquant et produisait surtout du bruit. L’automatisation a changé la donne. Parcourir une surface étendue, répertorier chaque signal faible et tester des combinaisons auxquelles aucun analyste n’aurait consacré un après-midi ne coûtent désormais presque rien.

La conséquence est précise, tout comme la réponse. Chaque entrée de votre registre a été évaluée selon les anciennes probabilités, et la plupart n’ont pas été réexaminées depuis leur acceptation. Réévaluer ce registre constitue donc un travail que vous pouvez définir et planifier ce trimestre.

Des constats de faible gravité se combinent pour former des chemins de forte gravité

La gravité évalue une vulnérabilité isolément, tandis que les attaques combinent plusieurs vulnérabilités.

Prenons trois entrées qui se situent chacune confortablement sous le seuil de triage : une référence directe non sécurisée à un objet qui divulgue l’identifiant d’un objet interne, une réponse d’erreur trop détaillée qui confirme la validité d’un identifiant deviné, et une bibliothèque de sérialisation obsolète présentant un problème connu de désérialisation. Individuellement, chacune correspond au type de vulnérabilité qu’un programme accepte et ne réexamine jamais. Combinées, elles forment un chemin authentifié vers l’exécution de code à distance.

C’est ce mécanisme qui transforme un backlog en surface d’attaque. La file constitue un inventaire de composants qu’un attaquant peut assembler, et c’est cet assemblage qu’un modèle de gravité n’évalue jamais.

La démarche concrète consiste à lire le registre comme la description de ce dont dispose un attaquant. Demandez-vous quelles vulnérabilités acceptées se trouvent dans le même service, partagent la même frontière de confiance ou touchent les mêmes données, car c’est dans ces regroupements que se trouve l’exposition — et ils restent invisibles dans toute vue triée par gravité.

La priorisation ordonne la file sans la raccourcir

Face à un backlog qui s’allonge, le réflexe consiste à mieux classer : évaluer plus précisément, pondérer selon l’accessibilité, trier selon l’exploitabilité et traiter le haut de la liste avec davantage de confiance.

Un meilleur classement produit une file mieux ordonnée, mais de même longueur. Une fois que le flux entrant dépasse le flux sortant, le classement détermine quelles vulnérabilités resteront définitivement sans traitement, faisant de la priorisation l’outil de gestion du risque accepté. Améliorer cet outil améliore la gestion d’un état dont le programme devrait sortir.

L’accessibilité, l’exploitabilité et l’historique des résultats des corrections sont utiles ailleurs. Appliquez-les à la justesse des corrections et à l’ordre de résolution, là où ils répondent à des questions qui font évoluer le chiffre : cette correction résoudra-t-elle un chemin réel ? Sera-t-elle déployée sans casser le build ? Que faut-il résoudre en premier ? Atteindre zéro dépend du rythme, et le classement ne modifie pas ce rythme.

Ce qu’il faut pour traiter le backlog comme une surface d’attaque

Avant de modifier quoi que ce soit, établissez quatre chiffres. La plupart des équipes peuvent les obtenir en une semaine, et ils recadrent généralement la conversation plus rapidement que n’importe quel argument.

1. Le flux entrant réel comparé aux clôtures réelles sur les 90 derniers jours, en comptant les vulnérabilités effectivement résolues plutôt que celles simplement triées.

2. Le nombre d’entrées dont le risque est accepté et de celles marquées « ne corrigera pas », ainsi que la date de leur dernier réexamen. Toute date antérieure à l’adoption des outils de codage par IA dans votre organisation correspond à une entrée évaluée selon des probabilités qui ont depuis changé.

3. La part du code fusionné attribuable à un auteur humain, qui vous indique quelle proportion de votre flux entrant peut encore être expliquée par la personne qui l’a produit.

4. Le taux de fusion des corrections de sécurité : parmi les corrections ouvertes au trimestre dernier, combien ont été déployées ?

Le quatrième chiffre est généralement celui qui surprend, car il constitue la véritable contrainte depuis des années, tandis que l’attention restait concentrée sur la détection. Des corrections sont générées, mais jamais fusionnées : un programme qui produit davantage de vulnérabilités sans faire progresser ce taux ne fait qu’allonger la file.

Un backlog diminue lorsque trois conditions sont réunies : la prévention réduit le flux entrant au moment où le code est écrit, la résolution s’effectue sans exiger une décision humaine pour chaque vulnérabilité, et la justesse des corrections peut être garantie sans que quelqu’un lise chaque diff. Mettez ces trois éléments en place et votre équipe pourra faire reculer le risque en résolvant davantage de vulnérabilités qu’il n’en arrive. Le registre commence à se réduire pour la première fois depuis sa création.

À partir de là, la mission change, car le travail ne se situe plus dans la file : il devient le programme lui-même.