Checklista för säkerhet i CI/CD-pipelines

Arbetsflöden

• Lås tredjeparts-actions till en fullständig commit-SHA. GitHub beskriver detta som det för närvarande enda sättet att använda en action som en oföränderlig release. En tagg kan ändras så att den pekar på annan kod. I mars 2025 rapporterade CISA att alla versioner av tj-actions/changed-files var komprometterade i tre dagar.
• Ge GITHUB_TOKEN minsta möjliga behörighet. Använd skrivskyddad åtkomst till innehåll som standard och ge mer per jobb.
• Checka aldrig ut opålitlig kod i pull_request_target. De här arbetsflödena körs med hemligheter och utökade behörigheter.
• Håll opålitlig indata borta från skript. Skicka titlar, grennamn och andra användarstyrda värden via en miljövariabel i stället för att expandera dem i ett skalkommando.
• Granska ändringar i arbetsflödesfiler. Kräv granskning av en kodägare för .github/workflows.

Hemligheter

• Föredra kortlivade inloggningsuppgifter. Använd OpenID Connect så att jobb får kortlivade, avgränsade tokens från din molnleverantör i stället för långlivade nycklar lagrade som hemligheter.
• Avgränsa hemligheter till miljöer. Lägg produktionsuppgifter bakom en miljö med obligatoriska granskare.
• Rotera efter en incident. CISA:s råd efter komprometteringen av tj-actions var att behandla exponerade hemligheter som komprometterade och rotera dem omedelbart.

Runners

• Använd tillfälliga runners. En ny maskin för varje jobb lämnar inget kvar åt nästa.
• Håll egenhostade runners borta från publika repon. GitHub säger att de nästan aldrig bör användas där, eftersom vem som helst kan öppna en pull request mot repot.
• Isolera jobb. Ett jobb ska inte kunna läsa ett annat jobbs arbetsyta eller inloggningsuppgifter.

Nätverk

• Kontrollera utgående trafik. Tillåt de paketkällor och tjänster som ett jobb behöver och blockera resten, så att ett komprometterat beroende inte kan skicka ut hemligheter. Så stoppar en egress-policy exfiltrering
• Registrera anslutningar. Spara en spårning av vad varje jobb anslöt till, så att du kan utreda det senare.

Beroenden

• Checka in lockfiler. Byggen ska lösa samma versioner varje gång.
• Granska nya beroenden. Kontrollera vad en pull request lägger till innan den slås samman.
• Spärra byggen utifrån fynd. Blockera ett bygge när det drar in ett paket med en känd kritisk sårbarhet, innan artefakten levereras.

Byggbevis

• Registrera en SBOM över vad bygget hämtade. En skanning av filer i efterhand beskriver vad som deklarerades, inte vad bygget använde.
• Signera proveniens. Koppla varje artefakt till bygget som producerade den, så att du senare kan kontrollera att det som körs är det som byggdes.
• Bevaka det som levererats. Kontrollera släppta byggen på nytt när nya sårbarheter publiceras.

Vilka verktyg täcker vilka punkter

Skannrar täcker punkterna om beroenden, verktyg för pipelinehärdning täcker punkterna om arbetsflöden, och agenter på runnern eller en säker runner täcker punkterna om nätverk och bevis. CRACI är runnern: den upprätthåller en egress-policy som blockerar vid fel, registrerar en SBOM över vad varje jobb hämtade, låter policyspärrar blockera ett bygge utifrån fynd och returnerar SBOM:er, nätverksspårningar och proveniens via sitt API. Den skannar inte kod eller arbetsflöden. Se verktyg för CI/CD-säkerhet i jämförelse för vilket verktyg som täcker vad.

Säkerhet i CI/CD-pipelines: vanliga frågor

Vad är säkerhet i CI/CD-pipelines?

Det innebär att skydda systemen som bygger och levererar din programvara: arbetsflödesdefinitionerna, hemligheterna de använder, runnerna som kör dem, beroendena de laddar ner och artefakterna de producerar. En komprometterad pipeline kan leverera skadlig kod i ditt namn utan att röra din källkod.

Varför ska GitHub Actions låsas till en commit-SHA?

Taggar kan ändras så att de pekar på annan kod. GitHub anger att låsning av en action till en fullständig commit-SHA för närvarande är det enda sättet att använda en action som en oföränderlig release. I mars 2025 rapporterade CISA att alla versioner av tj-actions/changed-files var komprometterade i tre dagar.

Vilka behörigheter ska GITHUB_TOKEN ha?

Det minimum som varje jobb behöver. Sätt standarden till skrivskyddad åtkomst för repots innehåll och ge mer per jobb, bara där ett jobb behöver det.

Behöver jag kontroll av utgående trafik i CI?

Om dina jobb har tillgång till hemligheter och kör tredjepartskod, ja. De flesta jobb behöver bara nå en känd uppsättning paketregister och tjänster. En egress-policy blockerar allt annat, så att ett komprometterat beroende inte kan skicka hemligheter till en angripares server.