Din app har låg risk. Det har inte din byggpipeline.

Resonemanget håller, till en viss gräns

Vi hör det ofta, och det kommer oftast från ett förnuftigt håll. Appen är en intern dashboard, en datapipeline eller en liten tjänst med en handfull användare. Den innehåller inget som en angripare vill ha. Säkerhetsbudgeten går först till den kundnära produkten.

Den logiken håller för applikationen. Den håller inte för hur applikationen byggs. Varje team, oavsett vad det levererar, har en CI-pipeline med inloggningsuppgifter och ett beroendeträd det inte har skrivit. De är värda att angripa eftersom de delas, och ett intrång där når allt annat som inloggningsuppgifterna kommer åt: dina register, dina molnkonton och dina andra repon.

Attacker som inte brydde sig om vad appen gjorde

Ingen av dessa incidenter riktade sig mot en viss sorts applikation. Var och en nådde team genom ett verktyg eller paket som de använde för att bygga programvara.

tj-actions/changed-files, 2025

En mycket använd GitHub Action som upptäcker ändrade filer komprometterades. Enligt CISA låg skadliga versioner ute mellan den 12 och 15 mars 2025, och intrånget exponerade hemligheter som åtkomstnycklar, personliga åtkomsttokens för GitHub, npm-tokens och privata RSA-nycklar. Wiz rapporterade att koden dumpade CI-runnerns minne, så på publika repon hamnade hemligheterna i arbetsflödesloggar. Arbetsflöden som refererade till actionen med en versionstagg körde den skadliga koden, oavsett vad repot innehöll.

npm-masken Shai-Hulud, 2025

I september 2025 varnade CISA för en självreplikerande mask som hade komprometterat mer än 500 npm-paket. Den samlade in personliga åtkomsttokens för GitHub och moln-API-nycklar för AWS, Google Cloud och Azure. Palo Alto Networks Unit 42 beskrev hur den använde stulna npm-tokens för att publicera infekterade versioner av offrets andra paket, och hur en senare våg kördes under pre-install, vilket utökade dess räckvidd till CI/CD-pipelines.

3:27

Codecov Bash Uploader, 2021

En angripare kom över en inloggningsuppgift genom ett fel i Codecovs byggprocess för Docker-avbilder och ändrade Bash Uploader-skriptet som många team körde i CI. Från den 31 januari till den 1 april 2021 kunde det ändrade skriptet skicka miljövariabler, inklusive inloggningsuppgifter, tokens och nycklar som fanns i CI-miljön, till en tredje part. Det upptäcktes när en kund märkte att skriptets kontrollsumma inte stämde.

xz utils, 2024

Skadlig kod bäddades in i XZ Utils-versionerna 5.6.0 och 5.6.1, ett datakomprimeringsbibliotek som kan finnas i Linux-distributioner. CISA rekommenderade att nedgradera till en okomprometterad version som 5.4.6 och att leta efter skadlig aktivitet. Ett komprimeringsbibliotek är ungefär så oglamoröst som ett beroende kan bli, och det blev ändå ett mål.

event-stream, 2018

En person som utgav sig för att vara en hjälpsam förvaltare tog över det populära npm-paketet event-stream och lade till ett skadligt beroende, flatmap-stream, i version 3.3.6. npm-teamet rapporterade att den skadliga koden riktade sig mot en specifik applikation, bitcoinplånboken Copay. Alla andra som installerade event-stream fick också den skadliga koden.

Vad incidenterna har gemensamt

• De inträffade vid bygge eller installation. Den skadliga koden kördes på utvecklardatorer och CI-runners, inte i produktionsappen.
• De gick efter inloggningsuppgifter. Tokens och nycklar i pipelinen var bytet, eftersom de öppnar dörrar utanför projektet som byggs.
• De kom via betrodda namn. En välkänd action, ett välkänt paket, ett välkänt skript. Ingen valde att installera skadlig kod.
• Den första frågan efteråt var densamma. Hämtade något av våra byggen den dåliga versionen, och vad kunde den nå? Team utan en registrering av vad varje bygge använde fick rekonstruera det.

Vad en minimal insats innebär

Du behöver inget säkerhetsteam för att täcka grunderna. De flesta av råden från GitHub och CISA ryms i en kort lista:

1. Lås GitHub Actions från tredje part till en fullständig commit-SHA i stället för en tagg, så att en flyttad tagg inte kan ändra vad som körs.
2. Checka in lockfiler och lås beroendeversioner till kända bra releaser.
3. Ge CI-tokens så snäva behörigheter som fungerar, och byt ut dem när en incident berör något du använder.
4. Kräv nätfiskeresistent flerfaktorsautentisering på utvecklar- och publiceringskonton.
5. Behåll en registrering av vad varje bygge installerade, så att du kan svara på ”drabbades vi?” utifrån data och inte minnet.

De fyra första är konfiguration. Den femte är den som de flesta små team hoppar över, eftersom den kräver verktyg.

Var CRACI passar in med liten insats

CRACI sköter registreringen och lägger till en nätverksgräns, utan att du behöver ändra din app eller dina arbetsflöden.

• En rad per jobb. Ändra runs-on till craci. Dina GitHub Actions-arbetsflöden förblir som de är, och körningarna syns fortfarande i GitHub.
• En SBOM från varje bygge. CRACI registrerar paketen som varje jobb faktiskt hämtar, inklusive paket som återställs från cachar, och exporterar resultatet i CycloneDX eller SPDX.
• En nätverksspårning per jobb. När en incident tillkännages kan du kontrollera vilka byggen som hämtade det berörda paketet och vart varje jobb anslöt.
• En egress-policy som du kan ställa om till att neka som standard. Tillåt paketkällorna som ett jobb behöver, så har ett komprometterat steg färre ställen att skicka sina fynd till. Policyer blockerar vid fel, och överträdelser utlöser ett larm.
• Löpande omvärdering. Bevakade SBOM:er kontrolleras på nytt när nya sårbarheter publiceras, så att ett gammalt bygge inte förblir ”rent” bara för att ingen har tittat.

För att vara tydliga med begränsningarna: en egress-policy hade inte hindrat tj-actions-intrånget från att skriva ut hemligheter i en publik logg, och inget verktyg gör en läckt token ogjord. Låsning och utbyte av tokens spelar fortfarande roll. Det CRACI ändrar är hur snabbt du kan svara på om du var exponerad och hur långt ett komprometterat steg kan nå.

För att få igång ett första arbetsflöde installerar du GitHub-appen och ändrar en rad till runs-on: craci.

Vad det kostar

CRACI tar bara betalt för byggminuter: $0.002 per vCPU-minut ($0.004 för en standardrunner med 2 vCPU), mätt per sekund, utan månadsavgift och utan avgift per SBOM. Se priser för alla villkor. Startups som uppfyller kraven kan ansöka till startupprogrammet för minst 100k gratis byggminuter och personlig onboarding.

Om du säljer programvara i EU är det också värt att kontrollera om Cyber Resilience Act gäller dig. Vår guide till CRA förklarar tillämpningsområdet och tidsfristerna.