Din app har lav risiko. Din build-pipeline har ikke.

Ræsonnementet holder, op til et vist punkt

Vi hører det ofte, og det kommer som regel af gode grunde. Appen er et internt dashboard, en datapipeline eller en lille service med en håndfuld brugere. Den rummer intet, en angriber vil have. Sikkerhedsbudgettet går først til det kundevendte produkt.

Den logik holder for applikationen. Den holder ikke for, hvordan applikationen bygges. Alle teams har, uanset hvad de leverer, en CI-pipeline med legitimationsoplysninger og et afhængighedstræ, de ikke selv har skrevet. De er værd at angribe, fordi de er delt, og en kompromittering der når alt andet, de legitimationsoplysninger kan røre: dine registries, dine cloud-konti og dine andre repositories.

Angreb, der var ligeglade med, hvad appen gjorde

Ingen af disse hændelser var rettet mod en bestemt slags applikation. Hver af dem nåede teams gennem et værktøj eller en pakke, de brugte til at bygge software.

tj-actions/changed-files, 2025

En meget brugt GitHub Action, der opdager ændrede filer, blev kompromitteret. Ifølge CISA var ondsindede versioner live mellem 12. og 15. marts 2025, og kompromitteringen eksponerede secrets, herunder adgangsnøgler, GitHub personal access tokens, npm-tokens og private RSA-nøgler. Wiz rapporterede, at koden dumpede CI-runnerens hukommelse, så secrets på offentlige repositories endte i workflow-logs. Workflows, der henviste til actionen med et versionstag, kørte den ondsindede kode, uanset hvad repositoriet indeholdt.

npm-ormen Shai-Hulud, 2025

I september 2025 advarede CISA om en selvreplikerende orm, der havde kompromitteret mere end 500 npm-pakker. Den høstede GitHub personal access tokens og cloud-API-nøgler til AWS, Google Cloud og Azure. Palo Alto Networks Unit 42 beskrev, hvordan den brugte stjålne npm-tokens til at udgive inficerede versioner af ofrets andre pakker, og hvordan en senere bølge kørte under pre-install, hvilket udvidede dens rækkevidde ind i CI/CD-pipelines.

3:27

Codecov Bash Uploader, 2021

En angriber fik fat i en legitimationsoplysning gennem en fejl i Codecovs byggeproces for Docker-images og ændrede Bash Uploader-scriptet, som mange teams kørte i CI. Fra 31. januar til 1. april 2021 kunne det ændrede script sende miljøvariabler, herunder legitimationsoplysninger, tokens og nøgler tilgængelige i CI-miljøet, til en tredjepart. Det blev opdaget, da en kunde bemærkede, at scriptets checksum ikke stemte.

xz utils, 2024

Ondsindet kode blev indlejret i XZ Utils version 5.6.0 og 5.6.1, et datakomprimeringsbibliotek, der kan findes i Linux-distributioner. CISA rådede til at nedgradere til en ukompromitteret version som 5.4.6 og lede efter ondsindet aktivitet. Et komprimeringsbibliotek er omtrent så uglamourøst, som en afhængighed kan blive, og det var alligevel et mål.

event-stream, 2018

En person, der udgav sig for at være en hjælpsom maintainer, overtog den populære npm-pakke event-stream og tilføjede en ondsindet afhængighed, flatmap-stream, i version 3.3.6. npm-teamet rapporterede, at payloaden var rettet mod én bestemt applikation, bitcoin-tegnebogen Copay. Alle andre, der installerede event-stream, fik også den ondsindede kode.

Hvad disse hændelser har til fælles

• De skete under build eller installation. Den ondsindede kode kørte på udvikleres maskiner og CI-runnere, ikke i produktionsappen.
• De gik efter legitimationsoplysninger. Tokens og nøgler i pipelinen var præmien, fordi de åbner døre ud over det projekt, der bygges.
• De kom gennem betroede navne. En velkendt action, en velkendt pakke, et velkendt script. Ingen valgte at installere malware.
• Det første spørgsmål bagefter var det samme. Trak nogen af vores builds den dårlige version ind, og hvad kunne den nå? Teams uden en registrering af, hvad hvert build brugte, måtte rekonstruere det.

Sådan ser en minimal indsats ud

Du behøver ikke et sikkerhedsteam for at dække det grundlæggende. De fleste af rådene fra GitHub og CISA kan stå på en kort liste:

1. Fastlås tredjeparts GitHub Actions på en fuld commit-SHA i stedet for et tag, så et flyttet tag ikke kan ændre, hvad der kører.
2. Commit lockfiles, og fastlås afhængighedsversioner til kendte, gode releases.
3. Giv CI-tokens de snævrest mulige rettigheder, og rotér dem, når en hændelse rammer noget, du bruger.
4. Kræv phishing-resistent multifaktorgodkendelse på udvikler- og publiceringskonti.
5. Hav en registrering af, hvad hvert build installerede, så du kan svare på "var vi ramt?" ud fra data i stedet for hukommelsen.

De første fire er konfiguration. Den femte er den, de fleste små teams springer over, fordi den kræver værktøjer.

Hvor CRACI passer ind med lille indsats

CRACI dækker registreringen og tilføjer en netværksgrænse, uden at du skal ændre din app eller dine workflows.

• Én linje pr. job. Ændr runs-on til craci. Dine GitHub Actions-workflows forbliver, som de er, og kørsler vises stadig i GitHub.
• En SBOM fra hvert build. CRACI registrerer de pakker, hvert job faktisk trækker ind, inklusive pakker gendannet fra caches, og eksporterer resultatet som CycloneDX eller SPDX.
• Et netværkstrace pr. job. Når en hændelse bliver offentliggjort, kan du tjekke, hvilke builds der trak den ramte pakke ind, og hvor hvert job forbandt sig til.
• En egress-politik, du kan skifte til default deny. Tillad de pakkekilder, et job har brug for, så har et kompromitteret trin færre steder at sende det, det finder. Politikker blokerer ved fejl (fail closed), og overtrædelser udløser en alarm.
• Løbende genvurdering. Overvågede SBOM'er tjekkes igen, når nye sårbarheder offentliggøres, så et gammelt build ikke forbliver "rent", bare fordi ingen har kigget.

For at være tydelig om begrænsningerne: En egress-politik ville ikke have forhindret tj-actions-kompromitteringen i at skrive secrets i en offentlig log, og intet værktøj gør et lækket token ugjort. Fastlåsning og rotation er stadig vigtige. Det, CRACI ændrer, er, hvor hurtigt du kan svare på, om du var eksponeret, og hvor langt et kompromitteret trin kan nå.

For at få et første workflow til at køre skal du installere GitHub-appen og ændre én linje til runs-on: craci.

Hvad det koster

CRACI tager kun betaling for build-minutter: $0.002 pr. vCPU-minut ($0.004 for en standardrunner med 2 vCPU), målt pr. sekund, uden månedligt gebyr og uden betaling pr. SBOM. Se priser for de fulde vilkår. Startups, der opfylder kravene, kan ansøge om startup-programmet og få mindst 100k gratis build-minutter og personlig onboarding.

Hvis du sælger software i EU, er det også værd at tjekke, om Cyber Resilience Act gælder for dig. Vores guide til CRA forklarer omfanget og fristerne.