Det var en afgørende forskel. GitHub udvider udtrykket, før shellen udfører kommandoen. En ondsindet issue-titel med et enkelt anførselstegn kunne derfor lukke den tiltænkte tekststreng og tilføje shell-kommandoer efter angriberens eget valg. At rense værdien bagefter med sed kunne ikke ophæve den fortolkning, der allerede havde fundet sted i shellen.

Workflowets trigger, issues: opened, gjorde heller ikke titlen pålidelig. Enhver bruger, der kunne oprette en issue i det offentlige repository, kunne styre titlen. En hændelsesbetingelse, der begrænsede workflowet til issue-aktivitet, forhindrede ikke, at angriberstyrede data blev interpoleret i shell-koden.

Committen krediterede “Copilot Autofix powered by AI” som medforfatter, og den AI-assisterede gennemgang markerede ikke problemet. Men materialet fastslår ikke, om Copilot genererede den usikre ændring eller gennemgik en ændring skrevet af et menneske. Den mest præcise konklusion er derfor, at Copilot var knyttet til ændringen og ikke opdagede injektionen – ikke at det er bevist, at modellen skrev koden.

Sådan fandt Red Agent sårbarheden

Wiz’ Red Agent scannede Snowflakes offentlige GitHub-organisation for risikable CI/CD-mønstre. Agenten identificerede Jira-workflowet som et sted, hvor data fra en upålidelig issue blev brugt i en shell-run:-blok. Den vurderede, at en særligt udformet offentlig issue-titel kunne føre til vilkårlig kommandoeksekvering på den GitHub-hostede Actions-runner.

Den 23. juni – fem dage efter at den sårbare ændring var blevet lagt sammen – oprettede agenten en manipuleret issue som led i Snowflakes HackerOne-program. Titlen brød ud af shell-strengen og fik workflowet til at sende Jira-legitimationsoplysninger til et out-of-band-callback, som var kontrolleret til det godkendte proof of concept.

Der var tale om en sanktioneret sikkerhedstest og ikke et ukontrolleret indbrud. Selve sikkerhedsfundamentet var dog reelt: En offentlig issue kunne nå et workflow-trin, der håndterede legitimationsoplysninger, og forvandle almindelig issue-oprettelse til kommandoeksekvering.

Hvilken adgang blev eksponeret?

Det kompromitterede workflow havde adgang til Snowflakes interne Jira-konfiguration, herunder Jira-URL, brugerens e-mailadresse og en API-token. Den fundne token var knyttet til qa@snowflake.net. Wiz brugte den til at logge ind på den interne Jira-portal og vurdere den mulige eksponering.

Rapporteringen beskrev læseadgang til Jira-projekter inden for engineering, sikkerhed og compliance samt bug bounty-aktiviteter. Det tilgængelige materiale fastslår ikke tokenens fulde rettighedssæt eller giver en endelig oversigt over alle poster, der kunne nås. Den bedst dokumenterede konklusion er derfor, at tokenen gav adgang til følsomt internt Jira-indhold – ikke at den gav ubegrænset adgang til Snowflakes øvrige systemer.

Den sårbare komponent var repositoryets CI/CD-automatisering. Der blev ikke rapporteret om en berørt udgivet version af Snowflake Connector for .NET, fordi fejlen lå i GitHub Actions-workflowet og ikke i connectorens runtime-kode.

Snowflakes reaktion

Wiz rapporterede problemet 23. juni. Snowflake rettede workflowet samme dag og roterede den eksponerede Jira-legitimationsoplysning dagen efter.

Snowflake gennemgik derefter auditloggene og konkluderede, at Wiz var den eneste aktør i eksponeringsperioden. Wiz oplyste samtidig, at alle data fra proof of concept var blevet slettet på sikker vis.

Der blev ikke rapporteret om uautoriseret adgang fra tredjeparter, ingen CVE-tildeling og ingen berørt connector-udgivelse. Disse forhold afgrænser den bekræftede konsekvens – men gør ikke det oprindelige workflow-design sikkert. En offentlig issue-titel burde aldrig have kunnet blive en del af en shell-kommando i et workflow, der håndterede interne legitimationsoplysninger.

Lektionen for CI/CD-sikkerhed

Læringen rækker længere end Snowflake og Copilot. GitHub-udtryk som issue-titler, pull request-titler, branchenavne og kommentarer bør behandles som potentielt ondsindede input, når de føres ind i shell-kommandoer.

Et sikrere workflow bør blandt andet:

• Sende upålidelige værdier via miljøvariabler i stedet for at indsætte dem direkte i run:-scripts.
• Bruge strukturerede værktøjer som jq til at opbygge JSON i stedet for at samle shell-strenge manuelt.
• Citere og validere data ved overgangen til shellen.
• Holde legitimationsoplysninger ude af trin, der behandler angriberstyret indhold, når det er muligt.
• Gennemgå AI-genererede sikkerhedsændringer lige så grundigt som kode skrevet af mennesker.

Episoden viser et nyt sikkerhedsmønster med stor tydelighed: Ét AI-baseret kodningssystem kan overse en farlig CI/CD-ændring, mens en autonom offensiv agent finder og validerer den få dage senere. Automatisering kan fremskynde både afhjælpning og udnyttelse – men den kan ikke erstatte uafhængig sikkerhedsgennemgang.

Det var en afgørende forskel. GitHub udvider udtrykket, før shellen udfører kommandoen. En ondsindet issue-titel med et enkelt anførselstegn kunne derfor lukke den tiltænkte tekststreng og tilføje shell-kommandoer efter angriberens eget valg. At rense værdien bagefter med sed kunne ikke ophæve den fortolkning, der allerede havde fundet sted i shellen.

Workflowets trigger, issues: opened, gjorde heller ikke titlen pålidelig. Enhver bruger, der kunne oprette en issue i det offentlige repository, kunne styre titlen. En hændelsesbetingelse, der begrænsede workflowet til issue-aktivitet, forhindrede ikke, at angriberstyrede data blev interpoleret i shell-koden.

Committen krediterede “Copilot Autofix powered by AI” som medforfatter, og den AI-assisterede gennemgang markerede ikke problemet. Men materialet fastslår ikke, om Copilot genererede den usikre ændring eller gennemgik en ændring skrevet af et menneske. Den mest præcise konklusion er derfor, at Copilot var knyttet til ændringen og ikke opdagede injektionen – ikke at det er bevist, at modellen skrev koden.

Sådan fandt Red Agent sårbarheden

Wiz’ Red Agent scannede Snowflakes offentlige GitHub-organisation for risikable CI/CD-mønstre. Agenten identificerede Jira-workflowet som et sted, hvor data fra en upålidelig issue blev brugt i en shell-run:-blok. Den vurderede, at en særligt udformet offentlig issue-titel kunne føre til vilkårlig kommandoeksekvering på den GitHub-hostede Actions-runner.

Den 23. juni – fem dage efter at den sårbare ændring var blevet lagt sammen – oprettede agenten en manipuleret issue som led i Snowflakes HackerOne-program. Titlen brød ud af shell-strengen og fik workflowet til at sende Jira-legitimationsoplysninger til et out-of-band-callback, som var kontrolleret til det godkendte proof of concept.

Der var tale om en sanktioneret sikkerhedstest og ikke et ukontrolleret indbrud. Selve sikkerhedsfundamentet var dog reelt: En offentlig issue kunne nå et workflow-trin, der håndterede legitimationsoplysninger, og forvandle almindelig issue-oprettelse til kommandoeksekvering.

Hvilken adgang blev eksponeret?

Det kompromitterede workflow havde adgang til Snowflakes interne Jira-konfiguration, herunder Jira-URL, brugerens e-mailadresse og en API-token. Den fundne token var knyttet til qa@snowflake.net. Wiz brugte den til at logge ind på den interne Jira-portal og vurdere den mulige eksponering.

Rapporteringen beskrev læseadgang til Jira-projekter inden for engineering, sikkerhed og compliance samt bug bounty-aktiviteter. Det tilgængelige materiale fastslår ikke tokenens fulde rettighedssæt eller giver en endelig oversigt over alle poster, der kunne nås. Den bedst dokumenterede konklusion er derfor, at tokenen gav adgang til følsomt internt Jira-indhold – ikke at den gav ubegrænset adgang til Snowflakes øvrige systemer.

Den sårbare komponent var repositoryets CI/CD-automatisering. Der blev ikke rapporteret om en berørt udgivet version af Snowflake Connector for .NET, fordi fejlen lå i GitHub Actions-workflowet og ikke i connectorens runtime-kode.

Snowflakes reaktion

Wiz rapporterede problemet 23. juni. Snowflake rettede workflowet samme dag og roterede den eksponerede Jira-legitimationsoplysning dagen efter.

Snowflake gennemgik derefter auditloggene og konkluderede, at Wiz var den eneste aktør i eksponeringsperioden. Wiz oplyste samtidig, at alle data fra proof of concept var blevet slettet på sikker vis.

Der blev ikke rapporteret om uautoriseret adgang fra tredjeparter, ingen CVE-tildeling og ingen berørt connector-udgivelse. Disse forhold afgrænser den bekræftede konsekvens – men gør ikke det oprindelige workflow-design sikkert. En offentlig issue-titel burde aldrig have kunnet blive en del af en shell-kommando i et workflow, der håndterede interne legitimationsoplysninger.

Lektionen for CI/CD-sikkerhed

Læringen rækker længere end Snowflake og Copilot. GitHub-udtryk som issue-titler, pull request-titler, branchenavne og kommentarer bør behandles som potentielt ondsindede input, når de føres ind i shell-kommandoer.

Et sikrere workflow bør blandt andet:

• Sende upålidelige værdier via miljøvariabler i stedet for at indsætte dem direkte i run:-scripts.
• Bruge strukturerede værktøjer som jq til at opbygge JSON i stedet for at samle shell-strenge manuelt.
• Citere og validere data ved overgangen til shellen.
• Holde legitimationsoplysninger ude af trin, der behandler angriberstyret indhold, når det er muligt.
• Gennemgå AI-genererede sikkerhedsændringer lige så grundigt som kode skrevet af mennesker.

Episoden viser et nyt sikkerhedsmønster med stor tydelighed: Ét AI-baseret kodningssystem kan overse en farlig CI/CD-ændring, mens en autonom offensiv agent finder og validerer den få dage senere. Automatisering kan fremskynde både afhjælpning og udnyttelse – men den kan ikke erstatte uafhængig sikkerhedsgennemgang.