GitHub-repo's lekken ruim 543.000 nog geldige inloggegevens

Openbare GitHub-repository's bevatten nog altijd honderdduizenden werkende geheimen, ook al heeft het platform tools toegevoegd die onbedoelde lekken moeten voorkomen. Uit een nieuwe analyse van Truffle Security blijkt dat 543.699 unieke inloggegevens in juli nog geldig waren.

De onderzoekers doorzochten 224 miljoen repository's en ruim 58 miljard bestanden. Een gelekt wachtwoord of gelekte sleutel bleef mediaan 784 dagen openbaar toegankelijk voordat iemand het opmerkte of ingreep.

Opvallend is hoe oud sommige van die geheimen zijn. Zo'n 10% van de werkende inloggegevens was ouder dan 6,3 jaar, en de oudste geldige dateert uit 2009. De 543.699 unieke geheimen doken steeds opnieuw op in meer dan 1,1 miljoen bestanden en repository's, inclusief kopieen in forks.

Waar de gegevens vandaan komen

Truffle Security heeft GitHub voor dit onderzoek niet zelf doorzocht. Het bedrijf gebruikte een dataset die is samengesteld om grote taalmodellen te trainen, gebaseerd op een crawl die eindigde op 7 augustus 2025.

Het aantal op GitHub is ruim het dubbele van wat hetzelfde team in augustus vond bij een scan van Hugging Face. Daar ging het om 221.303 werkende inloggegevens.

Het onderzoek wijst ook op een gestage stijging van het aantal geheimen dat in code opduikt. Het aantal werkende inloggegevens groeide van 3,72 per miljoen bestanden in 2015 naar een piek van 11,62 per miljoen bestanden in 2025.

Push Protection helpt, maar niet onbeperkt

De belangrijkste beveiliging die GitHub tegen dit probleem inzet, is Push Protection. Die functie kwam in april 2022 voor het eerst beschikbaar voor klanten van Advanced Security, werd in mei 2023 uitgebreid naar openbare repository's en ging later standaard aan.

De functie controleert binnenkomende code op patronen van geheimen, zoals API-sleutels en toegangstokens, en blokkeert de push als er een match is. Inloggegevens die al waren uitgelekt voordat de functie ingreep, worden echter niet ingetrokken.

Volgens Truffle Security werden 199.843 van de actieve inloggegevens, ongeveer 36,8% van het totaal, blootgesteld nadat GitHub Push Protection in februari 2024 voor alle gebruikers had ingeschakeld.

Iets meer dan de helft (51,8%) van de werkende geheimen viel in categorieen die de standaardinstelling van Push Protection niet blokkeert. Daaronder vallen verbindingsstrings voor databases en Google API-sleutels.

Binnen de categorieen die wel worden gedekt, lijkt de functie te werken. Het aandeel gelekte inloggegevens in beschermde categorieen daalde met 53% nadat GitHub de functie standaard had ingeschakeld.

De ene dienst ruimt sneller op dan de andere

Of een gelekt geheim nog werkt, hangt sterk af van de dienst erachter. Van de 101.886 npm-tokens die in openbare repository's waren gecommit, vonden de onderzoekers er maar een die nog actief was.

Bij inloggegevens van serviceaccounts in Google Cloud lag dat heel anders. Van de 126.963 gelekte sleutels waren er 69.041 nog geldig toen Truffle Security ze controleerde.

Wie getroffen is, krijgt het advies gelekte inloggegevens meteen te vervangen, de repository's op te schonen, de volledige commitgeschiedenis te scannen en voor alle actieve geheimen een automatische vervaldatum in te stellen.

Het onderzoek laat zien hoeveel werkende geheimen er in openbare code staan. Het laat niet zien hoeveel daarvan daadwerkelijk door aanvallers zijn gevonden en misbruikt.

Waarom dit ertoe doet

Voor ontwikkelaars en securityteams is de belangrijkste les dat het blokkeren van nieuwe lekken niet hetzelfde is als het dichten van oude. Push Protection lijkt het aantal lekken te verminderen in de categorieen die het dekt, maar honderdduizenden oudere en niet-gedekte geheimen zijn nog altijd bruikbaar. Dat wijst erop dat het doorzoeken van de geschiedenis en het intrekken van sleutels nog grotendeels op het bordje van repository-eigenaren ligt.

Het verschil tussen npm-tokens en inloggegevens voor Google Cloud zegt ook veel. Het geeft aan dat detectie en automatische intrekking door de aanbieder een groot verschil kunnen maken, en dat diensten zonder zulke mechanismen de last bij de gebruikers leggen.

De bevindingen passen in een breder patroon van gevoelige gegevens die in openbare code terechtkomen, van AI-agents die screenshots naar GitHub lekken tot uitgelekte e-mailadressen van GitLab waarmee code werd gepusht. Het is de moeite waard om te volgen of GitHub Push Protection uitbreidt naar verbindingsstrings voor databases en Google API-sleutels, en of meer cloudaanbieders gelekte inloggegevens automatisch gaan intrekken.