CI/CD-beveiliging

Waarom pipelines een doelwit zijn

• Ze hebben de sleutels. Cloudinloggegevens, registrytokens en ondertekeningssleutels gaan allemaal door CI.
• Ze draaien code van anderen. Elke afhankelijkheid, elk installatiescript en elke action van derden wordt uitgevoerd op de runner.
• Ze bereiken productie. Wat uit de pipeline komt, wordt vertrouwd, ondertekend en geleverd. Een aanvaller in de build bereikt alle klanten tegelijk.
• Weinig mensen houden ze in de gaten. Workflowbestanden veranderen zelden en krijgen minder review dan applicatiecode.

De compromittering van tj-actions en de npm-worm Shai-Hulud hadden het allebei gemunt op secrets in CI. Zie wat is een aanval op de softwareketen voor hoe deze aanvallen verlopen.

De grootste CI/CD-beveiligingsrisico's

De OWASP Top 10 CI/CD Security Risks is de standaardreferentie. Gegroepeerd naar wat er misgaat:

Gebied	OWASP-risico's	Hoe het eruitziet
Wie wat kan wijzigen	Onvoldoende flowcontrole, ontoereikend identiteits- en toegangsbeheer	Code bereikt productie zonder review, of oude accounts behouden hun toegang
Wat er in de pipeline draait	Misbruik van de afhankelijkheidsketen, poisoned pipeline execution	Een kwaadaardig pakket of een gewijzigde workflow draait met de toegang van de job
Wat een job kan bereiken	Onvoldoende pipelinegebaseerde toegangscontroles, onvoldoende hygiëne van inloggegevens	Eén job kan elk secret lezen, en tokens blijven jarenlang geldig
Hoe het is ingericht	Onveilige systeemconfiguratie, ongecontroleerd gebruik van diensten van derden	Ongepatchte runners, en integraties met meer toegang dan ze nodig hebben
Wat u kunt aantonen	Ontoereikende validatie van artefactintegriteit, onvoldoende logging en zichtbaarheid	Niemand kan zeggen wat er in een release is gegaan of waarmee een job verbinding maakte

Zie runnerbeveiliging vergeleken voor elk risico, gekoppeld aan runnermaatregelen.

Best practices voor CI/CD-beveiliging

1. Behandel pipelinedefinities als productiecode. Eis een review op workflowbestanden, en houd niet-vertrouwde pull requests weg van secrets.
2. Beperk wat elke job kan doen. Geef tokens de minste rechten die ze nodig hebben, en geef de voorkeur aan kortlevende inloggegevens boven opgeslagen secrets.
3. Pin actions van derden vast op een commit-hash. Tags kunnen naar andere code worden verplaatst.
4. Isoleer jobs. Laat elke job draaien in een nieuwe omgeving, zodat er niets meegaat naar de volgende.
5. Beheers uitgaand verkeer. Een build heeft bekende bronnen en bekende bestemmingen nodig. Door al het andere te blokkeren, voorkomt u dat gestolen secrets de build verlaten. Zie egressbeleid voor GitHub Actions.
6. Leg vast wat er is gebeurd. Bewaar van elke build een SBOM en een log van de netwerkactiviteit, zodat u achteraf vragen kunt beantwoorden.

Zie voor de stapsgewijze versie de beveiligingschecklist voor CI/CD-pipelines.

Soorten CI/CD-beveiligingstools

Type	Wat het doet	Voorbeelden
Runnerbeveiliging	Isoleert jobs en bepaalt wat ze kunnen bereiken terwijl ze draaien	CRACI, StepSecurity
Posture management	Vindt riskante instellingen van pipelines en repositories	Legit Security, Cycode, Apiiro, OX Security
Scannen van code en afhankelijkheden	Controleert code, afhankelijkheden en secrets bij elke wijziging	GitHub Advanced Security, Snyk, Semgrep
SBOM en bewijs	Legt vast wat er in elke release is gegaan	CRACI, Syft, Anchore

Deze tools werken in verschillende fasen, dus de meeste teams combineren ze. Een scanner kijkt vóór de build naar bestanden, posture-tools kijken naar instellingen en runnerbeveiliging werkt terwijl de job draait, en dat is het moment waarop een kwaadaardig pakket toeslaat. Zie tools voor ketenbeveiliging van software vergeleken en DevSecOps-tools vergeleken.

Waar CRACI past

CRACI beveiligt de build terwijl hij draait. Het vervangt uw door GitHub gehoste runners door snellere, goedkopere runners: elke job draait in een eigen geïsoleerde virtuele machine, een egressbeleid blokkeert verbindingen die de build niet nodig heeft, en elk pakket dat de job ophaalt, komt in een SBOM. Omdat het beleid alleen toestaat wat de build nodig heeft, beschermt het u zelfs tegen een aanval die nog niemand heeft gezien.

CRACI controleert uw workflowconfiguratie niet, scant geen broncode of secrets en ondertekent geen herkomstgegevens, dus behoud daarvoor tools of voeg ze toe. GitHub Actions is vandaag het ondersteunde CI-systeem, en andere CI-systemen staan op de roadmap.

CI/CD-beveiliging: veelgestelde vragen

Wat is CI/CD-beveiliging?

Het is het beschermen van de pipelines die software bouwen, testen en leveren, inclusief hun inloggegevens, de code die ze draaien en de artefacten die ze produceren.

Wat zijn de grootste CI/CD-beveiligingsrisico's?

Kwaadaardige afhankelijkheden en actions van derden, vergiftigde pipelines, tokens met te veel rechten en langlevende secrets, en een gebrek aan zicht op wat een build heeft gedaan. De OWASP Top 10 CI/CD Security Risks is de standaardlijst.

Wat is poisoned pipeline execution?

Een aanvaller wijzigt wat een pipeline uitvoert, bijvoorbeeld door via een pull request een workflowbestand of een aangeroepen script aan te passen, zodat zijn code draait met de toegang van de pipeline.

Hoe beveiligt u een CI/CD-pipeline?

Beoordeel pipelinewijzigingen, geef elke job de minste toegang die hij nodig heeft, pin actions van derden vast op een commit-hash, isoleer jobs, beperk uitgaand verkeer en leg vast wat elke build heeft gedaan.

Wat is het verschil tussen CI/CD-beveiliging en DevSecOps?

DevSecOps is de bredere praktijk om beveiliging in te bouwen in de manier waarop software wordt ontwikkeld. CI/CD-beveiliging richt zich op de pipeline zelf, waarvan ook DevSecOps-tools afhankelijk zijn.

Heeft GitHub Actions extra beveiliging nodig?

GitHub biedt voorzieningen zoals tokenrechten en secret scanning, maar die moet u zelf configureren, en gehoste runners beperken uitgaand verkeer standaard niet. De meeste teams voegen pinning, reviewregels en runnermaatregelen toe.