if ( !emtpy($headline_subheadline ) ) : ?>
L’arrêt temporaire par Google de certaines soumissions de bug bounty souligne un problème plus large auquel sont confrontées les entreprises : l’IA rend la découverte des vulnérabilités moins coûteuse et plus rapide, mais les équipes de sécurité ont du mal à valider, prioriser et corriger un flot croissant de découvertes générées par les machines.
endif; ?>
L’IA accélère la découverte de vulnérabilités logicielles, mais elle crée également un nouveau goulot d’étranglement pour les défenseurs : décider quelles découvertes générées par les machines justifient une enquête. Google a décidé de cesser temporairement d’accepter certaines soumissions de bug bounty après qu’une vague de rapports automatisés en grande partie invalides ait mis en évidence un défi croissant pour les équipes de sécurité alors que la découverte de vulnérabilités basée sur l’IA commence à dépasser la capacité de validation humaine.
La suspension de son programme de bug bounty fait suite à des tentatives antérieures de Google visant à réduire la quantité de matériel de mauvaise qualité atteignant ses équipes de sécurité. En mars, la société a renforcé les règles régissant son programme de vulnérabilité open source après avoir signalé une forte augmentation des soumissions générées par l’IA. Google a déclaré que certains rapports contenaient des affirmations incorrectes sur la façon dont les vulnérabilités pourraient être déclenchées, tandis que d’autres identifiaient des défauts de codage qui avaient peu d’impact pratique sur la sécurité.
Google a commencé à demander des preuves plus solides pour certaines catégories de vulnérabilités, notamment des résultats reproductibles ou des correctifs acceptés. Il a ensuite cessé de récompenser certains rapports de vulnérabilité de produits de niveau inférieur.
Mais un volume élevé de rapports ne signifie pas nécessairement que les résultats sont de faible valeur. Vercel, par exemple, a déclaré en septembre avoir reçu 1 285 rapports de vulnérabilité au cours d’un défi de sécurité de deux semaines pour son environnement Sandbox, la société ayant automatisé certaines parties du tri. Des dizaines de soumissions ont finalement été validées.
La recherche sur la vulnérabilité assistée par l’IA produit également des résultats importants dans la pratique. Une faille critique dans le serveur de fichiers HTTP Rejetto, découverte avec l’aide du modèle de recherche de vulnérabilités Mythos d’Anthropic, a ensuite été ciblée lors de tentatives d’exploitation.
Le problème va au-delà des programmes de bug bounty. À mesure que les entreprises adoptent des outils assistés par l’IA dans les flux de travail de sécurité des applications, la découverte de vulnérabilités pourrait dépasser la capacité de validation et de correction de ce que ces systèmes trouvent.
Pour les RSSI, la question est de savoir si les processus de gestion des vulnérabilités existants peuvent absorber ce volume sans permettre aux découvertes de faible valeur de consommer les ressources nécessaires aux risques confirmés.
Pression de validation
L’une des principales préoccupations est que l’IA peut augmenter le volume de soumissions plus rapidement que les équipes ne peuvent augmenter leur capacité de vérification.
« Un rapport convaincant peut être généré rapidement », a déclaré Bhupendra Chopra, directeur des revenus chez Kanerika. « Le vérifier peut encore nécessiter qu’un ingénieur retrace le code et teste les conditions d’attaque revendiquées. »
L’expérience de Google doit être considérée comme un avertissement sur les aspects économiques du reporting des vulnérabilités plutôt que comme une preuve que le même problème est déjà répandu dans les entreprises, selon Sakshi Grover, directeur de recherche pour la sécurité des informations et des données chez IDC.
« L’IA peut aider les chercheurs à découvrir de véritables vulnérabilités, mais elle peut également produire des rapports convaincants et peu étayés à moindre coût », a déclaré Grover. « L’équipe réceptrice doit encore établir si le code concerné existe, si le chemin d’attaque revendiqué est accessible et s’il existe un impact significatif sur la sécurité. »
Cela peut imposer un coût direct aux entreprises. Une découverte qui parvient au propriétaire d’une application avant d’avoir été correctement évaluée peut prendre du temps d’ingénierie, même si la version logicielle concernée n’est pas déployée ou si le code vulnérable n’est pas accessible dans l’environnement de l’organisation.
Chopra a déclaré que les équipes de sécurité devraient vérifier qu’une faille signalée affecte réellement leur environnement avant de la traiter comme une priorité urgente de remédiation. Grover a déclaré que les RSSI devraient juger les outils de sécurité assistés par l’IA par les résultats exploitables qu’ils produisent et les efforts requis pour les valider, plutôt que par le nombre brut de vulnérabilités qu’ils identifient.
« Un tableau de bord de résultats plus volumineux ne constitue pas, en soi, la preuve d’une meilleure sécurité », a déclaré Grover.
Sunil Varkey, RSSI, a déclaré que les entreprises devront de plus en plus considérer le triage comme une capacité de sécurité à part entière, en utilisant des exigences en matière de preuves, une notation d’accessibilité et un filtrage automatisé avant que les résultats ne parviennent aux examinateurs humains.
Réparer l’arriéré
La deuxième préoccupation majeure est que même les vulnérabilités confirmées se disputent des capacités d’ingénierie limitées.
« Davantage de rapports ne créent pas plus de capacités d’ingénierie ou de fenêtres de maintenance », a déclaré Chopra.
Grover a déclaré qu’une faille techniquement valide pourrait ne pas être accessible dans l’environnement déployé, tandis qu’une vulnérabilité avec un score de gravité inférieur pourrait exiger une action plus rapide si elle affecte un système exposé et critique pour l’entreprise. Cela rend le contexte de déploiement et les preuves d’exploitation plus utiles pour la priorisation que de s’appuyer uniquement sur un indice de gravité généré par un scanner.
Les résultats d’un scanner doivent être traités comme une hypothèse plutôt que comme une preuve d’une vulnérabilité exploitable, a déclaré Keith Prabhu, fondateur et PDG de Confidis. Les équipes doivent encore établir si le code concerné est présent et accessible, reproduire le problème et évaluer son impact dans leur environnement.
Un indicateur utile, a ajouté Chopra, est de savoir si les analystes passent plus de temps à rejeter les conclusions faibles alors que les vulnérabilités confirmées à haut risque restent non résolues plus longtemps. Si cela se produit, le processus de reporting lui-même risque de consommer des capacités qui seraient autrement utilisées pour réduire les risques.
Grover a déclaré que les RSSI devraient suivre les efforts de validation et l’âge des expositions confirmées à haut risque, plutôt que de se concentrer sur le nombre de problèmes signalés par un outil.
Triage comme cible
Des rapports de vulnérabilité peu coûteux et plausibles pourraient également créer des opportunités d’abus. Chopra a averti que même si la décision de Google d’arrêter les soumissions de vulnérabilités de produits ne montre pas que l’entreprise a été ciblée par une campagne de distraction délibérée, un tel scénario est plausible.
« Un canal de signalement non filtré pourrait donner aux attaquants un moyen de consommer la capacité de sécurité sans d’abord violer un système », a-t-il déclaré.
Les attaquants pourraient, par exemple, soumettre des variantes de la même réclamation sur plusieurs services, obligeant les équipes de sécurité à passer du temps à enquêter sur chaque soumission avant de déterminer si elles concernent le même problème.
Prabhu a déclaré que les organisations devraient traiter les grands volumes de rapports de mauvaise qualité comme un risque de résilience et de flux de travail, sans supposer que chaque mauvaise soumission fait partie d’une attaque délibérée.
Chopra a déclaré que les organisations peuvent réduire ce risque en exigeant des preuves reproductibles, en regroupant les rapports en double et en limitant les soumissions lorsque des modèles d’abus émergent.
Une utilisation accrue de l’IA pour le tri pourrait également introduire une autre voie d’attaque. Grover a déclaré que les rapports de vulnérabilité malveillants pourraient contenir des instructions d’injection rapide conçues pour manipuler l’évaluation d’un agent IA ou l’inciter à prendre des mesures via des outils connectés.
Le texte et le code soumis doivent donc être traités comme des entrées non fiables, a-t-elle déclaré, les tests de vulnérabilité étant tenus à l’écart des systèmes de production et les actions importantes vérifiées de manière indépendante.
« Le prochain avantage concurrentiel ne viendra pas de la découverte plus rapide de nouvelles vulnérabilités », a déclaré Varkey. « Cela viendra de déterminer plus rapidement lesquels présentent un risque réel et lesquels ne le sont pas. »
