Forskjellen var avgjørende. GitHub utvider uttrykket før skallet kjører kommandoen. En ondsinnet sakstittel med et enkelt anførselstegn kunne derfor avslutte den tiltenkte tekststrengen og legge til kommandoer valgt av angriperen. At verdien senere ble forsøkt renset med sed, kunne ikke reparere tolkningen som allerede hadde skjedd i skallet.

At arbeidsflyten var begrenset til hendelsen issues: opened, gjorde heller ikke tittelen pålitelig. Alle som kunne opprette en sak i det offentlige repositoriet, kunne kontrollere innholdet. En kontroll som bare begrenser hvilken type GitHub-hendelse som utløser arbeidsflyten, hindrer ikke at angriperkontrollert data interpoleres i en skallkommando.

Commiten krediterte «Copilot Autofix powered by AI» som medforfatter, og den AI-assisterte gjennomgangen flagget ikke problemet. Dokumentasjonen fastslår imidlertid ikke om Copilot genererte den usikre endringen eller bare var knyttet til gjennomgangen av en endring skrevet av et menneske. Den mest presise konklusjonen er derfor at Copilot var knyttet til endringen og ikke oppdaget injeksjonen – ikke at det er bevist at modellen skrev koden.

Slik fant Red Agent feilen

Wizs Red Agent skannet Snowflakes offentlige GitHub-organisasjon etter risikable mønstre i CI/CD, altså automatiserte prosesser for bygging, testing og utrulling av kode. Agenten identifiserte Jira-arbeidsflyten som en prosess der data fra en bruker kunne havne direkte i en run:-blokk, og utledet at en spesiallaget offentlig sakstittel kunne gi vilkårlig kommando-kjøring på GitHub Actions-kjøremiljøet.

23. juni – fem dager etter at den sårbare endringen ble slått sammen – opprettet agenten en manipulert sak som del av Snowflakes program for ansvarlig sikkerhetsrapportering gjennom HackerOne. Tittelen brøt ut av skallstrengen og fikk arbeidsflyten til å sende Jira-legitimasjon til en ekstern «out-of-band»-tilbakekalling som var kontrollert for den autoriserte testen.

Dette var en godkjent sikkerhetstest, ikke et ukontrollert innbrudd. Selve sikkerhetsfunnet var likevel reelt: En offentlig sak kunne nå et arbeidsflyttrinn som håndterte interne hemmeligheter, og gjøre vanlig opprettelse av en sak om til kjøring av kommandoer.

Hvilken tilgang ble eksponert?

Den kompromitterte arbeidsflyten hadde tilgang til konfigurasjon for Snowflakes interne Jira, blant annet Jira-adresse, brukerens e-postadresse og et API-token. Tokenet som ble hentet ut, var knyttet til qa@snowflake.net. Wiz brukte det til å autentisere mot den interne Jira-portalen og undersøke mulig eksponering.

Rapporteringen beskriver lesetilgang til Jira-prosjekter innen ingeniørarbeid, sikkerhetsetterlevelse og bug bounty-aktivitet. Dokumentasjonen som foreligger, viser ikke hele tillatelsessettet til tokenet eller gir en fullstendig oversikt over alle poster som kunne nås. Den sikreste konklusjonen er derfor at tokenet ga tilgang til sensitivt internt Jira-innhold – ikke at det ga ubegrenset tilgang til Snowflakes øvrige systemer.

Det berørte området var repositoryets CI/CD-automatisering. Det er ikke rapportert om en berørt, utgitt versjon av Snowflake Connector for .NET, fordi feilen lå i GitHub Actions-arbeidsflyten og ikke i konnektorens kjøretidskode.

Snowflake svarte raskt

Wiz rapporterte feilen 23. juni. Snowflake rettet arbeidsflyten samme dag og roterte den eksponerte Jira-legitimasjonen dagen etter.

Snowflake gjennomgikk deretter revisjonsloggene og konkluderte med at Wiz var den eneste aktøren i tidsrommet der legitimasjonen kunne ha vært eksponert. Wiz opplyste også at data fra bevisføringen var slettet på en sikker måte.

Det ble ikke rapportert om uautorisert tilgang fra tredjeparter, ingen CVE-tildeling og ingen berørt konnektorutgave. Disse begrensningene beskriver den bekreftede virkningen av hendelsen, men gjør ikke den opprinnelige arbeidsflytdesignen trygg. En offentlig sakstittel skulle aldri ha blitt gjort til en del av en skallkommando i en arbeidsflyt som håndterte interne legitimasjoner.

Lærdommen for CI/CD

Lærdommen gjelder langt mer enn Snowflake og Copilot. GitHub-uttrykk som sakstitler, titler på pull requests, branchnavn og kommentarer må behandles som fiendtlige brukerdata når de sendes inn i en skallkommando.

En sikrere arbeidsflyt bør blant annet:

• sende ukontrollerte verdier gjennom miljøvariabler i stedet for å interpolere dem direkte i run:-skript
• bruke strukturerte verktøy som jq til å bygge JSON, fremfor å sette sammen skallstrenger
• sitere og validere data ved grensen mot skallet
• holde legitimasjoner unna arbeidsflyttrinn som behandler angriperkontrollert innhold, så langt det er mulig
• gjennomgå AI-genererte sikkerhetsendringer like grundig som kode skrevet av mennesker

Hendelsen viser et nytt sikkerhetsmønster: Ett AI-assistert kodesystem kan overse en farlig endring i CI/CD, mens en autonom offensiv agent kan finne og verifisere den i løpet av få dager. Automatisering kan dermed fremskynde både utnyttelse og utbedring – men den erstatter ikke uavhengig sikkerhetsgjennomgang.

Forskjellen var avgjørende. GitHub utvider uttrykket før skallet kjører kommandoen. En ondsinnet sakstittel med et enkelt anførselstegn kunne derfor avslutte den tiltenkte tekststrengen og legge til kommandoer valgt av angriperen. At verdien senere ble forsøkt renset med sed, kunne ikke reparere tolkningen som allerede hadde skjedd i skallet.

At arbeidsflyten var begrenset til hendelsen issues: opened, gjorde heller ikke tittelen pålitelig. Alle som kunne opprette en sak i det offentlige repositoriet, kunne kontrollere innholdet. En kontroll som bare begrenser hvilken type GitHub-hendelse som utløser arbeidsflyten, hindrer ikke at angriperkontrollert data interpoleres i en skallkommando.

Commiten krediterte «Copilot Autofix powered by AI» som medforfatter, og den AI-assisterte gjennomgangen flagget ikke problemet. Dokumentasjonen fastslår imidlertid ikke om Copilot genererte den usikre endringen eller bare var knyttet til gjennomgangen av en endring skrevet av et menneske. Den mest presise konklusjonen er derfor at Copilot var knyttet til endringen og ikke oppdaget injeksjonen – ikke at det er bevist at modellen skrev koden.

Slik fant Red Agent feilen

Wizs Red Agent skannet Snowflakes offentlige GitHub-organisasjon etter risikable mønstre i CI/CD, altså automatiserte prosesser for bygging, testing og utrulling av kode. Agenten identifiserte Jira-arbeidsflyten som en prosess der data fra en bruker kunne havne direkte i en run:-blokk, og utledet at en spesiallaget offentlig sakstittel kunne gi vilkårlig kommando-kjøring på GitHub Actions-kjøremiljøet.

23. juni – fem dager etter at den sårbare endringen ble slått sammen – opprettet agenten en manipulert sak som del av Snowflakes program for ansvarlig sikkerhetsrapportering gjennom HackerOne. Tittelen brøt ut av skallstrengen og fikk arbeidsflyten til å sende Jira-legitimasjon til en ekstern «out-of-band»-tilbakekalling som var kontrollert for den autoriserte testen.

Dette var en godkjent sikkerhetstest, ikke et ukontrollert innbrudd. Selve sikkerhetsfunnet var likevel reelt: En offentlig sak kunne nå et arbeidsflyttrinn som håndterte interne hemmeligheter, og gjøre vanlig opprettelse av en sak om til kjøring av kommandoer.

Hvilken tilgang ble eksponert?

Den kompromitterte arbeidsflyten hadde tilgang til konfigurasjon for Snowflakes interne Jira, blant annet Jira-adresse, brukerens e-postadresse og et API-token. Tokenet som ble hentet ut, var knyttet til qa@snowflake.net. Wiz brukte det til å autentisere mot den interne Jira-portalen og undersøke mulig eksponering.

Rapporteringen beskriver lesetilgang til Jira-prosjekter innen ingeniørarbeid, sikkerhetsetterlevelse og bug bounty-aktivitet. Dokumentasjonen som foreligger, viser ikke hele tillatelsessettet til tokenet eller gir en fullstendig oversikt over alle poster som kunne nås. Den sikreste konklusjonen er derfor at tokenet ga tilgang til sensitivt internt Jira-innhold – ikke at det ga ubegrenset tilgang til Snowflakes øvrige systemer.

Det berørte området var repositoryets CI/CD-automatisering. Det er ikke rapportert om en berørt, utgitt versjon av Snowflake Connector for .NET, fordi feilen lå i GitHub Actions-arbeidsflyten og ikke i konnektorens kjøretidskode.

Snowflake svarte raskt

Wiz rapporterte feilen 23. juni. Snowflake rettet arbeidsflyten samme dag og roterte den eksponerte Jira-legitimasjonen dagen etter.

Snowflake gjennomgikk deretter revisjonsloggene og konkluderte med at Wiz var den eneste aktøren i tidsrommet der legitimasjonen kunne ha vært eksponert. Wiz opplyste også at data fra bevisføringen var slettet på en sikker måte.

Det ble ikke rapportert om uautorisert tilgang fra tredjeparter, ingen CVE-tildeling og ingen berørt konnektorutgave. Disse begrensningene beskriver den bekreftede virkningen av hendelsen, men gjør ikke den opprinnelige arbeidsflytdesignen trygg. En offentlig sakstittel skulle aldri ha blitt gjort til en del av en skallkommando i en arbeidsflyt som håndterte interne legitimasjoner.

Lærdommen for CI/CD

Lærdommen gjelder langt mer enn Snowflake og Copilot. GitHub-uttrykk som sakstitler, titler på pull requests, branchnavn og kommentarer må behandles som fiendtlige brukerdata når de sendes inn i en skallkommando.

En sikrere arbeidsflyt bør blant annet:

• sende ukontrollerte verdier gjennom miljøvariabler i stedet for å interpolere dem direkte i run:-skript
• bruke strukturerte verktøy som jq til å bygge JSON, fremfor å sette sammen skallstrenger
• sitere og validere data ved grensen mot skallet
• holde legitimasjoner unna arbeidsflyttrinn som behandler angriperkontrollert innhold, så langt det er mulig
• gjennomgå AI-genererte sikkerhetsendringer like grundig som kode skrevet av mennesker

Hendelsen viser et nytt sikkerhetsmønster: Ett AI-assistert kodesystem kan overse en farlig endring i CI/CD, mens en autonom offensiv agent kan finne og verifisere den i løpet av få dager. Automatisering kan dermed fremskynde både utnyttelse og utbedring – men den erstatter ikke uavhengig sikkerhetsgjennomgang.