CI/CD-säkerhet

Varför pipelines är ett mål

• De har nycklarna. Inloggningsuppgifter till molnet, registertokens och signeringsnycklar passerar alla genom CI.
• De kör andras kod. Varje beroende, installationsskript och action från tredje part körs på runnern.
• De når produktion. Det som kommer ut ur pipelinen är betrott, signerat och levererat. En angripare i bygget når alla kunder på en gång.
• Få håller koll på dem. Arbetsflödesfiler ändras sällan och granskas mindre än applikationskod.

Komprometteringen av tj-actions och npm-masken Shai-Hulud gick båda efter hemligheter i CI. Se vad är en attack mot leveranskedjan för hur de här attackerna går till.

De största riskerna för CI/CD-säkerhet

OWASP Top 10 CI/CD Security Risks är standardreferensen. Grupperade efter vad som går fel:

Område	OWASP-risker	Hur det ser ut
Vem som kan ändra vad	Otillräcklig flödeskontroll, bristfällig identitets- och åtkomsthantering	Kod når produktion utan granskning, eller gamla konton behåller sin åtkomst
Vad som körs i pipelinen	Missbruk av beroendekedjan, poisoned pipeline execution	Ett skadligt paket eller ett ändrat arbetsflöde körs med jobbets åtkomst
Vad ett jobb kan nå	Otillräcklig pipelinebaserad åtkomstkontroll, otillräcklig hygien kring inloggningsuppgifter	Ett enda jobb kan läsa alla hemligheter, och tokens lever i åratal
Hur det är konfigurerat	Osäker systemkonfiguration, ostyrd användning av tredjepartstjänster	Opatchade runners, och integrationer med mer åtkomst än de behöver
Vad du kan bevisa	Bristfällig validering av artefakters integritet, otillräcklig loggning och insyn	Ingen kan säga vad som ingick i en release eller vad ett jobb anslöt till

För varje risk kopplad till kontroller i runnern, se runner-säkerhet i jämförelse.

Bästa praxis för CI/CD-säkerhet

1. Behandla pipeline-definitioner som produktionskod. Kräv granskning av arbetsflödesfiler, och håll pull requests du inte litar på borta från hemligheter.
2. Begränsa vad varje jobb kan göra. Ge tokens de minsta behörigheter de behöver, och välj kortlivade inloggningsuppgifter framför lagrade hemligheter.
3. Lås actions från tredje part till en commit-hash. Taggar kan flyttas till annan kod.
4. Isolera jobb. Kör varje jobb i en ny miljö, så att inget följer med till nästa.
5. Kontrollera utgående trafik. Ett bygge behöver kända källor och kända mål. Att blockera allt annat hindrar stulna hemligheter från att lämna bygget. Se egress-policy för GitHub Actions.
6. Registrera vad som hände. Behåll en SBOM för varje bygge och en logg över dess nätverksaktivitet, så att du kan besvara frågor i efterhand.

För versionen steg för steg, se checklistan för säkerhet i CI/CD-pipelinen.

Typer av verktyg för CI/CD-säkerhet

Typ	Vad det gör	Exempel
Runner-säkerhet	Isolerar jobb och styr vad de kan nå medan de körs	CRACI, StepSecurity
Hantering av säkerhetsläge	Hittar riskfyllda inställningar i pipelines och repon	Legit Security, Cycode, Apiiro, OX Security
Skanning av kod och beroenden	Kontrollerar kod, beroenden och hemligheter vid varje ändring	GitHub Advanced Security, Snyk, Semgrep
SBOM och bevis	Registrerar vad som ingick i varje release	CRACI, Syft, Anchore

De här verktygen arbetar i olika skeden, så de flesta team kombinerar dem. En skanner tittar på filer före bygget, verktyg för säkerhetsläge tittar på inställningar, och runner-säkerhet verkar medan jobbet körs, vilket är när ett skadligt paket agerar. Se verktyg för säkerhet i mjukvarans leveranskedja i jämförelse och DevSecOps-verktyg i jämförelse.

Var CRACI passar in

CRACI säkrar bygget medan det körs. Det ersätter dina GitHub-hostade runners med snabbare och billigare: varje jobb körs i en egen isolerad virtuell maskin, en egress-policy blockerar anslutningar som bygget inte behöver, och varje paket som jobbet hämtar hamnar i en SBOM. Eftersom policyn bara tillåter det bygget behöver skyddar den dig även mot en attack som ingen har sett tidigare.

CRACI kontrollerar inte din arbetsflödeskonfiguration, skannar inte källkod eller hemligheter och signerar inte proveniens, så behåll eller lägg till verktyg för det. GitHub Actions är det CI-system som stöds i dag, och andra CI-system finns på roadmapen.

CI/CD-säkerhet: vanliga frågor

Vad är CI/CD-säkerhet?

Det handlar om att skydda de pipelines som bygger, testar och levererar programvara, inklusive deras inloggningsuppgifter, koden de kör och artefakterna de tar fram.

Vilka är de största riskerna för CI/CD-säkerhet?

Skadliga beroenden och actions från tredje part, förgiftade pipelines, tokens med för breda behörigheter och långlivade hemligheter, samt bristande insyn i vad ett bygge gjorde. OWASP Top 10 CI/CD Security Risks är standardlistan.

Vad är poisoned pipeline execution?

En angripare ändrar vad en pipeline kör, till exempel genom att via en pull request redigera en arbetsflödesfil eller ett skript som den anropar, så att angriparens kod körs med pipelinens åtkomst.

Hur säkrar du en CI/CD-pipeline?

Granska ändringar i pipelinen, ge varje jobb den minsta åtkomst det behöver, lås actions från tredje part med commit-hash, isolera jobb, begränsa utgående trafik och behåll en registrering av vad varje bygge gjorde.

Vad är skillnaden mellan CI/CD-säkerhet och DevSecOps?

DevSecOps är den bredare metoden att bygga in säkerhet i hur programvara utvecklas. CI/CD-säkerhet fokuserar på själva pipelinen, som även DevSecOps-verktyg är beroende av.

Behöver GitHub Actions extra säkerhet?

GitHub erbjuder kontroller som tokenbehörigheter och skanning av hemligheter, men du måste konfigurera dem, och hostade runners begränsar inte utgående trafik som standard. De flesta team lägger till låsning, granskningsregler och kontroller i runnern.