Je CI/CD-pipeline is een van de krachtigste — en gevaarlijkste — systemen in je infrastructuur. Het heeft toegang tot broncode, secrets, cloudcredentials, productieomgevingen en containerregistries. Een gecompromitteerde pipeline kan kwaadaardige code rechtstreeks naar productie deployen, secrets exfiltreren of een aanvaller persistente toegang geven tot je volledige infrastructuur. Het hardenen van je pipeline is niet optioneel — het is een kritieke beveiligingsvereiste.
Het aanvalsoppervlak begrijpen
CI/CD-pipelines presenteren een breed aanvalsoppervlak dat veel organisaties onderschatten:
- Broncoderepositories — gecompromitteerde ontwikkelaarsaccounts of kwaadaardige pull requests kunnen code injecteren die de pipeline zal bouwen en deployen.
- Pipelineconfiguratie — als pipelinedefinities (Jenkinsfiles, GitHub Actions workflows, GitLab CI YAML) in de repository worden opgeslagen, kan iedereen met schrijftoegang het buildproces wijzigen.
- Afhankelijkheden — supply chain-aanvallen via gecompromitteerde pakketten, container base images of buildtools kunnen kwaadaardige code injecteren tijdens het bouwen.
- Secrets en credentials — API-sleutels, cloudcredentials en deploymenttokens die in de pipeline zijn opgeslagen, zijn waardevolle doelwitten.
- Buildomgevingen — gedeelde buildrunners kunnen secrets lekken tussen projecten of laterale beweging tussen teams mogelijk maken.
Broncode en pipelineconfiguratie beveiligen
- Codereview vereisen — verplicht pull request reviews voordat code de hoofdbranch bereikt. Gebruik branchbeschermingsregels om directe pushes naar productiebranches te voorkomen.
- Pipelinedefinities beschermen — behandel CI/CD-configuratiebestanden met dezelfde zorgvuldigheid als applicatiecode. Wijzigingen aan workflowbestanden zouden extra review van een security- of platformteam moeten vereisen.
- Commits ondertekenen — implementeer commit-signing met GPG- of SSH-sleutels om de identiteit van code-auteurs te verifieren en commit-spoofing te voorkomen.
- Repositoryrechten beperken — volg het principe van minimale rechten. Niet elke ontwikkelaar heeft schrijftoegang tot elke repository nodig, en externe bijdragers mogen nooit automatisch pipeline-runs triggeren.
Secretbeheer
Goed secretbeheer is misschien wel het belangrijkste aspect van pipelinebeveiliging:
- Sla secrets nooit op in code — dit geldt ook voor pipelineconfiguratiebestanden, Dockerfiles en applicatiecode. Gebruik het ingebouwde secretbeheer van je CI/CD-platform of een externe kluis.
- Gebruik externe secret managers — integreer met HashiCorp Vault, AWS Secrets Manager of Azure Key Vault in plaats van uitsluitend te vertrouwen op de secretopslag van het CI-platform.
- Beperk de scope van secrets — beperk welke pipelines en omgevingen toegang hebben tot elk secret. Productiecredentials mogen niet beschikbaar zijn voor builds van ontwikkelbranches.
- Roteer regelmatig — automatiseer secretrotatie en zorg ervoor dat je pipeline credential-updates kan afhandelen zonder handmatige interventie.
- Audit toegang — log elke keer dat een secret wordt benaderd en bekijk deze logs regelmatig op afwijkingen.
Het buildproces beveiligen
- Gebruik geïsoleerde buildomgevingen — draai elke build in een verse, efemere container of VM. Hergebruik nooit buildomgevingen tussen projecten of runs. Dit voorkomt dat secrets lekken tussen builds.
- Pin afhankelijkheden — gebruik lockbestanden (package-lock.json, Pipfile.lock, go.sum) en verifieer checksums. Pin container base images op specifieke SHA-digests in plaats van muteerbare tags.
- Scan op kwetsbaarheden — integreer dependency scanning (Snyk, Trivy, Grype) en statische analyse (SonarQube, Semgrep) in elke pipeline-run. Laat builds falen die kritieke kwetsbaarheden introduceren.
- Onderteken artefacten — onderteken containerimages met Cosign of Notary en verifieer handtekeningen voor deployment. Dit garandeert dat alleen images die door je pipeline zijn gebouwd, naar productie kunnen worden gedeployd.
- Implementeer SBOM-generatie — genereer een Software Bill of Materials voor elke build om zicht te houden op welke componenten zijn opgenomen in je deployments, wat steeds belangrijker wordt voor NIS2-compliance.
Deploymentbeveiliging
- Scheid omgevingen — gebruik aparte credentials en serviceaccounts voor ontwikkel-, staging- en productiedeployments. Een gecompromitteerde dev-pipeline mag geen toegang tot productie kunnen krijgen.
- Implementeer goedkeuringspoorten — vereis handmatige goedkeuring voor productiedeployments, vooral voor gevoelige services. Veel CI/CD-platformen ondersteunen goedkeuringsworkflows native.
- Gebruik GitOps voor productie — overweeg een GitOps-aanpak waarbij de pipeline alleen een Git-repository bijwerkt en een aparte operator naar productie deployt. Dit elimineert de noodzaak voor het CI-systeem om directe productietoegang te hebben.
- Monitor deployments — implementeer geautomatiseerde rollbacks getriggerd door health check-failures en anomaliedetectie in je monitoringstack.
Hoe ICTLAB kan helpen
ICTLAB biedt CI/CD-pipeline beveiligingsbeoordelingen en hardeningdiensten voor Belgische organisaties. Wij beoordelen je bestaande pipelines op kwetsbaarheden, implementeren beveiligingscontroles over het build- en deploymentproces, en integreren beveiligingsscanning in je workflows — allemaal als onderdeel van een uitgebreide DevSecOps-aanpak.