CI/CD-sikkerhed

Derfor er pipelines et mål

• De har nøglerne. Cloud-legitimationsoplysninger, registry-tokens og signeringsnøgler passerer alle gennem CI.
• De kører andres kode. Hver afhængighed, hvert install-script og hver tredjeparts-action eksekveres på runneren.
• De når produktion. Det, der kommer ud af pipelinen, bliver betragtet som pålideligt, signeret og leveret. En angriber i buildet når alle kunder på én gang.
• Få holder øje med dem. Workflow-filer ændres sjældent og får mindre gennemgang end applikationskode.

Kompromitteringen af tj-actions og Shai-Hulud-ormen i npm gik begge efter secrets i CI. Se hvad er et forsyningskædeangreb for, hvordan disse angreb udvikler sig.

De største CI/CD-sikkerhedsrisici

OWASP Top 10 CI/CD Security Risks er standardreferencen. Grupperet efter, hvad der går galt:

Område	OWASP-risici	Sådan ser det ud
Hvem kan ændre hvad	Insufficient flow control, inadequate identity and access management	Kode når produktion uden gennemgang, eller gamle konti beholder deres adgang
Hvad der kører i pipelinen	Dependency chain abuse, poisoned pipeline execution	En ondsindet pakke eller et ændret workflow kører med jobbets adgang
Hvad et job kan nå	Insufficient pipeline-based access controls, insufficient credential hygiene	Ét job kan læse alle secrets, og tokens lever i årevis
Hvordan det er sat op	Insecure system configuration, ungoverned use of third-party services	Runnere uden patches og integrationer med mere adgang, end de har brug for
Hvad du kan bevise	Improper artifact integrity validation, insufficient logging and visibility	Ingen kan se, hvad der gik ind i en release, eller hvad et job forbandt sig til

Se runner-sikkerhed sammenlignet for hver risiko koblet til runner-kontroller.

Bedste praksis for CI/CD-sikkerhed

1. Behandl pipeline-definitioner som produktionskode. Kræv gennemgang af workflow-filer, og hold pull requests, du ikke stoler på, væk fra secrets.
2. Begræns, hvad hvert job kan. Giv tokens de mindste rettigheder, de har brug for, og foretræk kortlivede legitimationsoplysninger frem for gemte secrets.
3. Fastlås tredjeparts-actions til et commit-hash. Tags kan flyttes til anden kode.
4. Isolér jobs. Kør hvert job i et nyt miljø, så intet følger med over i det næste.
5. Kontrollér udgående trafik. Et build har brug for kendte kilder og kendte destinationer. Blokerer du alt andet, kan stjålne secrets ikke slippe ud. Se egress-politik for GitHub Actions.
6. Registrér, hvad der skete. Gem en SBOM af hvert build og en log over dets netværksaktivitet, så du kan besvare spørgsmål bagefter.

Se tjeklisten for CI/CD-pipelinesikkerhed for versionen trin for trin.

Typer af CI/CD-sikkerhedsværktøjer

Type	Hvad det gør	Eksempler
Runner-sikkerhed	Isolerer jobs og kontrollerer, hvad de kan nå, mens de kører	CRACI, StepSecurity
Posture management	Finder risikable pipeline- og repository-indstillinger	Legit Security, Cycode, Apiiro, OX Security
Kode- og afhængighedsscanning	Tjekker kode, afhængigheder og secrets ved hver ændring	GitHub Advanced Security, Snyk, Semgrep
SBOM og dokumentation	Registrerer, hvad der gik ind i hver release	CRACI, Syft, Anchore

De virker på forskellige stadier, så de fleste teams kombinerer dem. En scanner ser på filer før buildet, posture-værktøjer ser på indstillinger, og runner-sikkerhed virker, mens jobbet kører, og det er dér, en ondsindet pakke slår til. Se værktøjer til forsyningskædesikkerhed for software sammenlignet og DevSecOps-værktøjer sammenlignet.

Hvor CRACI passer ind

CRACI sikrer buildet, mens det kører. Det erstatter dine GitHub-hostede runnere med hurtigere og billigere runnere: Hvert job kører i sin egen isolerede virtuelle maskine, en egress-politik blokerer forbindelser, buildet ikke har brug for, og hver pakke, jobbet henter, kommer med i en SBOM. Fordi politikken kun tillader det, buildet har brug for, beskytter den dig, selv mod et angreb, ingen har set før.

CRACI tjekker ikke din workflow-konfiguration, scanner ikke kildekode eller secrets og signerer ikke provenance, så behold eller tilføj værktøjer til det. GitHub Actions er det understøttede CI-system i dag, og andre CI-systemer er på roadmappen.

CI/CD-sikkerhed: ofte stillede spørgsmål

Hvad er CI/CD-sikkerhed?

Det er praksissen med at beskytte de pipelines, der bygger, tester og leverer software, herunder deres legitimationsoplysninger, den kode, de kører, og de artefakter, de producerer.

Hvad er de største CI/CD-sikkerhedsrisici?

Ondsindede afhængigheder og tredjeparts-actions, forgiftede pipelines, tokens med for mange rettigheder og langlivede secrets samt manglende indsigt i, hvad et build gjorde. OWASP Top 10 CI/CD Security Risks er standardlisten.

Hvad er poisoned pipeline execution?

En angriber ændrer, hvad en pipeline kører, for eksempel ved gennem en pull request at redigere en workflow-fil eller et script, den kalder, så angriberens kode kører med pipelinens adgang.

Hvordan sikrer du en CI/CD-pipeline?

Gennemgå pipeline-ændringer, giv hvert job den mindste adgang, det har brug for, fastlås tredjeparts-actions til et commit-hash, isolér jobs, begræns udgående trafik, og gem en registrering af, hvad hvert build gjorde.

Hvad er forskellen på CI/CD-sikkerhed og DevSecOps?

DevSecOps er den bredere praksis med at bygge sikkerhed ind i den måde, software udvikles på. CI/CD-sikkerhed fokuserer på selve pipelinen, som DevSecOps-værktøjer også er afhængige af.

Har GitHub Actions brug for ekstra sikkerhed?

GitHub tilbyder kontroller som token-rettigheder og secret scanning, men du skal selv konfigurere dem, og hostede runnere begrænser ikke udgående trafik som standard. De fleste teams tilføjer fastlåsning, gennemgangsregler og runner-kontroller.