L'Agent IA de Wiz a Piraté Snowflake, Puis a Accusé Copilot

Ce Que l'Agent de Wiz a Réellement Compromis

Wiz a construit un agent IA autonome appelé Red Agent pour rechercher des failles exploitables comme le ferait un testeur d'intrusion humain, puis agir selon ce qu'il trouve. Pointé sur les dépôts GitHub publics de Snowflake, il a trouvé une faille d'injection de script dans un fichier de workflow GitHub Actions nommé jira_issue.yml à l'intérieur de snowflakedb/snowflake-connector-net, le connecteur .NET open source de Snowflake. La faille permettait à quiconque d'ouvrir une issue GitHub avec un titre spécialement conçu et de faire exécuter par l'automatisation de Snowflake une partie de ce titre comme commande shell, sans connexion requise.

La première tentative de Red Agent a échoué. Le runner a renvoyé une erreur de syntaxe au lieu d'exécuter la charge utile. Plutôt que de s'arrêter là, l'agent a lu l'erreur, a réécrit de lui-même le titre manipulé de l'issue et a réessayé. La deuxième tentative est sortie de la chaîne shell et a atteint un domaine contrôlé par l'attaquant, exfiltrant au passage un jeton d'API Jira encodé en base64. Découverte, ajustement, exploitation et vérification de l'accès obtenu se sont tous produits en une seule session, sans qu'aucun humain ne décide de l'étape suivante.

Le jeton volé était valide et authentifié comme un compte de service Snowflake, accordant un accès en lecture à une instance Jira interne couvrant des projets d'ingénierie, de conformité sécurité et de suivi des primes aux bugs. Le code vulnérable était actif depuis la fusion de la PR #1218 le 18 juin 2026, qui avait remplacé un schéma d'analyse sécurisé par une interpolation directe de variables dans une commande shell. Snowflake l'a corrigé le 23 juin 2026, restaurant le schéma sécurisé, et a révoqué et renouvelé le jeton exposé ; un audit des journaux n'a trouvé aucune preuve qu'une partie externe l'ait utilisé pendant la fenêtre d'exposition de cinq jours.

Wiz a Désigné Copilot Comme Coauteur du Bug

Le rapport original de Wiz a pointé le commit qui a introduit la faille et a noté que GitHub Copilot Autofix y apparaissait comme coauteur. Le récit s'est écrit tout seul : un assistant de codage IA semblait avoir aidé à écrire exactement le bug qu'un agent de sécurité IA a ensuite trouvé et exploité de façon autonome, des deux côtés.

La ligne de coauteur était réelle, et les fusions squash font paraître ce genre de preuve plus solide qu'elle ne l'est. Une pull request peut contenir de nombreux commits individuels de nombreux contributeurs, mais une fusion squash les regroupe tous en un seul commit sur la branche principale, et chaque ligne de coauteur de chacun de ces commits voyage avec lui jusqu'au résultat combiné. Un nom sur cette ligne enregistre une participation quelque part dans la pull request, pas la paternité d'une ligne précise. Au moment où Wiz a mis à jour son article le 17 août 2026, son propre langage s'était déjà assoupli jusqu'à reconnaître qu'il n'était pas clair si Copilot avait contribué aux lignes vulnérables.

L'Historique des Commits de GitHub Dit Qu'un Humain l'a Écrit

GitHub a mené son propre examen interne du même dépôt et est arrivé à une conclusion différente. Selon GitHub, un ingénieur humain de Snowflake a écrit le remaniement dangereux, dans un commit distinct daté du 25 août 2025, environ dix mois avant que la pull request vulnérable ne soit fusionnée, et Copilot Autofix n'a ni examiné ni contribué à ces lignes précises.

Le commit réel de coauteur de Copilot au sein de la pull request #1218 a modifié un fichier différent, jira_close.yml, sans rapport avec les lignes vulnérables de jira_issue.yml que Red Agent a exploitées. Quand la pull request a été compressée en un seul commit de fusion, la ligne de coauteur de Copilot a voyagé quand même avec lui, attachée à une modification qu'elle n'avait jamais touchée.

Le différend est maintenant public, avec deux récits incompatibles et aucun arbitre indépendant. Wiz pointe une ligne de coauteur dans l'historique des commits vivant ; GitHub pointe un examen interne du même dépôt qui interprète la paternité différemment. Personne en dehors des deux entreprises n'a l'accès nécessaire pour déterminer quelle lecture est correcte.

Le Vide de Gouvernance Que Toute Équipe Assistée par l'IA Devrait Remarquer

Faire fonctionner un assistant de codage IA et un scanner de sécurité IA dans le même pipeline devient rapidement la configuration par défaut, pas l'exception. Quand quelque chose tourne mal dans cette configuration, la partie qui trouve le bug et l'outil accusé de l'avoir écrit peuvent tous deux être des systèmes IA, et la seule preuve à laquelle l'une ou l'autre partie peut se référer est l'historique des commits d'un dépôt. Cet historique n'est fiable qu'à hauteur des pratiques qui l'ont produit, et une fusion squash de routine vient de prouver qu'elle peut attacher le nom d'un contributeur à l'erreur d'un autre sans que personne ne l'ait voulu.

Le bug lui-même est resté exposé cinq jours et en a demandé cinq de plus pour être corrigé. Le débat sur qui l'a écrit a duré plus longtemps que la vulnérabilité elle-même, et il a eu lieu entre deux fournisseurs disposant des ressources et de l'accès au dépôt pour enquêter correctement. Une entreprise avec moins de discipline pour préserver l'historique des commits de ses propres fichiers de workflow, et sans réponse établie sur qui, en interne, est autorisé à publier une affirmation d'attribution avant qu'elle ne devienne un différend public, ne réglera pas sa version aussi proprement.

À lire ensuite: Une seule ligne valait plus que les trois fonds  |  Un modèle de frontière retiré est de nouveau en ligne