Comment mandiant accélère l’analyse de sécurité du code avec l’IA

La revue de code par IA gagne en crédibilité grâce à des contraintes expertes

Google Cloud indique que son Agentic Vulnerability Discovery Harness a trouvé plus de 100 vulnérabilités critiques avérées en deux jours lors d’un incident impliquant des dépôts d’entreprise volés. Alex Tselevich et Michael Maturi, auteurs du compte rendu de Google Cloud, décrivent un système qui place des contrôles experts autour des modèles.

Mandiant utilise ce système dans les évaluations de sécurité et les interventions de réponse à incident. Ses agents IA, des composants pilotés par des modèles auxquels sont confiées des tâches d’investigation précises, parcourent le code, collectent le contexte, retracent les chemins d’exécution et génèrent des hypothèses de vulnérabilité. Des experts humains apportent des connaissances spécialisées, approuvent le modèle de menace et reproduisent les exploits suspectés avant qu’une conclusion ne soit retenue. Le système élargit la quantité de code que les experts peuvent examiner tout en laissant le jugement final en matière de sécurité aux personnes.

Ces affirmations proviennent de Google Cloud et de Mandiant, qui ont un intérêt commercial à démontrer la valeur de cette approche. Google Cloud soutient que le vol de code source propriétaire crée un sentiment d’urgence, car les attaquants peuvent rapidement utiliser des outils automatisés pour y rechercher des faiblesses exploitables.

L’écart entre la revue manuelle et l’analyse conventionnelle

La revue du code source a un problème de passage à l’échelle. Tselevich et Maturi indiquent que Mandiant a appliqué le harness à des environnements contenant des dizaines de millions de lignes de code. Une revue manuelle à cette échelle exige un temps d’expertise considérable.

L’analyse statique conventionnelle automatise certaines parties du travail. Tselevich et Maturi estiment que ces outils peuvent avoir du mal avec la logique métier, l’atteignabilité de l’exécution et la distinction entre les fonctions privilégiées et celles exposées au public. Ces distinctions peuvent déterminer si un code suspect expose un chemin exploitable.

L’Agentic Vulnerability Discovery Harness combine une investigation automatisée avec des décisions d’experts à des étapes définies. Tselevich et Maturi le décrivent comme une architecture à un instant donné.

L’architecture place l’expertise autour des modèles

Le harness utilise un pipeline séquentiel qui divise l’investigation en étapes spécialisées. Tselevich et Maturi affirment que cette structure rend l’analyse plus prévisible et réduit le comportement erratique des modèles.

La modélisation des menaces vient en premier. Un agent explorateur identifie le domaine logiciel, lit la documentation et marque des répertoires tels que les tests unitaires pour exclusion. Des sous-agents spécialisés examinent des domaines comme l’authentification, l’autorisation et le routage, puis un agent de synthèse combine leur travail dans un modèle de menace.

Un consultant humain doit vérifier ce modèle avant que l’analyse plus large ne se poursuive. Ce point de contrôle détermine ce que le système automatisé considère comme important et dans le périmètre.

La phase suivante recherche dans chaque fichier du périmètre les points d’entrée, c’est-à-dire les emplacements où des requêtes, des messages ou d’autres entrées externes pénètrent dans le logiciel. Cela inclut les routes HTTP et les écouteurs de communication interprocessus. Des agents supplémentaires collectent le code environnant, en intégrant à l’analyse les sanitizers, les contrôles d’autorisation et les appels de fonctions imbriqués afin qu’une fonction suspecte puisse être évaluée dans son contexte d’exécution.

Une inspection plus approfondie sépare l’analyse du flux de contrôle de l’analyse du flux de données. L’analyse du flux de contrôle examine les chemins que l’exécution du programme peut emprunter. Ses agents recherchent des problèmes de contrôle d’accès, notamment des autorisations manquantes, des élévations de privilèges et des falsifications de requêtes intersites.

L’analyse du flux de données suit la manière dont l’information circule dans le logiciel. Ses agents suivent les entrées contrôlées par l’utilisateur pour déterminer si elles peuvent atteindre des fonctions dangereuses associées à l’injection SQL, au cross-site scripting, à l’injection de commandes et à la traversée de répertoires.

Les consultants Mandiant encodent également des connaissances spécialisées dans des règles structurées couvrant les domaines logiciels, les langages de programmation, les frameworks et les classes de vulnérabilités individuelles. Tselevich et Maturi indiquent que ces règles capturent les endroits où les frameworks définissent les points d’entrée, la manière dont ils se comportent et comment des failles particulières doivent être trouvées et validées.

Plusieurs agents de validation mettent à l’épreuve les hypothèses générées par l’IA. Une étape de synthèse classe une faille suspectée comme confirmée, infirmée ou rejetée. Les conclusions confirmées sont évaluées en termes de risque et dédupliquées.

La revue humaine constitue le dernier filtre. Les évaluateurs tentent de reproduire les exploits et de tester le code de preuve de concept. Les conclusions qui échouent aux tests dynamiques sont écartées. Tselevich et Maturi indiquent que cette étape élimine les faux positifs et détecte les hypothèses incorrectes des modèles.

Les déploiements signalés établissent l’échelle opérationnelle

Tselevich et Maturi indiquent que Mandiant a utilisé le système au cours des 10 derniers mois dans des revues de code proactives, des tests d’intrusion, des opérations de red team et des enquêtes menées après des vols de code source.

À l’échelle de grandes bases de code, ils rapportent que le processus a généré des milliers de pipelines d’analyse et des dizaines de milliers de conclusions. Les revues ont mis au jour des dizaines de failles dans des extensions web et des projets open source. Ils indiquent que 12 identifiants Common Vulnerabilities and Exposures ont été attribués jusqu’à présent, avec environ une douzaine de problèmes supplémentaires en cours de divulgation.

Ils décrivent également une mission client dans laquelle le harness a traité le code source de l’application web d’un client et a rapidement identifié une vulnérabilité d’exécution de code à distance qui fournissait une voie d’accès initiale à l’environnement cible.

Ces résultats sont rapportés par des employés de Google Cloud à propos d’une technologie utilisée par Mandiant, qui fait partie de Google Cloud. Les deux organisations en tirent un bénéfice commercial lorsque les clients perçoivent de la valeur dans leurs capacités de sécurité. Ces cas établissent un usage signalé et une échelle opérationnelle. Les performances comparatives plus larges entre organisations, bases de code et méthodes de revue constituent une question distincte.

L’évaluation distingue la découverte de la mémorisation

Le rôle des spécialistes définit l’autonomie du système. Les experts vérifient le modèle de menace, apportent des connaissances de sécurité structurées, reproduisent les exploits et écartent les conclusions qui échouent aux tests. Cette conception soutient une proposition plus étroite : l’IA peut faire passer à l’échelle une investigation dirigée et arbitrée par des experts en sécurité.

Tselevich et Maturi décrivent également une évaluation conçue pour traiter la contamination par les données d’entraînement des modèles. Les jeux de données publics sur les vulnérabilités peuvent contenir des failles rencontrées pendant l’entraînement du modèle, ce qui peut donner l’impression qu’un modèle découvre une vulnérabilité alors qu’il rappelle en réalité des informations qu’il a déjà vues.

L’évaluation utilise des bases de code synthétiques internes avec des vulnérabilités injectées. Des experts humains vérifient ces failles. Un processus de notation compare les conclusions du système à la vérité terrain connue, c’est-à-dire les réponses vérifiées utilisées comme référence pour l’évaluation, avant qu’une revue manuelle ne contrôle les résultats. Cette conception vise à distinguer la découverte de vulnérabilités du rappel de vulnérabilités publiques.

Ce test traite la mémorisation. Les performances comparatives par rapport à d’autres approches de revue constituent une question distincte. Les déploiements signalés et l’évaluation synthétique étayent des affirmations différentes et doivent être évalués séparément.

L’arbitrage expert fixe la limite opérationnelle

Pour un responsable de la sécurité, la décision consiste à déterminer si ce workflow conçu par des experts peut accroître la quantité de code qu’une équipe peut examiner lorsque le temps et l’échelle limitent la revue manuelle. La capacité du modèle n’est qu’un élément de cette décision. Les contrôles qui l’entourent déterminent à quel moment le jugement spécialisé intervient dans le processus et quelles preuves sont requises avant qu’un soupçon généré par l’IA ne devienne une conclusion de sécurité.

Tselevich et Maturi décrivent la stratégie comme le fait d’« intégrer des modèles de pointe dans un harness défini par des experts » afin d’automatiser la découverte de vulnérabilités courantes. Dans le workflow qu’ils décrivent, la frontière déterminante se situe au niveau de la validation : les évaluateurs tentent de reproduire l’exploit et écartent les conclusions qui échouent aux tests dynamiques. Ce filtre humain détermine quelles hypothèses générées par la machine deviennent des conclusions sur lesquelles une équipe de sécurité peut agir.

Points clés

• Les contrôles experts rendent la revue de code par IA plus crédible : Mandiant indique avoir trouvé plus de 100 vulnérabilités critiques en deux jours en combinant des agents IA avec la modélisation des menaces par des experts, la validation et la reproduction des exploits. Les dirigeants devraient évaluer les contrôles qui encadrent la découverte par IA.
• L’IA peut étendre la revue de sécurité au-delà de l’échelle manuelle : Mandiant a appliqué son harness à des bases de code contenant des dizaines de millions de lignes, tandis que l’analyse conventionnelle peut manquer la logique métier et le contexte d’exécution. Les équipes de sécurité devraient examiner où l’analyse agentique peut compléter la revue manuelle et l’analyse statique.
• Les agents spécialisés ont besoin de points de contrôle humains définis : Le harness sépare la modélisation des menaces, la découverte des points d’entrée, l’analyse du flux de contrôle, l’analyse du flux de données et la validation. L’approbation humaine du modèle de menace et des conclusions finales maintient les jugements de sécurité déterminants entre les mains des spécialistes.
• Les déploiements signalés montrent l’échelle : Google Cloud affirme que le système a généré des milliers de pipelines d’analyse, des dizaines de milliers de conclusions et plusieurs CVE. Les acheteurs devraient considérer ces résultats rapportés par le fournisseur comme une preuve d’échelle opérationnelle tout en recherchant des benchmarks indépendants ou comparatifs.
• L’évaluation doit distinguer la découverte de la mémorisation : Mandiant teste le système sur des bases de code synthétiques internes avec des vulnérabilités injectées et vérifiées par des experts afin de réduire le risque que les modèles ne fassent que rappeler des failles publiques issues des données d’entraînement. Les dirigeants qui évaluent des outils de sécurité IA devraient demander comment les benchmarks contrôlent la contamination par les données d’entraînement.
• L’arbitrage humain reste la limite opérationnelle : Les agents IA peuvent accroître la quantité de code examinée par les équipes de sécurité, mais Mandiant exige que les évaluateurs reproduisent les exploits et rejettent les conclusions qui échouent aux tests dynamiques. Les organisations qui adoptent des systèmes similaires devraient préserver des filtres humains explicites avant que des hypothèses générées par l’IA ne deviennent des conclusions exploitables.