Beveiligingschecklist voor CI/CD-pipelines

Workflows

• Pin actions van derden vast op een volledige commit-SHA. Volgens GitHub is dit momenteel de enige manier om een action als onveranderlijke release te gebruiken. Een tag kan worden gewijzigd zodat die naar andere code wijst. In maart 2025 meldde CISA dat elke versie van tj-actions/changed-files drie dagen lang gecompromitteerd was.
• Geef GITHUB_TOKEN de minste rechten. Gebruik standaard alleen-lezen voor inhoud en ken per job meer toe.
• Check nooit niet-vertrouwde code uit in pull_request_target. Deze workflows draaien met secrets en verhoogde rechten.
• Houd niet-vertrouwde invoer uit scripts. Geef titels, branchnamen en andere door gebruikers beheerde waarden door via een omgevingsvariabele in plaats van ze in een shellopdracht te expanderen.
• Beoordeel wijzigingen in workflowbestanden. Vereis een beoordeling door een code owner voor .github/workflows.

Secrets

• Geef de voorkeur aan kortlevende inloggegevens. Gebruik OpenID Connect, zodat jobs kortlevende tokens met beperkte scope van uw cloudprovider krijgen in plaats van langlevende sleutels die als secrets zijn opgeslagen.
• Beperk secrets tot omgevingen. Zet productie-inloggegevens achter een omgeving met verplichte reviewers.
• Roteer na een incident. Het advies van CISA na de tj-actions-compromittering was om blootgestelde secrets als gecompromitteerd te behandelen en ze onmiddellijk te roteren.

Runners

• Gebruik ephemeral runners. Een nieuwe machine per job laat niets achter voor de volgende.
• Houd self-hosted runners weg bij openbare repositories. Volgens GitHub moeten ze daar vrijwel nooit worden gebruikt, omdat iedereen een pull request op de repository kan openen.
• Isoleer jobs. De ene job mag de workspace of inloggegevens van een andere job niet kunnen lezen.

Netwerk

• Beheers egress. Sta de pakketbronnen en diensten toe die een job nodig heeft en blokkeer de rest, zodat een gecompromitteerde afhankelijkheid geen secrets naar buiten kan sturen. Hoe een egressbeleid exfiltratie stopt
• Leg verbindingen vast. Bewaar een trace van waarmee elke job verbinding maakte, zodat u dat later kunt onderzoeken.

Afhankelijkheden

• Commit lockfiles. Builds moeten elke keer op dezelfde versies uitkomen.
• Beoordeel nieuwe afhankelijkheden. Controleer wat een pull request toevoegt voordat die wordt gemerged.
• Laat builds afhangen van bevindingen. Blokkeer een build wanneer hij een pakket met een bekende kritieke kwetsbaarheid binnenhaalt, voordat het artefact wordt geleverd.

Buildbewijs

• Leg een SBOM vast van wat de build ophaalde. Een scan van bestanden achteraf beschrijft wat was gedeclareerd, niet wat de build heeft gebruikt.
• Onderteken herkomstgegevens. Koppel elk artefact aan de build die het heeft opgeleverd, zodat u later kunt controleren of wat draait ook is wat is gebouwd.
• Monitor wat is geleverd. Controleer uitgebrachte builds opnieuw wanneer er nieuwe kwetsbaarheden worden gepubliceerd.

Welke tools welke punten dekken

Scanners dekken de punten over afhankelijkheden, tools voor pipeline-hardening dekken de workflowpunten, en agents op de runner of een beveiligde runner dekken de netwerk- en bewijspunten. CRACI is de runner: het dwingt een fail-closed egressbeleid af, legt een SBOM vast van wat elke job ophaalde, laat policy gates een build blokkeren op bevindingen en levert SBOM's, netwerktraces en herkomstgegevens via zijn API. Het scant geen code of workflows. Zie CI/CD-beveiligingstools vergeleken voor welke tool wat dekt.

CI/CD-pipelinebeveiliging: veelgestelde vragen

Wat is CI/CD-pipelinebeveiliging?

Het is het beschermen van de systemen die uw software bouwen en leveren: de workflowdefinities, de secrets die ze gebruiken, de runners die ze uitvoeren, de afhankelijkheden die ze downloaden en de artefacten die ze opleveren. Een gecompromitteerde pipeline kan kwaadaardige code onder uw naam leveren zonder uw broncode aan te raken.

Waarom GitHub Actions vastpinnen op een commit-SHA?

Tags kunnen worden gewijzigd zodat ze naar andere code wijzen. GitHub stelt dat een action vastpinnen op een volledige commit-SHA momenteel de enige manier is om een action als onveranderlijke release te gebruiken. In maart 2025 meldde CISA dat elke versie van tj-actions/changed-files drie dagen lang gecompromitteerd was.

Welke rechten moet GITHUB_TOKEN hebben?

Het minimum dat elke job nodig heeft. Stel de standaard in op alleen-lezen voor repository-inhoud en ken per job meer toe, alleen waar een job dat nodig heeft.

Heb ik egresscontrole in CI nodig?

Als uw jobs secrets bevatten en code van derden draaien, ja. De meeste jobs hoeven alleen een bekende set pakketregistries en diensten te bereiken. Een egressbeleid blokkeert al het andere, zodat een gecompromitteerde afhankelijkheid geen secrets naar de server van een aanvaller kan sturen.