AppSec à l’ère des agents : deux visions US, et ce qui casse vraiment dans le pipeline

⏱️

Temps de lecture estimé
~11 minutes

Deux billets US publiés à une semaine d’écart posent le même diagnostic : l’AppSec par volume de findings s’effondre face à la vélocité des agents IA. L’un mise sur l’élimination des classes de vulnérabilités à la racine, l’autre sur la vérification indépendante des correctifs. Voyons ce qui casse réellement dans un pipeline CI/CD aujourd’hui.

Chris Hughes ouvre son billet du 2 septembre sur Resilient Cyber avec trois chiffres : 59 000 CVE attendues sur 2026, un délai divulgation-exploitation passé de 771 jours en 2018 à 6 jours en 2023, et des agents autonomes qui exploitent déjà 97,7 % des vulnérabilités du catalogue KEV testées en laboratoire. Quatre jours plus tard, Taimur Ijlal lui répond sans le savoir, depuis The Cloud Security Guy. Pour lui, on a toujours eu de quoi détecter les failles, et largement. Il nous a toujours manqué une mécanique pour les corriger vite et prouver qu’elles le sont.

Je lis régulièrement ces newsletter. Le diagnostic est le même sur les 2, les réponses divergent. Et Voyons ce qui manque aux deux : ce qui casse dans un pipeline CI/CD quand le code de la pull request n’a plus été écrit par un humain qui sait ce qu’il committe.

Ce que Hughes et Ijlal disent, et où ils s’écartent

Hughes part de l’échec du triage classique. Les grandes entreprises accumulent des centaines de milliers de findings et en corrigent environ 10 % par mois(la il est un peu optimiste quand meme…). Le NIST a rangé 29 000 CVE en “Not Scheduled”, faute de bras. Sa réponse est architecturale. Il veut qu’on arrête de scorer sur la sévérité théorique, puisque le CVSS ne dit rien de l’exploitabilité réelle. Quand le même type de faille revient encore et encore, il y voit un problème d’organisation plutôt qu’un problème technique. Et il remonte aux causes racines, chiffres à l’appui : Gecko a ramené 569 divulgations à 105 causes distinctes. Tu corriges la cause et des dizaines de findings tombent d’un coup, au lieu de les traiter un par un jusqu’à la retraite.

Ijlal prend le problème par l’autre bout. Pour lui, la détection n’a jamais été le goulot d’étranglement : un scanner trouve une faille en quelques secondes, alors qu’une remédiation vérifiée prend des heures, parfois des jours. Il propose un pipeline à quatre agents. Le Reviewer identifie et explique la vulnérabilité dans la pull request. Le Fixer propose un correctif minimal avec ses tests. Le Verifier contrôle indépendamment que la faille a disparu. L’Explainer résume le tout pour le développeur, qui garde la main sur le bouton merge. Son principe : “AI proposes, independent verification confirms”.

Ce qu’Ijlal décrit comme une cible à atteindre tourne déjà en open source ; j’en avais fait l’inventaire en juillet. VVAH, le harness agentique de Visa, c’est ce découpage en onze étapes, avec un panel adversarial en lecture seule pour la validation. Visa met en avant le MTTA, le temps entre la découverte d’une exploitabilité et un correctif validé en production. Cette métrique-là, on ne la trouve dans aucun des deux articles US. Hughes compte les findings, Ijlal compte les étapes du workflow, et personne ne vérifie que le pipeline sert à quelque chose.

Note du PandaRedacteur : c’est amusant de voir deux personnes qui ne se citent pas arriver au même diagnostic à quatre jours d’écart. Soit c’est le signe qu’un vrai problème émerge, soit c’est la preuve que tout le monde lit le même rapport Verizon DBIR le même week-end.

IMHO, les deux se complètent. Éliminer les causes racines (Hughes) réduit ce qu’il reste à vérifier ; vérifier chaque correctif de façon indépendante (Ijlal) empêche un agent trop sûr de lui de refermer un ticket sans rien avoir corrigé. Hughes travaille sur le stock, Ijlal sur le flux. Faites l’un sans l’autre, et votre pipeline marche sur une jambe.