De softwaretoeleveringsketen begint niet bij de productieserver, maar bij het platform waarop code wordt geschreven, getest en uitgerold. Voor de meeste Europese organisaties is dat GitHub, eigendom van Microsoft en daarmee onderworpen aan de Amerikaanse Clarifying Lawful Overseas Use of Data Act (CLOUD Act). Wie broncode, CI/CD-pipelines en geheimen op GitHub beheert, plaatst een cruciaal deel van zijn digitale toeleveringsketen buiten de Europese rechtssfeer, met meetbare compliance- en veiligheidsconsequenties.
Wat de CLOUD Act concreet betekent voor GitHub-gebruikers
De CLOUD Act verplicht Amerikaanse technologiebedrijven op last van een rechtbank of een zogenoemde executive agreement data te verstrekken aan Amerikaanse autoriteiten, ongeacht de fysieke locatie van de servers. GitHub-servers in de Europese Unie veranderen hier niets aan: de verplichting rust op Microsoft als Amerikaans rechtspersoon, niet op de infrastructuur.
Dat heeft directe gevolgen voor wat er op GitHub staat. Privérepositories, CI/CD-omgevingsvariabelen, deploymentsleutels en pijplijnlogs zijn juridisch gezien bereikbaar voor de Amerikaanse overheid via een geldig verzoek. Het gaat daarbij niet alleen om persoonsgegevens in de zin van de AVG, maar ook om bedrijfsgevoelige broncode, cryptografische sleutels en architectuurdocumentatie.
“De CLOUD Act geeft Amerikaanse autoriteiten de bevoegdheid om data op te vragen bij Amerikaanse bedrijven, ongeacht waar die data fysiek is opgeslagen. Voor Europese organisaties die GitHub gebruiken, betekent dit dat hun broncode juridisch gezien bereikbaar is voor de Amerikaanse overheid.”
European Data Protection Board (EDPB), Guidelines on Third Country Transfers
GitHub ontving in de eerste helft van 2023 wereldwijd meer dan 5.000 overheidsverzoeken voor gebruikersdata, waarvan het overgrote deel afkomstig was van Amerikaanse instanties (bron: GitHub Transparency Report 2023). Dat zijn geen hypothetische risico’s, maar gedocumenteerde verzoeken die bij een Europese organisatie in de praktijk ook broncode of CI/CD-configuraties kunnen treffen.
Pakketmanagers als onderschatte jurisdictiefactor
De afhankelijkheid van niet-EU-infrastructuur strekt zich verder uit dan de code-hostinglaag. De drie dominante pakketregisters voor webontwikkeling, datascience en Java-ontwikkeling worden alle beheerd door Amerikaanse entiteiten.
| Pakketmanager | Register | Beherende organisatie | Jurisdictie |
|---|---|---|---|
| npm | registry.npmjs.org | GitHub / Microsoft | VS (CLOUD Act) |
| pip / PyPI | pypi.org | Python Software Foundation | VS |
| Maven | Maven Central | Sonatype | VS |
| Cargo | crates.io | Rust Foundation | VS |
Het risico bij pakketregisters zit op twee niveaus. Ten eerste de jurisdictie van de registerinfrastructuur zelf, inclusief de ondertekenings- en publicatierechten. Ten tweede de inhoud van de pakketten: kwaadaardige of gecompromitteerde pakketten worden via deze registers gedistribueerd naar Europese bouwomgevingen. Geautomatiseerde updatetools zoals Dependabot (geïntegreerd in GitHub) of Renovate trekken automatisch nieuwe versies op, waardoor een gecompromitteerd pakket zonder menselijke tussenkomst in de productieketen terechtkomt.
Volgens het ENISA Threat Landscape 2023 had 17% van alle cyberincidenten in 2023 een supply chain-component, wat de software-toeleveringsketen tot een van de snelst groeiende aanvalsvectoren maakt (bron: ENISA, 2023). Organisaties die pakketregisters zonder verificatie consumeren, vergroten dit aanvalsoppervlak structureel.
Beheersmaatregelen voor pakketafhankelijkheden
Een soevereine aanpak vereist interne spiegels of proxycaches van pakketregisters, waarbij inkomende pakketten worden gescand en vastgezet op een specifieke versie en hash. Tools als Nexus Repository Manager of Artifactory (beide beschikbaar als zelf-te-hosten installatie) bieden deze functionaliteit. Cryptografische verificatie via SBOM-doorsnijding, waarbij elke afhankelijkheid wordt gecontroleerd aan de hand van een vastgestelde Software Bill of Materials, voorkomt dat ongeplande updates doorkomen.
NIS-2 artikel 21 en de CRA als juridisch kader
NIS-2 artikel 21 en de Cyber Resilience Act (CRA) geven compliance officers concrete handvatten om externe ontwikkelplatforms formeel te beoordelen als onderdeel van de ICT-toeleveringsketen.
“Organisaties moeten hun ICT-toeleveringsketen behandelen als een integraal onderdeel van hun risicobeheer, inclusief de platforms waarop zij hun eigen software ontwikkelen en distribueren.”
ENISA, Guidelines on ICT Supply Chain Security
NIS-2 artikel 21, lid 2, sub d verplicht entiteiten maatregelen te nemen voor de beveiliging van de toeleveringsketen, met expliciete aandacht voor de relaties met directe leveranciers en dienstverleners. Een code-hostingplatform als GitHub valt hier rechtstreeks onder: het is een directe leverancier van CI/CD-diensten aan de ontwikkelende organisatie. Artikel 21 vereist dat organisaties de risico’s van dergelijke leveranciers documenteren, beoordelen en beheersen.
De CRA, die in 2024 in het Publicatieblad van de EU verscheen als Verordening (EU) 2024/2847, introduceert SBOM-vereisten voor fabrikanten van producten met digitale elementen. Een SBOM moet alle directe en transitieve afhankelijkheden documenteren met versienummers, licenties en bekende kwetsbaarheden. Wie zijn bouwpipeline op GitHub draait en afhankelijkheden uit npm of PyPI trekt zonder gecontroleerde interne spiegel, kan bij een CRA-audit moeilijk aantonen dat de SBOM volledig en betrouwbaar is, omdat de herkomst en integriteit van pakketversies niet autonoom zijn geborgd.
Het Centrum voor Cybersecurity België (CCB) stelde in 2023 vast dat meer dan 60% van de kritieke Belgische organisaties afhankelijk zijn van software van derde partijen zonder formeel SBOM-beheer (bron: CCB, jaarrapport 2023). Dit illustreert hoe breed de kloof is tussen de wettelijke vereisten en de huidige praktijk.
Europese alternatieven voor GitHub en CI/CD
Er zijn volwassen alternatieven beschikbaar die buiten de Amerikaanse jurisdictie kunnen worden gehost, elk met een ander profiel wat betreft functionaliteit, beheerslast en ecosysteem.
| Platform | Herkomst | Licentie | CI/CD ingebouwd | Geschikt voor |
|---|---|---|---|---|
| GitLab CE | VS (zelf te hosten) | MIT (CE) | Ja, GitLab CI | Grote organisaties, volledige DevSecOps |
| Gitea | Community (zelf te hosten) | MIT | Beperkt (Actions) | Kleine teams, lichte installatie |
| Forgejo | Community-fork van Gitea | MIT | Ja (Actions-compatibel) | Soeverein beheer, open governance |
| Codeberg.org | Duitsland (Forgejo-gebaseerd) | Non-profit service | Via Forgejo Actions | Open source projecten, EU-jurisdictie |
GitLab biedt de meest uitgebreide CI/CD-functionaliteit, inclusief ingebouwde SAST, DAST, dependency scanning en SBOM-export. De Community Edition is vrij te gebruiken en kan on-premise worden geïnstalleerd, volledig buiten Amerikaanse infrastructuur. De migratiedrempel van GitHub naar GitLab is reëel: GitHub Actions-workflows zijn niet één-op-één overdraagbaar naar GitLab CI, en repositories met complexe branch-protection-regels of integraties met GitHub Apps vereisen handmatige herconfiguratie.
Forgejo, de community-fork van Gitea met een volledig open governance-model, wint terrein als alternatief voor organisaties die GitHub Actions-compatibiliteit willen behouden zonder de overstap naar GitLab. Forgejo Actions is grotendeels compatibel met GitHub Actions-syntaxis, wat de migratiedrempel verlaagt. Codeberg.org, een in Duitsland geregistreerde non-profit die Forgejo gebruikt, biedt gehoste opslag onder Europese rechtsregels.
De EU Open Source Strategy 2026 en structurele aanpak
De Europese Commissie werkt aan de opvolger van de EU Open Source Strategy 2020-2023, gericht op de periode tot 2026. De strategie erkent expliciet dat strategische afhankelijkheid van niet-EU-ontwikkelinfrastructuur een risico vormt voor de digitale soevereiniteit van Europa. Verwachte maatregelen omvatten verplichte open source-publicatie van door EU-instellingen gefinancierde software, uitbreiding van de OSPO (Open Source Programme Office)-structuur binnen EU-instellingen, en financieringsstromen naar kritieke open source-projecten die momenteel door niet-EU-entiteiten worden beheerd.
De strategie sluit aan bij de bredere Europese Chips Act en de NIS-2-richtlijn door de ontwikkelketen te zien als een onderdeel van digitale infrastructuur. Concreet betekent dit dat organisaties die op EU-aanbestedingen reageren in de nabije toekomst vaker zullen worden beoordeeld op de soevereiniteit van hun eigen ontwikkelinfrastructuur, niet alleen die van hun eindproduct.
Praktische aanpak voor compliance officers en IT-beslissers
De beoordeling van GitHub als leverancier begint met een gestructureerde inventarisatie: welke repositories bevatten gevoelige bedrijfslogica of persoonsgerelateerde testdata, welke CI/CD-pipelines verwerken productiegeheimen, en welke integraties leggen data buiten de eigen omgeving. Pas daarna kan een risicogewogen migratieplanning worden gemaakt.
Een gefaseerde aanpak werkt het best: eerst interne spiegels van pakketregisters opzetten en SBOM-generatie in de bestaande GitHub-pipeline inbouwen (dit kan al met open tools als Syft of Trivy), daarna een pilotmigratie van minder kritieke repositories naar een zelf-gehoste GitLab- of Forgejo-instantie, en ten slotte de kritieke repositories overzetten nadat de nieuwe omgeving is gevalideerd. Door de CI/CD-logica vroegtijdig te abstraheren (gebruik van containergebaseerde runners die platform-agnostisch zijn), wordt de afhankelijkheid van platformspecifieke functionaliteit structureel verminderd.
Veelgestelde vragen
Valt GitHub onder de CLOUD Act en wat betekent dat voor mijn broncode?
Ja. GitHub is eigendom van Microsoft, een Amerikaans bedrijf, en valt daarmee volledig onder de CLOUD Act. Amerikaanse autoriteiten kunnen bij een geldig verzoek toegang eisen tot alle data die GitHub beheert, inclusief privérepositories, CI/CD-variabelen en geheimen, ongeacht of de servers fysiek in Europa staan.
Zijn npm, pip en Maven ook een jurisdictierisico?
Grotendeels wel. npm wordt beheerd door GitHub/Microsoft, PyPI door de Python Software Foundation (VS) en Maven Central door Sonatype (VS). De registraties zelf, de ondertekeningsinfrastructuur en het beheer van publicatierechten vallen daarmee onder Amerikaanse jurisdictie. Organisaties kunnen het risico beperken door interne spiegels of proxies te gebruiken en pakketten cryptografisch te verifiëren aan de hand van een vastgestelde SBOM.
Wat is het praktische verschil tussen GitLab, Gitea en Forgejo?
GitLab biedt een volledige DevSecOps-suite met uitgebreide CI/CD-functionaliteit en is beschikbaar als zelf-gehoste Community Edition. Gitea is een lichtgewicht, zelf-te-hosten Git-service die geschikt is voor kleinere teams met beperkte beheerscapaciteit. Forgejo is een community-fork van Gitea met een meer open governance-model, wordt gebruikt door Codeberg.org (een in Duitsland gevestigde non-profit) en biedt GitHub Actions-compatibele pijplijnsyntaxis, wat de migratiedrempel verlaagt.
Wat moet een SBOM bevatten op basis van de Cyber Resilience Act?
De CRA vereist dat fabrikanten van producten met digitale elementen een Software Bill of Materials bijhouden die alle directe en transitieve afhankelijkheden documenteert, inclusief versienummers, licenties en bekende kwetsbaarheden. Het formaat is niet dwingend voorgeschreven, maar SPDX en CycloneDX worden breed ondersteund en door toezichthouders erkend. De SBOM moet gedurende de volledige levensduur van het product actueel worden gehouden.
Welke concrete eerste stap kan een complianceofficier nemen om het GitHub-risico te beoordelen?
Begin met een inventarisatie van alle repositories, CI/CD-pipelines en geheimen die momenteel op GitHub staan. Beoordeel daarna per repository welke data juridisch gevoelig is, zoals broncode van kritieke systemen, API-sleutels of persoonsgegevens in testdatasets. Gebruik NIS-2 artikel 21 als formeel kader om de leveranciersrelatie met GitHub te documenteren en weeg de risico’s af tegen de migratie-inspanning naar een zelf-gehoste of Europees-gehoste alternatieve omgeving.
