Broncode van CrowdSec is in mei uit privé-repositories gestolen, meldt het cybersecuritybedrijf; de blootstelling bleef volgens CrowdSec beperkt tot eigen code en raakte geen klantdata.
Voor een Nederlandse organisatie die CrowdSec gebruikt, ligt de inzet daarom niet in een bewezen klantdatalek, maar in de controle van de softwareketen. Welke repositories, tokens en CI/CD-koppelingen liepen via deze leverancier, en zijn gedeelde credentials opnieuw uitgegeven?
Wat er is blootgesteld
CrowdSec maakt onderscheid tussen een publieke en een private codebasis. De publieke Security Engine is openbaar ontworpen en valt buiten de melding. De private repositories bevatten de broncode van de SaaS-console, AWS-cloudroutines, connectors en automatiseringen.
De claim van ongeveer 300 repositories klopt volgens CrowdSec als ook de ruim 130 publieke repositories worden meegeteld. Het aantal zegt daardoor vooral iets over de onderverdeling van de code, niet over 300 afzonderlijke geheime systemen. CrowdSec zegt dat geen klantdata, login- of wachtwoordgegevens, namen of organisatiedata zijn gelekt. Het bedrijf zegt ook geen persoonsgegevens of klantlogs op te slaan.

Hoe de toegang ontstond
Het lek zelf vond in mei plaats. CrowdSec zegt op 16 september over de blootstelling te zijn geïnformeerd; de officiële verklaring is gedateerd op 17 september. Security.NL meldt dat CrowdSec op 16 september over het lek werd geïnformeerd, dat in mei had plaatsgevonden en dat de broncode in de maanden daarna verder is ontwikkeld.
CrowdSec noemt de TanStack-compromise als waarschijnlijke route. Een component die in mei binnen de organisatie werd gebruikt, lijkt te zijn voorzien van een achterdeur om een API-sleutel te stelen met leesrechten op de private codebase. De aanval omvatte 84 malafide versies in 42 npm-pakketten, blijkt uit de TanStack-postmortem. CrowdSec zegt dat het kwetsbare venster kort was en dat alle noodzakelijke tokens en credentials daarna direct zijn geroteerd.
Wat klanten controleren
Voor klanten en partners staan vier controles centraal:
- Sleutelrotatie: roteer eigen tokens als ze in de betrokken workflow, buildomgeving of een gedeelde CI/CD-context konden komen. CrowdSec meldt geen gestolen klantdata of logingegevens, dus leg vast welke eigen sleutels wel en niet binnen bereik waren.
- Repository-audit: controleer GitHub-toegang, clone- en checkout-activiteiten en CI/CD-runs rond mei. Kijk ook naar onverwachte wijzigingen in workflows, connectors en automatiseringen.
- Credentialbeheer: gebruik per omgeving en integratie beperkte sleutels, bewaar secrets centraal en trek oude credentials echt in. Een gedeelde sleutel maakt een leveranciersincident groter dan nodig.
- Leverancierskoppelingen: vraag welke repositories, componenten en toegangsrechten onder het onderzoek vielen. Leg vast welke meldingen, indicatoren en herstelacties je van de leverancier hebt ontvangen.
Die controle sluit aan op API-sleutels inventariseren, centraliseren in een secrets manager en automatisch roteren.
CrowdSecs verklaring begrenst de directe schade tot de eigen codeomgeving, voor zover nu bekend. De bredere verschuiving zit in de toegangsketen: broncode, CI/CD en credentials horen bij het leveranciersrisico, ook wanneer klantdata zelf buiten de blootstelling blijft.
Veelgestelde vragen
Grip op leveranciersrisico
Ik help je softwareketen, toegangen en credentials van begin tot eind in kaart te brengen, van meedenken en ontwerp tot realiseren en automatiseren. Waar het kan zet ik de oplossing self-hosted neer, zodat je weet welke toegang waar zit.
Dit artikel is geproduceerd samen met het Agent Team. Meer over de redactie.

