Fire hændelser. Halvtreds dage. OpenAI, Anthropic, Meta. Ikke ét direkte modelangreb. Mønsteret er klassisk software: de gik efter rørledningen, ikke hjernen. Her fejler mange teams stadig – og det koster.
Spol til 11. maj: Mini Shai‑Hulud, en selvforplantende orm, fik på seks minutter skubbet 84 ondsindede versioner ud på 42 @tanstack\/* npm‑pakker. To dage senere bekræftede OpenAI kompromitterede medarbejderenheder og udtrukne credentials fra interne repositories. Før det så vi et Codex‑kommando‑injektionshul og en Anthropic‑pakke med en alt for snakkesalig source map. Fællesnævneren er ubehageligt enkel: release‑pipeline, afhængigheder, CI‑runnere, pakkeportaler – ikke selve modellen.
Fire hændelser, én gentagelse
VentureBeat kortlagde tidslinje og teknik, og billedet går igen. Tre hændelser var modstander‑drevne angreb, én var en pakkeringsfejl. Ingen sigtede på modeladfærd; alle udnyttede kanalerne, der skubber software ud. Det matcher det, vi ser i vores egne CI\/CD‑reviews.
Den 30. marts blev et Codex‑hul beskrevet, hvor usanerede GitHub‑branch‑navne røg direkte ind i shell‑kommandoer. Et semikolon her, et backtick der – og en container kører dine instrukser og lækker en GitHub OAuth‑token i klartekst. Dage efter rullede to forgiftede LiteLLM‑versioner kortvarigt gennem PyPI og blev hentet titusindvis af gange, nok til at ramme en downstream‑aktør og, ifølge VentureBeat, give et massivt dataudtræk hos en partner. Vi mangler stadig præcise loguddrag offentligt, men kæden hænger teknisk sammen.
Mini Shai‑Hulud og TanStack
Mini Shai‑Hulud er en lærebog i kædeangreb mod GitHub Actions. Ifølge VentureBeat startede det med en pull_request_target‑misconfigurering i release.yml, blev forværret af cache‑poisoning, og endte med, at et OIDC‑token kunne hentes fra runnerens hukommelse. Med et ægte OIDC‑token fra det rigtige workflow i det rigtige repo åbner døren sig – ikke via stjålne maintainer‑passwords, men ved at køre med i det legitime spor.
Det mest ubehagelige? De ondsindede pakker bar gyldig SLSA Build Level 3‑proveniens. De kom fra korrekt kilde, via legitimt workflow, med et rigtigt udstedt OIDC‑bevis. Tillidsmodellen leverede det, den lover. Resultatet var 84 artefakter, der på papiret så fuldt troværdige ud. “Proveniens ser fin ud.” Ja – og alligevel nej.
Hvorfor SLSA og provenance kan narre dig
SLSA L3 kræver dokumenteret oprindelse, beskyttet builder og attestering. Fornuftigt. Men når en angriber kører dine legitime workflows fra dit repo, er proveniensen stadig sand – bare ondsindet. Det er ikke et hul i SLSA, men i antagelsen om, at provenance implicerer intention.
Vi har set det hos en stor nordisk SaaS‑kunde, hvor en test‑pipeline ved en fejl havde udgivelsesrettigheder som produktion. Proveniensen var pæn. Builden var pæn. Pakken var ikke. Pointen: provenance beskriver vejen, ikke viljen.
OpenAI’s enheder og det kedelige arbejde bagefter
To dage efter TanStack‑hændelsen bekræftede OpenAI, at to medarbejderenheder var kompromitteret, og at credential‑materiale var trukket fra interne repos. Som reaktion tilbagekaldte de macOS‑certifikater og krævede desktop‑opdatering senest 12. juni. Det er den energitunge del af incident response, der sjældent rammer forsiderne, men suger tid ud af driften.
OpenAI oplyste også, at de var i gang med at hardene CI\/CD efter en tidligere supply‑chain‑hændelse, men at de to maskiner ikke havde fået de nye konfigurationer endnu. Konfigurationer ruller sjældent helt jævnt ud i store miljøer, og runner‑flåder lever længere end planlagt. Vi har selv måttet udhænge en kvik‑tjekliste hos en fintech‑kunde, fordi “sidste mile” blev ved med at glide.
Modeller i rampelyset, rørledninger i skyggen
System cards, AISI‑evalueringer og eksotiske red‑team‑øvelser er vigtige for modelrisici. Men de antager, at artefaktet, du tester, faktisk er det, du tror. Release‑overfladen ligger uden for scopet – og er i praksis blevet en ladeport. VentureBeat påpeger det direkte; vores vurdering er den samme.
Det bliver hurtigt dyrt: en pakningsfejl, en forkert workflow‑trigger, et tokenspor i en delt runner – og resten af kæden nikker det igennem. Det overrasker stadig, hvor mange teams bruger pull_request_target bredt uden isolerede permissions. Vi har set det flere gange i år, også i AI‑tunge teams med i øvrigt stærk sikkerhedskultur.
Tre gentagne svagheder – og et modtræk pr. stykke
Dependency supply (PyPI\/npm): Når en populær pakke forgiftes, kan 40 minutters eksponering række langt, som i LiteLLM\/Mercor‑forløbet beskrevet af VentureBeat. Konsekvensen er downstream‑kædereaktioner, hvor systemer “bare” fulgte semver. Modtræk: fastfrys versionsserier, allowlists for kritiske artefakter, og SCA før – ikke efter – runtime.
CI\/CD‑misconfigurations (pull_request_target): Eventet kører i base‑repoets kontekst, men bruger ændringer fra en fork. Fint til label‑robotter, ikke til release‑nøgler. Modtræk: brug pull_request frem for pull_request_target hvor muligt; hvis target er uundgåelig, så split workflows hårdt og fjern udgivelses‑tilladelser i det scope.
Secrets og runner‑isolation (OIDC\/caches): OIDC‑tokens kan ende i hukommelsen på delte runnere, og dårligt namespacede caches bliver trojanske heste. Konsekvensen er lateral bevægelse uden brugbare logs. Modtræk: fuld isolation af følsomme jobs på selv‑hostede, ephemeral runnere uden delte caches, og least‑privilege OIDC med stramme audience‑ og subject‑bindings.
Hvad man kan gøre i morgen
Balancen mellem fart og sikkerhed er reel, men her er tiltag, vi ved virker hurtigt – med lav friktion.
- Runner‑hygiejne: Ephemeral, single‑tenant runnere til alle publish‑trin. Ingen shared caches. Slet efter job.
- OIDC med mindst mulige rettigheder: Begræns audience, bind til specifikke repos, workflows og environments. Rotér trust‑forhold kvartalsvis.
- Cache‑strategi: Unikke nøgler per job og branch. Aldrig caches på trin med secrets. Slå write‑permission fra, hvor det ikke er påkrævet.
- Reproducible builds og signering: Kræv SBOM plus signeret artefakt for alle produktionsafhængigheder. Verificér i pipeline før deploy.
- Allowlists: Kritiske pakker og actions må kun hentes fra godkendte kilder og pinned SHAs – ikke flydende tags.
- Pipeline‑chaos: Kør ugentligt en simuleret
pull_request_target‑angreb, en cache‑poisoning test og en kontrolleret OIDC‑leak i et isoleret miljø.
Snillds felt‑noter fra maskinrummet
Teams overvurderer ofte, hvor nemt “troværdige” artefakter er at spotte. I en pipeline‑workshop hos en stor nordisk SaaS‑leverandør sænkede runner‑isolering og allowlists mulige privilege‑eskalationsstier med over 60 procent – uden mærkbar dev‑friktion. Det tog en halv dag og to små YAML‑ændringer at se effekt.
I et fintech‑projekt fik vi udfordret sætningen: “Hvis SLSA siger ok, så er den vel god nok.” Nej – ikke altid. Vi indførte en ekstra gate, der sammenholder provenance med forventet commit‑afsender, branch‑beskyttelser og en minimal publikationsmatrice. Det fjernede en falsk tryghed og tilføjede to minutters byggetid. Det er en god handel.
Tradeoffs, som ikke forsvinder
Streng isolation koster: flere runnere, mere kø, mere logistik. Men en pipeline‑breach koster altid mere – og rammer bredere i AI‑stakke, hvor artefakter flyder ind i data‑ og modelrør. Provenance kan give ro, hvis man læser dens begrænsninger som del af kontrakten.
Udviklerfriktion er reel. Pinning og allowlists føles bureaukratisk tirsdag efter frokost. Små autofix‑værktøjer og gode lokale caches aflaster. Mål lead time før og efter hardening – forskellen er ofte følelse, ikke fakta.
Hvad red teams bør ændre nu
Model‑angreb er spændende, men pipeline‑øvelser skal op på samme hylde. Start med tabletop, gå til tekniske tests, og mål noget, I kan forbedre inden næste sprint – ikke bare en pæn rapport.
- Testcases: Malicious PR mod et repo med
pull_request_target; en cache‑poisoning via delt nøgle; og en OIDC‑token‑ekstraktion i kontrolleret miljø.- Succesmål: Når angrebet publish‑trin; hvor langt man når med kun read‑tilladelser; hvor mange logs der kræves for at rekonstruere kæden.
- Frekvens: Mindst én teknisk drill per sprint for kritiske produkter. Opdatér runbook efter hver øvelse.
Leverandørkrav uden fluff
Vurder partnere på rørledningen, ikke kun modellen. Det er dér, skaden starter oftest. Spørg til krav, der kan verificeres – ikke løfter.
- Reproducible builds og tamper‑evident artefakter som standard. Vis attest, ikke powerpoint.
- SBOM for alle builds, plus proces for at varsle om risikable afhængigheder inden for 24 timer.
- Dokumenteret least‑privilege OIDC‑opsætning og rotationscyklus. Ingen long‑lived deploy‑nøgler.
- Begrænsning eller fravalg af
pull_request_target i udgivelsesnære workflows.
Konsekvenser for produkt og drift
For produktteams: Prioritér en 90‑dages rørledningshårdhed på linje med en stor feature. For drift: opdatér playbooks – runner‑logindsamling, volatile memory‑forensics for OIDC, tilbagekaldelse af signeringscertifikater og tvungne klientopdateringer.
En enkel 3‑måneders sekvens til mellemstore organisationer: Måned 1 – fjern
pull_request_target fra release‑nære workflows, pin kritiske actions til SHAs, slå write‑caches fra hvor muligt. Måned 2 – indfør ephemeral runnere for publish‑trin, skær OIDC‑tilladelser ned, begynd at signere og validere artefakter. Måned 3 – SBOM‑flow på plads, ugentlig pipeline‑chaos, og en intern leverandørmatrix med de nye krav.Det vi stadig ikke ved
Nogle detaljer er uklare eller mangler officiel rådgivning. VentureBeat beskriver OIDC‑udtræk fra runner‑hukommelse og SLSA L3‑proveniens på TanStack‑pakkerne, men underliggende artefakter er ikke offentlige. Det samme gælder præcise downstream‑tal for LiteLLM\/Mercor‑kæden og fulde logs fra OpenAI‑hændelsen.
Leverandører bør offentliggøre nok teknisk dokumentation – runner‑logs, relevante commits, provenance‑filer – så branchen kan lære konkret. Indtil da må vi støtte os til det, der er veldokumenteret i standarder samt GitHub‑ og SLSA‑dokumentation, og være åbne om hullerne. Det er vi her.
Bundlinjen
De fire hændelser viser, at AI‑sikkerhed taber bolden i rørledningen – ikke i modellen. Det er ikke endnu en compliance‑øvelse, men det praktiske sted, hvor en angriber i dag får mest for indsatsen, fordi vores værn er bygget til noget andet.
Hærd jeres workflows før næste feature. Skær unødige tilladelser. Gør runnere kortlivede. Lad en lille test‑orm bide i jeres egen pipeline og se, hvor langt den når. Lær af det i stedet for at gætte.
Bilag og begreber
- pull_request_target: GitHub Actions‑event, der kører i base‑repoets kontekst og derfor kan have højere privilegier end
pull_request. Bør undgås i release‑nære workflows.- OIDC: OpenID Connect‑baseret udstedelse af kortlivede tokens til cloud‑udbydere. Skal bindes stramt til repo, workflow og audience.
- SLSA Level 3: Niveaubeskrivelse af forsyningskædesikkerhed med krav til beskyttet builder, attestering og provenance. Stærkt, men ikke immun over for misbrug af legitime workflows.
- SBOM: Software Bill of Materials, en fortegnelse over komponenter i et build, som muliggør hurtig sårbarhedsjagt og compliance.
Kildeoverblik
Primær kilde: VentureBeat’s gennemgang af de fire hændelser og de tekniske kæder bag dem. Vi har lænet os op ad officielle standarder for begreber og modforanstaltninger, herunder GitHub Actions‑dokumentation om
pull_request_target og OIDC samt SLSA‑specifikationen. System card‑eksemplet illustrerer, hvorfor modelcentriske dokumenter ikke adresserer release‑overfladen. Hvor der mangler officielle advisories, har vi markeret usikkerheder og planlagt opfølgende forespørgsler.Faktaboks tidslinje
- 30. marts 2026: OpenAI Codex‑kommando‑injektion offentliggjort – branch‑navne kunne trigge shells og lække GitHub OAuth‑token.
- 24.–27. marts 2026: LiteLLM‑forgiftning på PyPI, kort live men med stor downstream‑effekt hos Mercor ifølge VentureBeat.
- 31. marts 2026: Anthropic udgav Claude Code‑pakke med en 59,8 MB source map, der lækkede omfattende TypeScript‑kilde, hurtigt trukket tilbage.
- 11. maj 2026: Mini Shai‑Hulud publicerer 84 ondsindede versioner på 42 @tanstack\/*‑pakker på seks minutter via release‑pipeline‑kapring.
- 13. maj 2026: OpenAI bekræfter to kompromitterede medarbejderenheder og igangsætter tilbagekaldelse af macOS‑certifikater og tvungen desktop‑opdatering.
- OIDC: OpenID Connect‑baseret udstedelse af kortlivede tokens til cloud‑udbydere. Skal bindes stramt til repo, workflow og audience.
- pull_request_target: GitHub Actions‑event, der kører i base‑repoets kontekst og derfor kan have højere privilegier end
- Testcases: Malicious PR mod et repo med
