CI/CD-sikkerhet

Hvorfor pipelines er et mål

• De har nøklene. Påloggingsinformasjon for skyen, registertokens og signeringsnøkler går alle gjennom CI.
• De kjører andres kode. Hver avhengighet, hvert installasjonsskript og hver tredjeparts-action kjører på runneren.
• De når produksjon. Det som kommer ut av pipelinen, blir stolt på, signert og levert. En angriper i bygget når alle kunder på én gang.
• Få følger med på dem. Workflow-filer endres sjelden og blir gjennomgått mindre enn applikasjonskode.

Både tj-actions-kompromitteringen og Shai-Hulud-ormen i npm gikk etter hemmeligheter i CI. Se hva er et leverandørkjedeangrep for hvordan slike angrep utvikler seg.

De viktigste risikoene i CI/CD-sikkerhet

OWASP Top 10 CI/CD Security Risks er standardreferansen. Gruppert etter hva som går galt:

Område	OWASP-risikoer	Slik ser det ut
Hvem som kan endre hva	Utilstrekkelig flytkontroll, mangelfull identitets- og tilgangsstyring	Kode når produksjon uten gjennomgang, eller gamle kontoer beholder tilgangen sin
Hva som kjører i pipelinen	Misbruk av avhengighetskjeden, poisoned pipeline execution	En ondsinnet pakke eller en endret workflow kjører med jobbens tilgang
Hva en jobb kan nå	Utilstrekkelig pipelinebasert tilgangskontroll, utilstrekkelig hygiene for påloggingsinformasjon	Én jobb kan lese alle hemmeligheter, og tokens lever i årevis
Hvordan det er satt opp	Usikker systemkonfigurasjon, ukontrollert bruk av tredjepartstjenester	Upatchede runnere og integrasjoner med mer tilgang enn de trenger
Hva du kan bevise	Mangelfull validering av artefaktintegritet, utilstrekkelig logging og synlighet	Ingen kan si hva som gikk inn i en utgivelse eller hva en jobb koblet seg til

For hver risiko koblet til runnerkontroller, se runnersikkerhet sammenlignet.

Beste praksis for CI/CD-sikkerhet

1. Behandle pipelinedefinisjoner som produksjonskode. Krev gjennomgang av workflow-filer, og hold pull requests du ikke stoler på, unna hemmeligheter.
2. Begrens hva hver jobb kan gjøre. Gi tokens de minste rettighetene de trenger, og foretrekk kortlevd påloggingsinformasjon fremfor lagrede hemmeligheter.
3. Fest tredjeparts-actions til en commit-hash. Tagger kan flyttes til annen kode.
4. Isoler jobber. Kjør hver jobb i et nytt miljø, så ingenting følger med til den neste.
5. Kontroller utgående trafikk. Et bygg trenger kjente kilder og kjente mål. Blokkerer du alt annet, kommer ikke stjålne hemmeligheter ut. Se egress-policy for GitHub Actions.
6. Registrer hva som skjedde. Behold en SBOM for hvert bygg og en logg over nettverksaktiviteten, så du kan svare på spørsmål i etterkant.

Den trinnvise versjonen finner du i sikkerhetssjekklisten for CI/CD-pipelines.

Typer verktøy for CI/CD-sikkerhet

Type	Hva det gjør	Eksempler
Runnersikkerhet	Isolerer jobber og styrer hva de kan nå mens de kjører	CRACI, StepSecurity
Posture management	Finner risikable innstillinger i pipelines og repositorier	Legit Security, Cycode, Apiiro, OX Security
Kode- og avhengighetsskanning	Sjekker kode, avhengigheter og hemmeligheter ved hver endring	GitHub Advanced Security, Snyk, Semgrep
SBOM og dokumentasjon	Registrerer hva som gikk inn i hver utgivelse	CRACI, Syft, Anchore

Disse virker på ulike stadier, så de fleste team kombinerer dem. En skanner ser på filer før bygget, posture-verktøy ser på innstillinger, og runnersikkerhet virker mens jobben kjører, og det er da en ondsinnet pakke slår til. Se verktøy for sikkerhet i programvareleverandørkjeden sammenlignet og DevSecOps-verktøy sammenlignet.

Hvor CRACI passer inn

CRACI sikrer bygget mens det kjører. Det erstatter de GitHub-hostede runnerne dine med raskere og rimeligere runnere: Hver jobb kjører i sin egen isolerte virtuelle maskin, en egress-policy blokkerer tilkoblinger bygget ikke trenger, og hver pakke jobben henter, havner i en SBOM. Fordi policyen bare tillater det bygget trenger, beskytter den deg selv mot et angrep ingen har sett før.

CRACI sjekker ikke workflow-konfigurasjonen din, skanner ikke kildekode eller hemmeligheter og signerer ikke provenance, så behold eller legg til verktøy for det. GitHub Actions er det støttede CI-systemet i dag, og andre CI-systemer står på veikartet.

CI/CD-sikkerhet: ofte stilte spørsmål

Hva er CI/CD-sikkerhet?

Det er praksisen med å beskytte pipelines som bygger, tester og leverer programvare, inkludert påloggingsinformasjonen deres, koden de kjører og artefaktene de produserer.

Hva er de største risikoene i CI/CD-sikkerhet?

Ondsinnede avhengigheter og tredjeparts-actions, forgiftede pipelines, tokens med for mange rettigheter og langlivede hemmeligheter, og mangel på innsyn i hva et bygg gjorde. OWASP Top 10 CI/CD Security Risks er standardlisten.

Hva er poisoned pipeline execution?

En angriper endrer hva en pipeline kjører, for eksempel ved å redigere en workflow-fil eller et skript den kaller, gjennom en pull request, slik at angriperens kode kjører med pipelinens tilgang.

Hvordan sikrer du en CI/CD-pipeline?

Gå gjennom endringer i pipelinen, gi hver jobb den minste tilgangen den trenger, fest tredjeparts-actions til en commit-hash, isoler jobber, begrens utgående trafikk og behold en oversikt over hva hvert bygg gjorde.

Hva er forskjellen på CI/CD-sikkerhet og DevSecOps?

DevSecOps er den bredere praksisen med å bygge sikkerhet inn i måten programvare utvikles på. CI/CD-sikkerhet konsentrerer seg om selve pipelinen, som DevSecOps-verktøy også er avhengige av.

Trenger GitHub Actions ekstra sikkerhet?

GitHub tilbyr kontroller som tokenrettigheter og secret scanning, men du må konfigurere dem selv, og hostede runnere begrenser ikke utgående trafikk som standard. De fleste team legger til festing, gjennomgangsregler og runnerkontroller.