In publieke code-repositories worden geregeld sleutels vergeten. Maar dit keer gaat het niet alleen om “mogelijk blootgestelde” credentials: een onderzoeker testte ze en vond 26.400 werkende cloud- en AI-credentials in publieke Gitee-repositories. Dat betekent dat iemand die een key uit die code kopieerde, er in veel gevallen direct mee aan de slag kon gaan.
De bevindingen zijn afkomstig van Ben Zimmermann, die tijdens een scan miljoenen publieke Gitee-projecten doorzocht. Vervolgens probeerde hij de gevonden credentials tegen de bijbehorende diensten om te zien welke echt nog functioneerden.
Wat werd er gevonden in Gitee-repositories?
Zimmermann doorzocht 7,25 miljoen publieke Gitee-repositories. Op basis van automatische secret-scanners kwamen er 26.400 unieke credentials naar voren die (volgens de test) nog werkten wanneer ze werden gebruikt.
Een belangrijk punt: de onderzoekers stuurden wel rapportages naar de providers met de meest blootgestelde sleutels, maar Zimmermann nam niet contact op met de developers die de secrets hadden gelekt. Daardoor is het risico niet “weg” totdat een key daadwerkelijk bij de provider is ingetrokken.
Grote groepen: van Alibaba Cloud tot AI-platforms
De grootste aantallen waren onder meer:
- 9.473 Alibaba Cloud AccessKey-pairs
- 3.805 YouTube API keys
- 3.170 DeepSeek keys
- 1.489 Zhipu BigModel AI-platform keys
- 1.348 OpenAI keys
Daarnaast werden er kleinere aantallen gevonden voor o.a. GitHub, AWS, Google Cloud en Gemini. Ook zat er volgens het onderzoek ten minste één credential tussen die als een actieve organisatie-admin voor een groot enterprise AI-platform kon dienen. Welke dienst dit precies was, werd niet gespecificeerd.
Waarom “verwijderd uit code” geen garantie is
Een veelgemaakte aanname is dat het verwijderen van een sleutel uit de code voldoende is. De scan werkte echter met de volledige commitgeschiedenis van repositories. Daardoor kan een key die ooit in de code stond, nog steeds teruggevonden en getest worden—ook als hij later is weggehaald.
Dit maakt de impact van credential leakage anders dan bij een eenmalige fout: zolang een sleutel ooit openbaar stond en nog niet is ingetrokken bij de provider, kan deze opnieuw worden misbruikt.
Wat kunnen aanvallers met werkende credentials?
Welke schade mogelijk is, hangt af van het type key en het platform. In de bronbevindingen wordt onder meer het volgende genoemd:
- OpenAI: als een key gecompromitteerd is, kan een ander de quota van het account gebruiken zonder toestemming van de eigenaar. Dat kan leiden tot dataverlies, onverwachte kosten, een opgebruikte maandquota en onderbroken API-toegang.
- YouTube API keys: volgens Google identificeren deze keys een project. Zonder extra API-restricties kan een key mogelijk worden gebruikt voor meerdere API’s die Google Cloud keys accepteren.
Met andere woorden: “sleutel gevonden” is vaak al genoeg voor misbruik; “restricties aanwezig” bepaalt in hoeverre het beperkt blijft.
Hoe de onderzoekers testten: niet alleen detectie
Zimmermann gebruikte twee secret-scanners: TruffleHog en Kingfisher. Beide probeerden de gevonden credentials tegen de bijbehorende service, en hielden alleen die keys over die daadwerkelijk werken.
Een nuance is dat scanners niet altijd hetzelfde detecteren. In deze meting vond TruffleHog 12.737 werkende credentials, terwijl Kingfisher er 14.664 vond. Van beide samen kwamen er slechts 1.001 in de overlap terecht. Elk instrument ontdekte dus ongeveer de helft van het totaal op basis van eigen detectiemechanismen.
Als je binnen je organisatie maar één tool gebruikt om secrets te vinden, is het verstandig om te controleren of die tool ook echt de services dekt die jullie gebruiken.
Wat betekent dit voor jou? Actieplan voor sleutelbeheer
De belangrijkste les is simpel: behandel elke sleutel die ooit in publieke Gitee-code heeft gestaan als blootgesteld. Zelfs als je denkt dat je hem verwijderd hebt. De enige echte remedie is revoken/rotaten bij de provider.
Concreet volgen hieronder de aanbevolen stappen die in de bronbevindingen zijn beschreven voor meerdere diensten.
Alibaba Cloud: roteren, migreren, oude pair uitschakelen
- Maak een nieuw AccessKey-pair.
- Schakel je applicaties om naar de nieuwe key.
- Schakel daarna de oude key uit en delete/revoke de oude pair.
- Controleer op onverwachte charges en op resources die je niet herkent.
Voor zicht op API-activiteit wordt genoemd dat ActionTrail API-oproepen kan tonen over de laatste 90 dagen. Voor dataservices zoals OSS en SLS moet je daarnaast in de eigen service-logs kijken.
Google en YouTube: roteren en API-restricties toevoegen
- Rotereer de key (dit creëert een nieuwe key met dezelfde restricties).
- Update je apps zodat ze direct de nieuwe key gebruiken.
- Verwijder/deactiveer de oude key.
- Voeg API restrictions toe zodat de key alleen werkt voor de API’s die je nodig hebt.
OpenAI: roteer direct en beperk besteding
- Rotereer de key meteen vanuit de API Keys-pagina.
- Stel spend limits in om schade door misbruik te beperken.
Waarom commitgeschiedenis en “scrubben” niet genoeg zijn
Ook al herschrijf je een repositorygeschiedenis of verwijder je de sleutel uit de code: dat is niet automatisch hetzelfde als revoken bij de provider. De bron geeft expliciet aan dat “de key uit het codeverloop halen” het echte beveiligingsprobleem niet oplost, omdat de sleutel nog in historische commits kan worden teruggevonden.
Daarom is “code opschonen” hooguit de stap om herhaling te voorkomen. Voor echte risicoreductie moet je de credential intrekken bij de dienst zelf.
Vergeet niet: niet elke scanner dekt alles
In de resultaten zie je dat bepaalde platforms opvallend vaak door één scanner wel en de andere niet werden gevonden. Zo werden de Zhipu BigModel keys door Kingfisher volledig gevonden, terwijl TruffleHog daar volgens de onderzoeker geen detector voor had.
Dit is een praktische waarschuwing: als je afhankelijk bent van één scanner, kun je een vals gevoel van veiligheid krijgen. Stem je secret-detectie af op de diensten die jullie daadwerkelijk gebruiken.
Wil je bredere context over het voorkomen en blokkeren van secrets vóór ze worden geïnstalleerd of uitgerold? Lees dan ook eens hoe je npm-firewalls gebruikt om misbruik vóór installatie te blokkeren.
Conclusie: neem werkende credentials serieus
De kern van het verhaal is dat het niet bij theoretische exposure bleef: de gevonden werkende cloud- en AI-credentials werden getest en bleken in veel gevallen nog bruikbaar. Dat maakt dit geen “paper issue”, maar een direct beveiligingsrisico.
Als je ooit keys in publieke repositories hebt gezet—ook als je ze later verwijderde—start dan met het rotaten en revoken bij de provider, en controleer tegelijkertijd of je API-restricties en bestedingslimieten op orde zijn. Zo beperk je de kans op datalekken, onverwachte kosten en onderbroken API-toegang.
Met een combinatie van secret scanning, snelle key rotation en strakke toegang/restricties kun je dit type incident effectiever afremmen, nog voordat een key misbruikbaar wordt.
Bron: https://thehackernews.com/2026/10/26400-valid-cloud-and-ai-credentials.html
