Een grote dataset laat zien dat actieve credentials op GitHub nog steeds een reëel probleem zijn. Een onderzoek van Truffle Security beschrijft hoe in openbare repositories honderdduizenden unieke geheimen zijn teruggevonden die op het moment van testen nog functioneerden. Het gaat niet om theoretische risico’s, maar om sleutels en tokens die toegang bleven geven.
Dat maakt de les extra belangrijk: beveiligingsmaatregelen die lekkage moeten voorkomen, pakken niet automatisch wat al eerder is doorgelaten. In dit artikel zet ik de belangrijkste bevindingen op een rij en vertaal ik ze naar praktische acties voor organisaties die code hosten of beheren.
Wat vond Truffle Security precies?
Truffle Security rapporteert dat het in augustus 2025 openbare GitHub-repositories heeft gescand. Daarbij kwam het tot 1.103.438 blootgestelde credentials verspreid over 224 miljoen onderzochte repositories. Het gaat daarbij om unieke credentials die herkenbaar waren in de publieke code.
Vervolgens is het onderzoek in de tijd doorgetrokken. Eind juli 2026 testte Truffle de gevonden credentials op de bijbehorende diensten. Daaruit bleek dat 543.699 credentials nog actief waren op het moment van controleren. Met andere woorden: een fors deel werkte nog steeds en gaf toegang, ondanks eerdere blootstelling.
De oudste credential in de set zou al in 2009 zijn gecommit en daarna niet meer zijn aangepast. De median exposure window—de typische periode tussen eerste blootstelling en het moment van de meting—bedroeg 784 dagen. Daarmee is duidelijk dat dit vaak geen incident van een week is, maar een langdurig risico.
Leeftijd en herkomst: waarom oude sleutels blijven doorwerken
Een opvallend detail is dat een deel van de blootgestelde secrets afkomstig is uit bestanden die al jaren geleden zijn gewijzigd. Truffle stelt dat 2.636 live credentials afkomstig zijn uit bestanden die voor 2015 zijn aangepast. Daarnaast zou ongeveer een kwart van alles wat ze vonden ouder dan vier jaar zijn.
Dat patroon is logisch vanuit organisatiegedrag: credentials worden in code gezet voor gemak, later vergeten of vervangen door “nieuwe” sleutels, terwijl oudere varianten in geschiedenis of forks blijven rondzwerven. Ook wanneer een team een sleutel vernieuwt, kan een oude key nog steeds bestaan in andere branches, tags of dependents.
De kern is dus niet alleen de “lekkage”, maar de levensduur van de credential na blootstelling.
Push protection en alerts: nuttig, maar niet genoeg
Truffle benadrukt een belangrijk misverstand: actieve credentials op GitHub blijven bestaan doordat bestaande controles niet automatisch alle risico’s afdekken. Push protection—een functie die moet voorkomen dat secrets tijdens het pushen per ongeluk in de repository terechtkomen—helpt bij incidenten “aan de deur”.
Maar wat al in het verleden is gepusht, wordt niet automatisch teruggedraaid. Bovendien wijst Truffle op de context rond het moment waarop GitHub gratis alerts en standaard push protections inschakelde. Een groot deel van de actieve secrets is volgens het rapport in de periode vóór of net langs de grenzen van deze instelling toegevoegd.
- 245.959 credentials zouden al bestaan vóórdat free alerts beschikbaar waren.
- 97.897 credentials zouden zijn binnengekomen in een fase waarin alerts niet altijd actief waren, of push protection net “één setting” verwijderd was.
- 199.843 credentials zouden na het blokkeren als default alsnog terecht zijn gekomen, en waren zelfs meer dan twee jaar later nog actief.
Het punt: maatregelen die je verkeer “tegenhouden” vertellen niets over wat al “in het gebouw” stond.
Secret scanning werkt voor detectie, maar niet gegarandeerd voor rotatie
GitHub heeft daarnaast secret-scanning en stuurt tokens door naar de providers die de secrets uitgeven, met als doel revocatie. Maar Truffle stelt dat het programma niet verplicht stelt dat partners de geïdentificeerde secrets ook daadwerkelijk intrekken. Daardoor kunnen tokens actief blijven als de provider geen pipeline heeft om ze automatisch te invalidateren.
Met andere woorden: detection is één stap, maar verwijdering en rotatie moet vervolgens op een consistente manier worden uitgevoerd door de eigenaar—en soms ook door de provider.
Welke soorten secrets kwamen het meest voor?
De top van wat werd gevonden laat vooral het belang zien van cloud-identity en database-toegang. Volgens Truffle domineerden de set met blootgestelde credentials:
- 69.041 Google Cloud service account credentials
- 51.067 MongoDB connection strings
- 33.343 live Google API keys
Dit zijn typen geheimen die vaak direct bruikbaar zijn: ze kunnen identiteiten activeren, databaseverbindingen mogelijk maken en API’s aanroepen. Dat verklaart ook waarom Truffle ze “active” kon vaststellen.
Wat betekent dit voor jouw organisatie?
De bevindingen zijn een stevige waarschuwing: zelfs als je technisch gezien “best practices” gebruikt, kan er nog steeds code of history bestaan waarin tokens leven. Daarom is de aanpak het meest effectief als je detectie en incident response als één doorlopende keten ziet.
1) Herken niet alleen “lekkage”, maar ook “activiteit”
Bekijk niet enkel of secrets zijn gedetecteerd, maar of ze nog bruikbaar zijn. Een secret scanning-melding zonder rotatie kan leiden tot schijnveiligheid. Plan daarom testen op geldigheid en zet dat onderdeel in je reguliere workflow.
2) Reduceer de tijd tussen vinden en intrekken
Truffle’s data toont dat sommige sleutels lang actief bleven. Maak daarom rotatie onderdeel van je standaard responsproces: zodra een token is geïdentificeerd, moet een eigenaar een strak pad doorlopen richting vervanging, intrekking en controle.
3) Controleer geschiedenis, niet alleen de huidige code
Ook als een repository tegenwoordig “schoon” lijkt, kan de commitgeschiedenis nog secrets bevatten. Besteed extra aandacht aan oude branches, tags, forks en voorbeeldcode die ooit in publicatie is terechtgekomen.
4) Leg verantwoordelijkheden bij een eigenaar met toegang tot rotatie
Het onderzoek suggereert dat secrets actief bleven omdat revocatie niet altijd werd doorgevoerd via een pipeline. Zorg er daarom voor dat er intern een partij is die daadwerkelijk de sleutelomgeving beheert en kan roteren—met duidelijke bevoegdheden en een vast ritme.
Praktische vervolgstap: verbeter je secret-hygiëne
Als je secret scanning vooral gebruikt om “meldingen te krijgen”, is het tijd om die meldingen te koppelen aan concrete technische acties. Denk aan het periodiek vernieuwen van omgevingssleutels, het afschalen van privileges en het beperken van wat tokens mogen doen (least privilege).
Ook is het verstandig om gerelateerde beveiligingsonderdelen te betrekken. Zo laten eerdere cases zien dat incidenten vaak niet losstaan van bredere aanvalspatronen rond toegang en tokens. Een voorbeeld is hoe organisaties te maken kunnen krijgen met beveiligingsproblemen en patches in verschillende productecosystemen; zie bijvoorbeeld analyses over kwetsbaarheden en patches binnen netwerk- en security-omgevingen, zoals Cisco Catalyst SD-WAN zero-day: patch CVE-2026-76504.
Daarnaast past de bredere gedachte—dat “detectie” niet automatisch “remediatie” is—goed bij hoe security teams hun processen moeten inrichten. Daarmee wordt het gemakkelijker om herhaling te voorkomen.
Waarom deze case ook relevant is in 2026
De studie eindigt niet bij detectie. Door de tijd te overbruggen tot eind juli 2026 en daar live-activiteit te meten, werd zichtbaar dat actieve credentials op GitHub niet vanzelf verdwijnen. Zelfs met verbeterde platformcontroles kan er nog steeds een gat zitten tussen identificatie, revocatie en rotatie.
Voor teams die software leveren is dit een extra argument om security in de hele keten te behandelen: van developer workflows tot CI/CD en van repositorybeheer tot cloud identity management.
Conclusie: controleer, roteer en sluit het gat
Truffle Security’s onderzoek toont een harde realiteit: in een grote set blootgestelde secrets waren 543.699 credentials nog actief. Dat betekent dat code en repositoryhistorie directe toegangsimpact kunnen hebben, zelfs wanneer platformfuncties zoals push protection en secret alerts bestaan.
De beste vervolgstap is daarom niet alleen “meer detectie”, maar vooral: snelle rotatie, verplichte intrekking van gevonden credentials en een aanpak die ook oudere commits en geschiedenis meeneemt. Alleen zo voorkom je dat gelekte sleutels blijven werken—en dat risico zich in de tijd herhaalt.
Bron: https://www.securityweek.com/500000-active-credentials-left-exposed-on-github/
