Sikkerhetssjekkliste for CI/CD-pipelines

Workflows

• Fest tredjeparts-actions til en fullstendig commit-SHA. Ifølge GitHub er dette for øyeblikket den eneste måten å bruke en action som en uforanderlig utgivelse på. En tagg kan endres til å peke på annen kode. I mars 2025 rapporterte CISA at alle versjoner av tj-actions/changed-files var kompromittert i tre dager.
• Gi GITHUB_TOKEN færrest mulig privilegier. La standarden være skrivebeskyttet for innhold, og gi mer per jobb.
• Sjekk aldri ut upålitelig kode i pull_request_target. Disse workflowene kjører med hemmeligheter og utvidede tillatelser.
• Hold upålitelig input utenfor skript. Send titler, grennavn og andre verdier brukere kontrollerer, gjennom en miljøvariabel i stedet for å ekspandere dem i en shell-kommando.
• Gå gjennom endringer i workflow-filer. Krev gjennomgang fra kodeeier for .github/workflows.

Hemmeligheter

• Foretrekk kortlevd påloggingsinformasjon. Bruk OpenID Connect, så jobber får kortlevde tokens med begrenset omfang fra skyleverandøren din i stedet for langlevde nøkler lagret som hemmeligheter.
• Avgrens hemmeligheter til miljøer. Legg produksjonspåloggingsinformasjon bak et miljø med påkrevde godkjennere.
• Roter etter en hendelse. CISAs råd etter kompromitteringen av tj-actions var å behandle eksponerte hemmeligheter som kompromitterte og rotere dem umiddelbart.

Runnere

• Bruk kortlevde runnere. En ny maskin per jobb etterlater ingenting til den neste.
• Hold selvhostede runnere unna offentlige repositorier. GitHub sier at de nesten aldri bør brukes der, fordi hvem som helst kan åpne en pull request mot repositoriet.
• Isoler jobber. Én jobb skal ikke kunne lese arbeidsområdet eller påloggingsinformasjonen til en annen jobb.

Nettverk

• Kontroller egress. Tillat pakkekildene og tjenestene en jobb trenger, og blokker resten, så en kompromittert avhengighet ikke kan sende hemmeligheter ut. Slik stopper en egress-policy eksfiltrering
• Registrer tilkoblinger. Ta vare på et spor av hva hver jobb koblet seg til, så du kan undersøke det senere.

Avhengigheter

• Commit lockfiler. Bygg bør løse de samme versjonene hver gang.
• Vurder nye avhengigheter. Sjekk hva en pull request legger til, før den merges.
• Stopp bygg på grunn av funn. Blokker et bygg når det henter inn en pakke med en kjent kritisk sårbarhet, før artefakten leveres.

Byggdokumentasjon

• Registrer en SBOM over det bygget hentet. En skanning av filer etterpå beskriver det som ble deklarert, ikke det bygget brukte.
• Signer provenance. Knytt hver artefakt til bygget som produserte den, så du senere kan sjekke at det som kjører, er det som ble bygget.
• Overvåk det som er levert. Sjekk utgitte bygg på nytt når nye sårbarheter publiseres.

Hvilke verktøy dekker hvilke punkter

Skannere dekker punktene om avhengigheter, verktøy for pipeline-herding dekker punktene om workflows, og agenter på runneren eller en sikker runner dekker punktene om nettverk og dokumentasjon. CRACI er runneren: Det håndhever en egress-policy som blokkerer ved feil, registrerer en SBOM over det hver jobb hentet, lar policy-gates blokkere et bygg på grunn av funn og returnerer SBOM-er, nettverksspor og provenance gjennom API-et. Det skanner ikke kode eller workflows. Se CI/CD-sikkerhetsverktøy sammenlignet for hvilket verktøy som dekker hva.

Sikkerhet i CI/CD-pipelines: ofte stilte spørsmål

Hva er sikkerhet i CI/CD-pipelines?

Det er å beskytte systemene som bygger og leverer programvaren din: workflow-definisjonene, hemmelighetene de bruker, runnerne som kjører dem, avhengighetene de laster ned, og artefaktene de produserer. En kompromittert pipeline kan levere ondsinnet kode i ditt navn uten å røre kildekoden din.

Hvorfor feste GitHub Actions til en commit-SHA?

Tagger kan endres til å peke på annen kode. GitHub oppgir at å feste en action til en fullstendig commit-SHA for øyeblikket er den eneste måten å bruke en action som en uforanderlig utgivelse på. I mars 2025 rapporterte CISA at alle versjoner av tj-actions/changed-files var kompromittert i tre dager.

Hvilke tillatelser bør GITHUB_TOKEN ha?

Minimum av det hver jobb trenger. Sett standarden til skrivebeskyttet for innholdet i repositoriet, og gi mer per jobb, bare der en jobb trenger det.

Trenger jeg kontroll på utgående nettverkstrafikk i CI?

Ja, hvis jobbene dine har hemmeligheter og kjører tredjepartskode. De fleste jobber trenger bare å nå et kjent sett med pakkeregistre og tjenester. En egress-policy blokkerer alt annet, så en kompromittert avhengighet ikke kan sende hemmeligheter til en angripers server.