Le cas Wiz et Snowflake ne doit pas être lu comme une nouvelle compromission de clients ni comme la preuve que les assistants de code fondés sur l’AI sont dangereux par nature. La leçon utile est plus précise : une issue GitHub publique peut devenir une entrée d’automatisation interne, et si cette entrée est collée dans une commande shell de GitHub Actions, elle cesse d’être un simple texte. Wiz Research indique que son outil autonome Red Agent a trouvé une injection dans un workflow du dépôt public snowflakedb/snowflake-connector-net, ouvert une issue préparée, reçu un callback depuis un runner GitHub Actions et obtenu un Jira API token. Snowflake a corrigé le workflow, fait tourner le jeton et, selon les éléments publics, n’a pas trouvé d’accès non autorisé hors recherche autorisée.

Schéma neutre montrant une issue GitHub publique entrant dans un workflow CI et un jeton Jira interne verrouillé

Ce qui s’est passé

Le mécanisme de départ est banal. Un dépôt public reliait des issues GitHub à des processus Jira internes via GitHub Actions. Beaucoup d’équipes utilisent ce type de colle : création de ticket, synchronisation d’état, notification Slack, fermeture automatique. Le risque apparaît quand le workflow traite du texte contrôlé par des utilisateurs externes comme une commande fiable. Le titre d’une issue, son corps, un nom de branche, un titre de pull request ou un commentaire peuvent être influencés depuis l’extérieur.

Wiz explique que Red Agent a analysé l’organisation GitHub publique de Snowflake et détecté une script injection dans .github/workflows/jira_issue.yml. Le workflow se déclenchait sur issues: opened. Selon Wiz, le titre contrôlé par l’attaquant était interpolé directement dans un bloc shell run:. Un premier essai a produit une erreur bash, puis l’agent a adapté son approche et reçu une réponse externe du runner contenant des identifiants encodés. Le jeton Jira s’authentifiait comme [email protected] dans l’environnement Atlassian de Snowflake et donnait un accès en lecture à des projets d’ingénierie, de conformité sécurité et de suivi bug bounty.

La chronologie est essentielle. Le PR #1218, “SNOW-2069227 : Update jira workflows”, a été fusionné le 18 juin 2026. Wiz dit avoir trouvé, testé et signalé le problème le 23 juin. Le PR correctif #1402 a été fusionné le même jour et le jeton a été renouvelé le 24 juin. Wiz a publié son analyse le 17 août; The Hacker News l’a reprise le 18 août en précisant qu’aucune version affectée du Snowflake Connector for .NET n’était identifiée, qu’aucun CVE ni CISA KEV public n’était connu et qu’aucune compromission client publique n’était établie.

Pourquoi c’est important maintenant

L’affaire résonne parce qu’elle relie deux mouvements. Les assistants de code sont entrés dans le développement courant, et les revues automatiques de sécurité accompagnent de nombreux pull requests. Dans le même temps, des agents autonomes peuvent lire des dépôts publics, reconnaître des classes connues de vulnérabilités, tenter un chemin, observer une erreur et s’adapter. Cela ne transforme pas chaque agent en super-attaquant, mais réduit le délai entre l’erreur et la preuve fonctionnelle.

La réponse mature n’est ni l’interdiction de Copilot ni la confiance aveugle. Elle consiste à traiter les changements dans .github/workflows, les scripts de déploiement, les identifiants cloud, les jetons Jira, la signature de release et la publication de paquets comme du code sensible. Un commentaire de bot ou une revue automatisée ne suffit pas à prouver la sécurité.

Injection de workflow sans mode d’emploi offensif

Un titre d’issue est une donnée tant qu’il reste stocké comme texte. Il devient dangereux si le workflow l’insère directement dans une commande shell. Si la chaîne contient des caractères interprétés par le shell, le runner peut exécuter autre chose que prévu.

Le modèle sûr consiste à garder les valeurs non fiables hors du texte de commande. On les place dans des variables d’environnement, on les cite correctement, on les passe aux outils comme des données et on utilise des encodeurs structurés comme jq --arg pour construire du JSON. GitHub a déjà documenté ce risque : les contextes tels que titres d’issues et noms de branches ne doivent pas être développés sans protection dans run:. Ce n’est pas un problème propre à Snowflake ou à Jira; il apparaît dès que YAML de CI/CD mélange métadonnées publiques, shell et secrets.

Les dépôts publics comme surface d’attaque

Un dépôt public n’est pas seulement une page de code. Il peut déclencher de l’automatisation. Une issue, un commentaire, une étiquette ou une branche peuvent lancer des workflows sur des runners hébergés ou internes. Ces workflows peuvent contenir des jetons pour Jira, Slack, registres de paquets, clouds ou outils de release.

issues: opened est donc une entrée non fiable depuis internet. Si le workflow utilise un jeton interne, le dépôt public est connecté à l’infrastructure de l’entreprise. Même un accès en lecture n’est pas anodin : Jira peut révéler vulnérabilités ouvertes, triage, noms internes, feuilles de route et informations de conformité. Pour un attaquant, cette lecture devient une carte.

Où intervient l’AI

L’angle AI est réel mais doit rester précis. Wiz a associé l’affaire à un PR assisté par Copilot et à Red Agent comme outil autonome. Le billet a ensuite clarifié que Copilot était co-auteur ou vérificateur du PR fusionné et l’avait marqué comme correct, sans preuve publique que Copilot ait écrit les lignes vulnérables. La conclusion n’est donc pas “Copilot a créé la faille”. Elle est que l’assistance automatique n’a pas empêché une classe connue de faille CI/CD.

Red Agent montre l’autre côté : des outils autonomes autorisés peuvent trouver et valider rapidement des erreurs. Les défenseurs doivent s’attendre à ce que des agents appliquent à grande échelle des patterns anciens à de nouveaux dépôts.

Pas une compromission client, mais un signal sérieux

Les éléments publics ne montrent pas de vol de données clients. THN indique que la faiblesse était limitée à l’automatisation CI/CD du dépôt et qu’aucune version affectée du connecteur n’était identifiée. Wiz écrit que Snowflake a vérifié les journaux et que Wiz était le seul acteur pendant la fenêtre d’exposition. Le jeton a été renouvelé.

Cela fixe le périmètre, sans annuler la leçon. Un secret CI/CD exposé reste important, même si un chercheur autorisé le trouve et si la correction est rapide. Les tickets internes de sécurité peuvent donner du contexte, des priorités et des chemins d’attaque.

Contrôles à mettre en place

Inventoriez les workflows, surtout ceux déclenchés par issues, issue_comment, pull_request, pull_request_target, discussion et les entrées manuelles. Notez les secrets accessibles, les systèmes appelés et le type de runner. Cherchez les expansions directes de contextes GitHub dans run: : issue titles, bodies, noms de branches, titres de PR et commentaires.

Réduisez les permissions. Définissez explicitement permissions, évitez les secrets dans les workflows déclenchés par des événements publics, utilisez OIDC ou des jetons courts quand c’est possible, et placez les étapes privilégiées derrière une validation de mainteneur. Exigez une revue de code owner pour .github/workflows/**, scripts de déploiement et release helpers. Conservez les logs assez longtemps pour relier usage de jeton et exécution de workflow.

Gouvernance des changements assistés par AI

Les changements générés ou relus par AI ont besoin d’une politique fondée sur le risque. Étiqueter les commits peut aider l’audit, mais le contrôle principal reste la revue humaine sur les zones sensibles : CI/CD, identité, secrets, releases et chemins vers des données clients. Les scanners et assistants réduisent la charge; ils ne remplacent pas la responsabilité.

La conclusion est calme : l’AI n’annule pas les bases d’AppSec, elle accélère les deux camps. Le temps entre un merge vulnérable et une preuve de concept peut tomber à quelques jours ou heures. Traitez le YAML CI/CD comme du code de production avec secrets. Les issues publiques sont des entrées utilisateur; elles ont besoin de frontières, et les secrets ont besoin de périmètres.