Cosa Ha Violato Realmente l'Agente di Wiz

Wiz ha costruito un agente IA autonomo chiamato Red Agent per cercare falle sfruttabili come farebbe un penetration tester umano, e poi agire in base a ciò che trova. Puntato sui repository pubblici GitHub di Snowflake, ha trovato una falla di script injection in un file di workflow GitHub Actions chiamato jira_issue.yml all'interno di snowflakedb/snowflake-connector-net, il connettore .NET open source di Snowflake. La falla permetteva a chiunque di aprire una issue su GitHub con un titolo appositamente creato e far eseguire all'automazione di Snowflake parte di quel titolo come comando shell, senza bisogno di accesso.

Il primo tentativo di Red Agent è fallito. Il runner ha restituito un errore di sintassi invece di eseguire il payload. Invece di fermarsi, l'agente ha letto l'errore, ha riscritto da solo il titolo dell'issue manipolato e ha riprovato. Il secondo tentativo è uscito dalla stringa shell e ha raggiunto un dominio controllato dall'attaccante, esfiltrando nel processo un token API di Jira codificato in base64. Scoperta, adattamento, sfruttamento e verifica dell'accesso ottenuto sono avvenuti tutti in un'unica sessione, senza che un umano decidesse il passo successivo.

Il token rubato era valido ed era autenticato come account di servizio di Snowflake, garantendo accesso in lettura a un'istanza Jira interna che copriva progetti di ingegneria, conformità alla sicurezza e tracciamento delle bug bounty. Il codice vulnerabile era attivo dal merge della PR #1218 del 18 giugno 2026, che aveva sostituito un pattern di parsing sicuro con l'interpolazione diretta di variabili in un comando shell. Snowflake lo ha corretto il 23 giugno 2026, ripristinando il pattern sicuro, e ha revocato e rinnovato il token esposto; un controllo dei log non ha trovato prove che una parte esterna lo avesse usato durante la finestra di esposizione di cinque giorni.

Wiz Ha Indicato Copilot Come Coautore della Falla

Il resoconto originale di Wiz ha segnalato il commit che ha introdotto la falla e ha notato che GitHub Copilot Autofix vi appariva come coautore. La narrazione si è scritta da sola: un assistente di coding IA sembrava aver contribuito a scrivere lo stesso bug che un agente di sicurezza IA ha poi trovato e sfruttato in autonomia, su entrambi i fronti.

La riga del coautore era reale, e i merge squash fanno sembrare quel tipo di prova più solida di quanto sia. Una pull request può contenere molti commit individuali da molti collaboratori, ma un merge squash li unisce tutti in un unico commit sul branch principale, e ogni riga di coautore di ciascuno di quei commit viene trascinata nel risultato unito. Un nome su quella riga registra la partecipazione da qualche parte nella pull request, non la paternità di una riga specifica. Quando Wiz ha aggiornato il proprio post il 17 agosto 2026, il linguaggio si era già ammorbidito fino ad ammettere che non era chiaro se Copilot avesse contribuito affatto alle righe vulnerabili.

La Cronologia dei Commit di GitHub Dice che l'Ha Scritto un Umano

GitHub ha condotto una propria revisione interna dello stesso repository ed è giunta a una conclusione diversa. Secondo GitHub, un ingegnere umano di Snowflake ha scritto la modifica insicura, in un commit separato datato 25 agosto 2025, circa dieci mesi prima che la pull request vulnerabile venisse unita, e Copilot Autofix non ha né revisionato né contribuito a quelle righe specifiche.

Il commit effettivo di coautore di Copilot all'interno della pull request #1218 ha modificato un file diverso, jira_close.yml, non correlato alle righe vulnerabili di jira_issue.yml sfruttate da Red Agent. Quando la pull request è stata compressa in un unico commit di merge, la riga di coautore di Copilot ha viaggiato comunque con esso, attaccata a una modifica che non aveva mai toccato.

La disputa è ora pubblica con due versioni incompatibili e nessun arbitro indipendente. Wiz indica una riga di coautore nella cronologia dei commit; GitHub indica una revisione interna dello stesso repository che legge la paternità in modo diverso. Nessuno al di fuori delle due società ha l'accesso necessario per stabilire quale lettura sia corretta.

Il Vuoto di Governance che Ogni Team Assistito da IA Dovrebbe Notare

Eseguire un assistente di coding IA e uno scanner di sicurezza IA nella stessa pipeline sta rapidamente diventando la configurazione predefinita, non l'eccezione. Quando qualcosa va storto in questa configurazione, sia la parte che trova il bug sia lo strumento accusato di averlo scritto possono essere entrambi sistemi IA, e l'unica prova a cui entrambe le parti possono fare riferimento è la cronologia dei commit di un repository. Quella cronologia è affidabile solo quanto le pratiche che l'hanno prodotta, e un merge squash di routine ha appena dimostrato che può attaccare il nome di un collaboratore all'errore di un altro senza che nessuno lo intendesse.

Il bug stesso è rimasto esposto per cinque giorni e ne ha impiegati altri cinque per essere corretto. La discussione su chi lo abbia scritto è durata più a lungo della vulnerabilità stessa, ed è avvenuta tra due fornitori con le risorse e l'accesso al repository per indagare correttamente. Una società con meno disciplina nel preservare la cronologia dei commit dei propri file di workflow, e senza una risposta stabilita su chi in società sia autorizzato a pubblicare un'affermazione di paternità prima che diventi una disputa pubblica, non risolverà la propria versione in modo altrettanto netto.

Da leggere ora: Una quota valeva più di tutti e tre i fondi  |  Un modello di frontiera ritirato è di nuovo online