Appen din har lav risiko. Byggepipelinen din har det ikke.

Resonnementet holder, til et visst punkt

Vi hører det ofte, og det har som regel en fornuftig begrunnelse. Appen er et internt dashbord, en datapipeline eller en liten tjeneste med en håndfull brukere. Den inneholder ingenting en angriper vil ha. Sikkerhetsbudsjettet går først til det kunderettede produktet.

Den logikken holder for applikasjonen. Den holder ikke for måten applikasjonen bygges på. Hvert team, uansett hva det leverer, har en CI-pipeline med påloggingsinformasjon og et avhengighetstre det ikke har skrevet selv. De er verdt å angripe fordi de er delt, og en kompromittering der når alt annet den påloggingsinformasjonen har tilgang til: registrene, skykontoene og de andre repositoriene dine.

Angrep som ikke brydde seg om hva appen gjorde

Ingen av disse hendelsene var rettet mot en bestemt type applikasjon. Hver av dem nådde team gjennom et verktøy eller en pakke de brukte til å bygge programvare.

tj-actions/changed-files, 2025

En mye brukt GitHub Action som oppdager endrede filer, ble kompromittert. Ifølge CISA var ondsinnede versjoner tilgjengelige mellom 12. og 15. mars 2025, og kompromitteringen eksponerte hemmeligheter, blant annet tilgangsnøkler, personlige GitHub-tilgangstokens, npm-tokens og private RSA-nøkler. Wiz rapporterte at koden dumpet minnet til CI-runneren, så på offentlige repositorier havnet hemmelighetene i workflow-logger. Workflows som viste til actionen med en versjonstagg, kjørte den ondsinnede koden, uansett hva repositoriet inneholdt.

npm-ormen Shai-Hulud, 2025

I september 2025 varslet CISA om en selvreplikerende orm som hadde kompromittert mer enn 500 npm-pakker. Den samlet inn personlige GitHub-tilgangstokens og sky-API-nøkler for AWS, Google Cloud og Azure. Palo Alto Networks Unit 42 beskrev hvordan den brukte stjålne npm-tokens til å publisere infiserte versjoner av offerets andre pakker, og hvordan en senere bølge kjørte under pre-install, noe som utvidet rekkevidden inn i CI/CD-pipelines.

3:27

Codecov Bash Uploader, 2021

En angriper hentet ut påloggingsinformasjon gjennom en feil i Codecovs byggeprosess for Docker-imaget og endret Bash Uploader-skriptet som mange team kjørte i CI. Fra 31. januar til 1. april 2021 kunne det endrede skriptet sende miljøvariabler, inkludert påloggingsinformasjon, tokens og nøkler som var tilgjengelige i CI-miljøet, til en tredjepart. Det ble oppdaget da en kunde la merke til at skriptets sjekksum ikke stemte.

xz utils, 2024

Ondsinnet kode ble bygget inn i XZ Utils versjon 5.6.0 og 5.6.1, et datakomprimeringsbibliotek som kan finnes i Linux-distribusjoner. CISA rådet til å nedgradere til en ukompromittert versjon som 5.4.6 og til å lete etter ondsinnet aktivitet. Et komprimeringsbibliotek er omtrent så lite glamorøst som en avhengighet kan bli, og det var likevel et mål.

event-stream, 2018

En person som utga seg for å være en hjelpsom vedlikeholder, tok over den populære npm-pakken event-stream og la til en ondsinnet avhengighet, flatmap-stream, i versjon 3.3.6. npm-teamet rapporterte at nyttelasten var rettet mot én bestemt applikasjon, bitcoin-lommeboken Copay. Alle andre som installerte event-stream, fikk også den ondsinnede koden.

Hva disse hendelsene har til felles

• De skjedde under bygging eller installasjon. Den ondsinnede koden kjørte på utvikleres maskiner og CI-runnere, ikke i produksjonsappen.
• De gikk etter påloggingsinformasjon. Tokens og nøkler i pipelinen var premien, fordi de åpner dører utover prosjektet som bygges.
• De kom gjennom betrodde navn. En kjent action, en kjent pakke, et kjent skript. Ingen valgte å installere skadevare.
• Det første spørsmålet etterpå var det samme. Hentet noen av byggene våre den dårlige versjonen, og hva kunne den nå? Team uten en oversikt over hva hvert bygg brukte, måtte rekonstruere det.

Hvordan minimal innsats ser ut

Du trenger ikke et sikkerhetsteam for å dekke det grunnleggende. De fleste rådene fra GitHub og CISA får plass i en kort liste:

1. Fest GitHub Actions fra tredjeparter til en full commit-SHA i stedet for en tagg, så en flyttet tagg ikke kan endre hva som kjører.
2. Commit lockfiler og fest avhengighetsversjoner til kjente, gode utgivelser.
3. Gi CI-tokens de smaleste tillatelsene som fungerer, og roter dem når en hendelse berører noe du bruker.
4. Krev phishing-resistent flerfaktorautentisering på utvikler- og publiseringskontoer.
5. Før en oversikt over hva hvert bygg installerte, så du kan svare på «ble vi berørt?» ut fra data og ikke hukommelsen.

De fire første er konfigurasjon. Den femte er den de fleste små team hopper over, fordi den krever verktøy.

Slik passer CRACI inn med liten innsats

CRACI dekker registreringen og legger til en nettverksgrense, uten at du må endre appen eller workflowene dine.

• Én linje per jobb. Endre runs-on til craci. GitHub Actions-workflowene dine forblir som de er, og kjøringene vises fortsatt i GitHub.
• En SBOM fra hvert bygg. CRACI registrerer pakkene hver jobb faktisk henter, inkludert pakker gjenopprettet fra cacher, og eksporterer resultatet i CycloneDX eller SPDX.
• Et nettverksspor per jobb. Når en hendelse blir kjent, kan du sjekke hvilke bygg som hentet den berørte pakken, og hvor hver jobb koblet seg til.
• En egress-policy du kan bytte til default deny. Tillat pakkekildene en jobb trenger, så har et kompromittert steg færre steder å sende det det finner. Policyer blokkerer ved feil (fail closed), og brudd utløser et varsel.
• Kontinuerlig revurdering. Overvåkede SBOM-er sjekkes på nytt etter hvert som nye sårbarheter publiseres, så et gammelt bygg ikke forblir «rent» bare fordi ingen har sett på det.

For å være tydelig om begrensningene: En egress-policy ville ikke ha hindret tj-actions-kompromitteringen i å skrive hemmeligheter til en offentlig logg, og ingen verktøy kan gjøre et lekket token ugjort. Festing og rotering er fortsatt viktig. Det CRACI endrer, er hvor raskt du kan svare på om du var eksponert, og hvor langt et kompromittert steg kan nå.

For å få den første workflowen i gang installerer du GitHub-appen og endrer én linje til runs-on: craci.

Hva det koster

CRACI tar bare betalt for byggeminutter: $0.002 per vCPU-minutt ($0.004 for en standard runner med 2 vCPU), målt per sekund, uten månedsavgift og uten betaling per SBOM. Se priser for de fullstendige vilkårene. Oppstartsbedrifter som oppfyller kravene, kan søke på programmet for oppstartsbedrifter og få minst 100k gratis byggeminutter og personlig onboarding.

Hvis du selger programvare i EU, er det også verdt å sjekke om Cyber Resilience Act gjelder for deg. Guiden vår til CRA forklarer virkeområdet og fristene.