Comment les analyses de sécurité par IA peuvent noyer les équipes sous de fausses alertes
Lorsque Tiago Vilas Boas a failli déposer 23 « vulnérabilités » contre des mainteneurs de projets open source—XSS, CORS, CSP, voire un SVG suspect—il a réalisé que les résultats n’étaient que du bruit, pas un signal. Le modèle avait produit du volume, mais peu de valeur. Le déclic est venu quand il a cessé de demander « audite mon code » et a commencé à rédiger le contrat avant d’ouvrir le dépôt. La direction—ce que le modèle est autorisé à affirmer—et la discipline—ce qu’il ne doit jamais inventer—ont transformé un déluge de faux positifs en résultats ciblés.
La différence entre chasse et analyse
Les scanners statiques comme Semgrep ou CodeQL détectent fiablement ce qui existe déjà : appels de fonctions dangereux, requêtes concaténées, en-têtes manquants. Ils sont rapides, déterministes et peu coûteux, exécutés à chaque push. Mais ils omettent structurellement ce qui manque : « Cette route devrait vérifier le propriétaire de la ressource avant de retourner une réponse, et elle ne le fait pas. » C’est un vide sémantique—la logique de propriété des locataires, à qui appartient quelle ressource, quelles routes sont publiques par conception. Le scanner voit le code ; la chasse humaine repère le contrôle absent.
Fixer les garde-fous
La direction consiste à ancrer le LLM à une norme stricte avant même qu’il lise un fichier. L’auteur verrouille l’invite avec la norme OWASP ASVS 5.0 et ses identifiants de exigences précis. « Bonnes pratiques » ne suffit pas. Chaque invariant doit être une phrase falsifiable unique : « Chaque gestionnaire de webhook entrant vérifie l’authenticité de l’expéditeur avant de modifier l’état » relève de la chasse, pas d’une opinion. La discipline impose un format : les constats, observations et hypothèses restent séparés. Pas de fichier:ligne → pas de constat. CWE inventé → session fermée. Besoin d’exécution runtime → pas de ticket. Pas de « X sur Y » → pas de chasse. Aucune preuve de concept, aucune requête en direct, aucune réécriture de code de production dans la même session. La session qui trouve n’est pas celle qui corrige.
Ce que cela implique pour demain
Le cadre ci-dessus tient dans une invite, mais derrière se cache une base de connaissances qui indique au modèle quand chasser, quand analyser, ce qui constitue un constat, et les trois barrières empêchant de déverser des rapports bruts dans le suivi. Sans cette base, le modèle improvise ; sans les compétences de harness, il lit le bloc et passe à autre chose. Il ne s’agit pas de rendre le LLM plus intelligent, mais de contrôler son comportement pour que ses sorties correspondent au modèle de menace, et non à son imagination.
Pourquoi c’est important
Des outils AppSec par IA non contrôlés risquent d’étouffer les mainteneurs sous des tickets sans pertinence, érodant la confiance dans l’automatisation. Des contrats clairs et des invites disciplinées recentrent l’attention sur la validité plutôt que le volume, permettant aux scanners de faire ce qu’ils font bien—trouver ce qui est présent—tandis que les humains se concentrent sur ce qui manque. Les enjeux ne concernent pas l’excellence algorithmique, mais le rapport signal/bruit dans votre pipeline de sécurité. Et c’est ce rapport qui détermine si l’IA devient un multiplicateur de force… ou une source de distraction.
Source : DEV Community. Synthèse éditoriale assistée par IA — TechnoExpress.