CI/CD-beveiliging
Exfiltratie uit GitHub Actions stoppen met een egressbeleid
Een CI-job bevat secrets en voert code uit die hij een minuut geleden heeft gedownload: actions, pakketten en hun installatiescripts. Is een deel van die code kwaadaardig, dan is de makkelijkste manier om de secrets te stelen ze naar een server te sturen. Een egressbeleid bepaalt welke servers een job mag bereiken en blokkeert de rest.
Bijgewerkt op
Hoe secrets een CI-job verlaten
Een job heeft toegang tot het repositorytoken, de secrets die eraan worden doorgegeven en alle cloudinloggegevens die hij gebruikt. Code die in de job draait, kan die lezen. Daarna kan die code ze op een paar manieren naar buiten krijgen:
- Via het netwerk. Een verzoek aan een server die de aanvaller beheert. Dit is het kanaal dat een egressbeleid sluit.
- Via logs. Secrets, vaak gecodeerd, naar het joblog schrijven. In maart 2025 meldde CISA dat de gecompromitteerde action tj-actions/changed-files op deze manier secrets blootstelde.
- Via uitvoer. Artefacten, caches of commits die met het token van de job worden gepusht.
De code hoeft geen kwaadaardig pakket te zijn. Een AI-agent in de workflow kan door prompt injection die in een issue of pull request is verborgen, tegen u worden gekeerd en vervolgens dezelfde kanalen gebruiken.
Wat een egressbeleid doet
De meeste jobs moeten een korte lijst bestemmingen bereiken: pakketbronnen, container registries, bronhosts en enkele diensten. Een egressbeleid staat die lijst toe en blokkeert al het andere. Met een beleid van standaard weigeren mislukt een verzoek aan een onbekende host, en blijven de secrets in de job.
Het sluit niet elke deur:
- Het voorkomt niet dat secrets naar logs worden geschreven. Houd logs privé en pin actions vast op commit-SHA's.
- Een bestemming die u toestaat, kan nog steeds gegevens naar buiten brengen, dus houd de allowlist beperkt.
- Het vertelt u niet welke pakketten kwaadaardig waren. Dat is de taak van package screening en een SBOM.
Drie manieren om het af te dwingen
- Een agent op de runner. StepSecurity Harden-Runner wordt toegevoegd als eerste stap van een job. Het koppelt elke verbinding aan de stap die hem maakte, bouwt een baseline op in auditmodus en blokkeert egress naar alles wat niet op een allowlist staat.
- Een runner met ingebouwd beleid. CRACI dwingt het beleid af als de runner zelf. Andere runneraanbieders bieden ook netwerkcontroles, zoals egressfiltering op de Linux-runners van Depot en blokkerend of adviserend egressbeleid op Namespace.
- Uw eigen netwerk. Self-hosted runners achter een firewall of proxy die u zelf configureert en onderhoudt.
Uitrollen zonder builds stuk te maken
- Observeren. Leg elke verbinding vast die een job over een paar runs maakt.
- Toestaan. Bouw de allowlist op uit wat de job echt nodig heeft.
- Blokkeren. Schakel over op standaard weigeren en let op overtredingen.
- Beoordelen. Behandel elke nieuwe overtreding als een ontbrekende bron of als een incident.
Hoe CRACI het doet
Op CRACI maakt het egressbeleid deel uit van de runner. Het wordt gevalideerd voordat de job start, onbekende velden worden geweigerd en het werkt fail-closed. Ingebouwde presets dekken gangbare pakketbronnen, en eigen bronnen en verbindingen vullen de rest aan. De jobtrace toont elke verbinding, en elke geblokkeerde verbinding als overtreding met de reden. Omdat de proxy pakketten herkent, wordt dezelfde vastlegging de SBOM van de job. De API levert SBOM's, netwerktraces en herkomstgegevens.
CRACI heeft nog geen speciale auditmodus; die staat op de roadmap. Zonder netwerkbeleid wordt het verkeer van een job toegestaan en in de trace vastgelegd, zodat u kunt zien wat een beleid nodig heeft voordat u het afdwingt. CRACI draait GitHub Actions-jobs op Linux. Zie CI/CD-beveiligingstools vergeleken en CRACI vs StepSecurity.
Egressbeleid in CI: veelgestelde vragen
Wat is een egressbeleid in CI?
Een set regels voor de uitgaande netwerkverbindingen die een CI-job mag maken. De job kan de pakketbronnen en diensten bereiken die hij nodig heeft, en elke andere bestemming wordt geblokkeerd.
Had een egressbeleid de compromittering van tj-actions gestopt?
Alleen daarmee niet. In dat geval meldde CISA dat secrets via workflowlogs waren blootgesteld, niet naar een externe server waren verstuurd. Een egressbeleid sluit het netwerkkanaal; actions vastpinnen op commit-SHA's en logs privé houden pakken het logkanaal aan.
Maakt het blokkeren van egress builds stuk?
Dat kan, als het beleid een bron mist die de build nodig heeft. Leg eerst vast waarmee de job verbinding maakt, bouw daaruit de allowlist op en blokkeer daarna. Op CRACI dekken ingebouwde presets gangbare pakketbronnen, en een geblokkeerde verbinding verschijnt met de reden in de jobtrace.
Kan ik een egressbeleid gebruiken op door GitHub gehoste runners?
Ja, met een agent die aan de job wordt toegevoegd, zoals StepSecurity Harden-Runner. Of verplaats de job naar een runner die het beleid zelf afdwingt, zoals CRACI.
Zet één job achter een egressbeleid
Draai één workflow op CRACI en zie elke verbinding die hij maakte, welke een beleid van standaard weigeren zou blokkeren, en de SBOM van wat hij ophaalde.
Demo boeken