Claude Code-feil gjorde GitHub-issues til supply-chain-risiko

En ny sikkerhetsgjennomgang fra GMO Flatt Security viser hvor fort AI-agenter i utviklingsløpet kan bli en supply-chain-risiko. Forskeren RyotaK beskriver en feil i Claude Code GitHub Actions som kunne la en angriper bruke en GitHub Issue som inngang til en agentdrevet workflow. Sårbarheten er ifølge gjennomgangen rettet, men mønsteret er mer interessant enn selve patchen.

Kjernen er enkel. Claude Code kan kjøres i GitHub Actions og reagere på issues, pull requests og andre hendelser. Det gjør agenten nyttig: den kan lese kontekst, foreslå endringer, opprette arbeid og hjelpe utviklere direkte der koden lever. Men samme mekanisme gjør også tekst i en issue eller PR-kommentar til styringsinput for en agent som kan ha tilgang til tokens, secrets og repository-rettigheter.

GMO Flatt beskriver en permission-bypass i agent mode. Claude Code-actionen vurderte aktører som endte på «[bot]» som betrodde, uten å gjøre en reell kontroll av om aktøren hadde write- eller admin-tilgang til repoet. En angriper kunne dermed opprette en egen GitHub App, installere den på eget repo og bruke app-token til å opprette en issue eller pull request i et offentlig målrepo som brukte Claude Code-workflow. Derfra kunne agenten behandle angriperens tekst som betrodd input.

Forskeren skriver at feilen kunne kompromittere repoer som brukte Claude Code-workflow, også i tilfeller der Anthropic selv var mål. GitHub-historikken viser en senere endring med tittelen «fix: add checkHumanActor to agent mode», og release v1.0.94 er relevant for rettingen. Det finnes ikke en offentlig Anthropic-advisory som dekker alle detaljene, så den trygge formuleringen er at primærkilden dokumenterer funnet, mens GitHub-endringen verifiserer at kontrollen i agent mode ble strammet inn.

For norske CISO-er er dette ikke en kuriositet om én AI-leverandør. Det er et konkret eksempel på en ny klasse risiko: agenten i CI/CD-løpet tolker utrygg tekst som arbeidsordre. Issues, PR-kommentarer, README-filer og prosjektinstrukser kan bli prompt-injection-flater. Hvis workflowen samtidig har GITHUB_TOKEN, cloud secrets eller write-permissions, flyttes angrepet fra «lur modellen» til «bruk modellen som intern aktør».

GMO Flatt peker også på en vanlig konfigurasjonsrisiko: allowed_non_write_users satt til «*». Det kan være fristende i åpne prosjekter og raske utviklingsmiljøer, fordi agenten da kan svare flere bidragsytere. Men kombinert med secrets eller brede rettigheter blir det et svakt punkt. Angriperen trenger ikke kompromittere en utviklerkonto hvis workflowen allerede gir agenten nok rom til å lese, skrive eller eksfiltrere.

Dette treffer særlig virksomheter som har flyttet AI-koding fra enkeltbrukere til felles utviklingsplattformer. En lokal Copilot-chat er én risikotype. En agent i GitHub Actions, koblet til repo, issues, pull requests, tokens og deployrutiner, er noe annet. Den står nærmere produksjonskjeden. Den bør derfor styres som CI/CD-infrastruktur, ikke som et kreativt verktøy.

Det første tiltaket er å kartlegge hvor AI-agenter faktisk kjører i pipeline. Søk etter workflows som bruker Claude Code, andre agent-actions eller egne scripts som sender issue- og PR-tekst til modeller. Sjekk om de er trigget av eksterne bidrag, om de kjører på offentlige repoer, og hvilke permissions de har. Minimer GITHUB_TOKEN-rettigheter per workflow. Unngå write-tilgang der agenten bare skal lese og foreslå.

Det andre tiltaket er å behandle all ekstern tekst som fiendtlig input. En issue er ikke bare en supportmelding når den mates inn i en agent. Den kan være en instruksjon. Det samme gjelder PR-beskrivelser, kommentarer, dokumentasjon og filer som agenten leser. Agenten bør ikke få blind tilgang til secrets. Den bør ikke kunne utføre irreversible handlinger uten eksplisitt menneskelig godkjenning. Logger bør vise hvilken hendelse som startet workflowen, hvilken identitet som trigget den, hvilke rettigheter som var tilgjengelige, og hva agenten forsøkte å gjøre.

Det tredje tiltaket er leverandørstyring. Spør leverandørene av AI-kodeagenter hvordan de skiller mellom menneskelige aktører, apper og bots. Be om dokumentasjon på hvordan de håndterer prompt injection i GitHub, GitLab og andre utviklingsplattformer. Krev klare råd for secrets, token-scope og default permissions. Dette er ikke lenger bare modellrisiko. Det er identitet, tilgang og endringsstyring i samme pakke.

Saken passer også inn i et større mønster. Etter hvert som agentene får flere verktøy, blir sikkerheten mindre avhengig av om modellen «forstår» instruksjonen riktig. Den blir mer avhengig av hvilke systemhandlinger modellen får lov til å utføre. En agent som kan lese en issue og skrive kode, trenger guardrails som ligger utenfor prompten. Den trenger policy i workflowen, begrensede tokens, verifikasjon av aktør og tydelige stoppunkter før endringer treffer kodebasen.

Konklusjonen er ganske jordnær. AI-agenter i utviklingsløpet bør inn i samme beredskap som npm-pakker, GitHub Actions, secrets og deploynøkler. Oppdater til rettede versjoner. Fjern brede tillatelser. Revider logger. Og gjør prompt-injection mot CI/CD til et fast punkt i trusselmodellen. Agenten er nyttig. Nettopp derfor må den behandles som en del av angrepsflaten.

Kilder og medier

• Primærkilde: GMO Flatt Security Research, «Poisoning Claude Code: One GitHub Issue to Break the Supply Chain», https://flatt.tech/research/posts/poisoning-claude-code-one-github-issue-to-break-the-supply-chain/
• Verifisering: GitHub, Anthropic claude-code-action release v1.0.94 og commit «fix: add checkHumanActor to agent mode».
• Thumbnail: OpenAI Image 2 / hogby.ai