Tjekliste for CI/CD-pipelinesikkerhed

Workflows

• Fastlås tredjeparts-actions på en fuld commit-SHA. Ifølge GitHub er det i øjeblikket den eneste måde at bruge en action som en uforanderlig release på. Et tag kan ændres, så det peger på anden kode. I marts 2025 rapporterede CISA, at alle versioner af tj-actions/changed-files var kompromitteret i tre dage.
• Giv GITHUB_TOKEN mindst mulige rettigheder. Brug skrivebeskyttet som standard for indhold, og giv mere pr. job.
• Tjek aldrig kode, du ikke stoler på, ud i pull_request_target. Disse workflows kører med secrets og forhøjede rettigheder.
• Hold input, du ikke stoler på, ude af scripts. Send titler, branch-navne og andre brugerstyrede værdier gennem en miljøvariabel i stedet for at ekspandere dem i en shell-kommando.
• Gennemgå ændringer i workflow-filer. Kræv gennemgang fra en code owner for .github/workflows.

Secrets

• Foretræk kortlivede legitimationsoplysninger. Brug OpenID Connect, så jobs får kortlivede, afgrænsede tokens fra din cloud-udbyder i stedet for langlivede nøgler gemt som secrets.
• Afgræns secrets til environments. Læg legitimationsoplysninger til produktion bag et environment med påkrævede reviewers.
• Rotér efter en hændelse. CISA's råd efter kompromitteringen af tj-actions var at betragte eksponerede secrets som kompromitterede og rotere dem med det samme.

Runnere

• Brug flygtige runnere. En ny maskine for hvert job efterlader intet til det næste.
• Hold selvhostede runnere ude af offentlige repositories. GitHub siger, at de næsten aldrig bør bruges der, fordi alle kan åbne en pull request mod repositoriet.
• Isolér jobs. Ét job bør ikke kunne læse et andet jobs workspace eller legitimationsoplysninger.

Netværk

• Styr udgående trafik. Tillad de pakkekilder og tjenester, et job har brug for, og blokér resten, så en kompromitteret afhængighed ikke kan sende secrets ud. Sådan stopper en egress-politik eksfiltrering
• Registrér forbindelser. Gem et trace af, hvad hvert job forbandt sig til, så du kan undersøge det senere.

Afhængigheder

• Commit lockfiles. Builds bør resolve de samme versioner hver gang.
• Gennemgå nye afhængigheder. Tjek, hvad en pull request tilføjer, før den merges.
• Lad fund blokere builds. Blokér et build, når det trækker en pakke med en kendt kritisk sårbarhed ind, før artefaktet leveres.

Dokumentation fra buildet

• Registrér en SBOM over det, buildet hentede. En scanning af filer bagefter beskriver, hvad der blev deklareret, ikke hvad buildet brugte.
• Signér provenance. Kobl hvert artefakt til det build, der producerede det, så du senere kan tjekke, at det, der kører, er det, der blev bygget.
• Overvåg det leverede. Tjek udgivne builds igen, når nye sårbarheder offentliggøres.

Hvilke værktøjer dækker hvilke punkter

Scannere dækker punkterne om afhængigheder, værktøjer til pipelinehærdning dækker punkterne om workflows, og agenter på runneren eller en sikker runner dækker punkterne om netværk og dokumentation. CRACI er runneren: Det håndhæver en egress-politik, der blokerer ved fejl, registrerer en SBOM over det, hvert job hentede, lader policy gates blokere et build på baggrund af fund og returnerer SBOM'er, netværkstraces og provenance via sit API. Det scanner ikke kode eller workflows. Se CI/CD-sikkerhedsværktøjer sammenlignet for, hvilket værktøj der dækker hvad.

Sikkerhed i CI/CD-pipelines: ofte stillede spørgsmål

Hvad er sikkerhed i CI/CD-pipelines?

Det er at beskytte de systemer, der bygger og leverer din software: workflow-definitionerne, de secrets, de bruger, de runnere, der kører dem, de afhængigheder, de downloader, og de artefakter, de producerer. En kompromitteret pipeline kan levere ondsindet kode i dit navn uden at røre din kildekode.

Hvorfor fastlåse GitHub Actions på en commit-SHA?

Tags kan ændres, så de peger på anden kode. GitHub oplyser, at fastlåsning af en action på en fuld commit-SHA i øjeblikket er den eneste måde at bruge en action som en uforanderlig release på. I marts 2025 rapporterede CISA, at alle versioner af tj-actions/changed-files var kompromitteret i tre dage.

Hvilke rettigheder skal GITHUB_TOKEN have?

Det minimum, hvert job har brug for. Sæt standarden til skrivebeskyttet for repository-indhold, og giv mere pr. job, kun hvor et job har brug for det.

Har jeg brug for kontrol af udgående netværkstrafik i CI?

Ja, hvis dine jobs har adgang til secrets og kører tredjepartskode. De fleste jobs behøver kun at nå et kendt sæt pakkeregistries og tjenester. En egress-politik blokerer alt andet, så en kompromitteret afhængighed ikke kan sende secrets til en angribers server.