Artikel3 min lezenBijgewerkt
Ga uit van een inbraak: wat de GitHub-breach iedereen leert die software bouwt
Een vergiftigde editorextensie kostte GitHub duizenden interne repositories. Hoe we ons eigen werk zo inrichten dat een inbraak niets van waarde oplevert.
In mei 2026 maakte GitHub bekend dat een aanvaller zo’n 3.800 van zijn interne repositories had gekopieerd. De weg naar binnen was geen geavanceerde exploit tegen het platform van GitHub. Het was één laptop van één medewerker, en daarop een gemanipuleerde versie van een populaire extensie voor de Visual Studio Code-editor. De vergiftigde versie stond maar enkele minuten in de marketplace voordat ze werd verwijderd, en dat was genoeg. GitHub vond geen aanwijzingen dat repositories van klanten waren geraakt.
De les is er een die veel teams liever niet horen: wie software bouwt, is op een gegeven moment onderdeel van een inbraak. Niet uit onzorgvuldigheid, maar omdat moderne engineering draait op lagen van tools, extensies en afhankelijkheden die niemand volledig in de hand heeft.
Ga uit van een inbraak, beperk de impact
Preventie blijft belangrijk, en we investeren erin. Maar een ontwerp dat alleen werkt zolang er niets binnenkomt, is een ontwerp dat faalt op de slechtste dag. Wij vertrekken vanuit het omgekeerde uitgangspunt: er komt iemand binnen, zorg dus dat die vertrekt zonder iets van strategische waarde. In de praktijk komt dat neer op vier gewoontes.
- Kernlogica achter interfaces. Eigen regels en algoritmen staan niet als leesbare broncode in een repository. Ze leven achter services, interfaces of private modules, zodat een gekopieerde repository laat zien hoe dingen samenhangen, niet hoe ze werken.
- Niets gevoeligs in code. Geen geheimen, geen interne endpoints, geen configuratie die de infrastructuur in kaart brengt. Geheimen leven in een kluis en worden tijdens de uitvoering opgehaald door een identiteit, nooit in een bestand geplakt.
- Bewuste abstractie. Code wordt geschreven om helder te zijn voor de mensen die eraan werken en zo min mogelijk prijs te geven aan wie hem niet hoort te lezen.
- Standaard publiek. Elke repository wordt geschreven alsof hij morgen openbaar kan worden. Als een bestand een probleem zou zijn op de voorpagina van een nieuwssite, hoort het niet in de repository.
De werkplek is de perimeter
De GitHub-zaak laat ook zien waar de echte perimeter tegenwoordig zit: op de machine van de ontwikkelaar. De editor, zijn extensies en de command-line-tools op die machine draaien allemaal met de toegang van de ontwikkelaar. Dat vraagt om dezelfde discipline als elk ander deel van de omgeving: een korte lijst met goedgekeurde extensies, devices die beheerd en actueel worden gehouden, aanmeldingen gebonden aan een beheerd device, en toegang die is afgebakend op de taak in plaats van op alles wat een ontwikkelaar ooit nodig zou kunnen hebben.
Weerbaarheid, geen paranoia
Security gaat niet alleen over aanvallers buiten houden. Het gaat erom dat, als er iets gebeurt, de schade klein, beheersbaar en snel teruggedraaid is. De GitHub-breach zal niet de laatste krantenkop in zijn soort zijn. Hoeveel het jou kost, wordt bepaald per ontwerpkeuze, lang vóór het incident.
We beheren onze eigen repositories op deze manier, en we helpen teams dezelfde gewoontes aan te nemen: geheimen in een kluis, beheerde ontwikkelaarsdevices, een korte lijst met goedgekeurde editorextensies en een review op elke wijziging.
Bekijk wat we bieden in cybersecurity en compliance en teamtraining en enablement.