A Truffle Security több mint félmillió olyan hitelesítő adatot talált nyilvános GitHub tárolókban, amelyek a kutatók tesztelésekor még mindig érvényesek voltak, és volt köztük olyan is, amely több mint 16 éve aktív maradt.

A biztonsági cég a The Stack v3-at vizsgálta át, egy nagy nyilvános kódbázist, amely 224 553 295 GitHub tárolót és több mint 58,4 milliárd fájlt tartalmaz. A feltérképezés minden tároló alapértelmezett ágát lefedi, olyan állapotban, ahogy az adatgyűjtés lezárásakor, 2025. augusztus 7-én kinézett.

A kutatók 2026. július 27-én és 28-án tesztelték a talált hitelesítő adatokat a kibocsátó szolgáltatásoknál. Ezek közül 543 699 egyedi hitelesítő adat továbbra is sikeresen azonosított. A Truffle Security szerint a kiszivárgott adatok mediánja 784 napja volt nyilvános kódban, míg 10%-uk több mint 6,3 éve szivárgott.

A legrégebbi, még működő hitelesítő adat, amit a kutatók azonosítottak, 2009 júniusára nyúlt vissza. Egy adatbázis-elérési adatokról volt szó, amelyeket egy Erlang webkiszolgáló konfigurációs fájljában tároltak, és 16,1 évvel később is érvényesek maradtak. A 2009-ből fennmaradt példák között FTP-belépési adatokat és egy AWS hozzáférési kulcsot is találtak.

Az eredmények arra is rámutatnak, hogy a GitHub push protection funkciója segít, de csak azoknál a hitelesítő típusoknál, amelyeket felismer és blokkol.

A GitHub 2024. február 29-én alapértelmezetten bekapcsolta a push protection funkciót a nyilvános tárolókra. A Truffle Security szerint az érintett, támogatott hitelesítő típusok nyilvános kódban való megjelenésének aránya nagyjából 53%-kal csökkent a bevezetést megelőző és követő 12 hónap átlagában.

Ennek ellenére a vizsgálatban talált hitelesítő adatok közül 199 843-at már azután commitoltak, hogy a push protection alapértelmezetté vált.

Az egyik ok a lefedettség. A kutatók szerint az összes még aktív hitelesítő adat 51,8%-a olyan típushoz tartozott, amelyet a GitHub alapértelmezetten nem blokkol, például adatbázis-kapcsolati stringek, privát kulcsok és Google API kulcsok.

A vizsgálat például 51 067 aktív MongoDB kapcsolati stringet és 33 343 élő Google API kulcsot talált. Emellett 31 374 aktív Gemini API kulcsot is azonosítottak, amelyek medián szivárgási dátuma 2025 februárjára esett.

A tanulmány szerint azonban a nagyobb gond a hitelesítő adatok visszavonása.

A datasetben talált 101 886 npm tokenből mindössze egy volt még aktív. A GitHub tokeneknél hasonló mintát láttak: 73 048 észlelt tokenből 260 működött még, míg a 30 437 Hugging Face tokenből csak 15 maradt érvényes.

Az adatbázis-hitelesítési adatok egészen más képet mutattak. A 12 985 PostgreSQL kapcsolati stringből 11 465 még aktív volt, ami 88%-os arány. MySQL esetében 2 421 hitelesítő adatból 1 806 maradt használható, nagyjából 75%.

A Truffle Security ezt a különbséget nagyrészt az automatizált visszavonásnak tulajdonítja. A GitHub-hez és az npm-hez hasonló szolgáltatók automatikusan érvényteleníteni tudják a kiszivárgott tokeneket, amint azonosítják őket. Egy PostgreSQL kapcsolati stringnek ezzel szemben általában nincs központi kibocsátója, amely automatikusan visszavonhatná.

GitHub egy titkos szkennelési partnerprogramot is működtet, amely értesíteni tudja a szolgáltatókat, ha a hitelesítő adataik nyilvános tárolókban bukkannak fel. A szolgáltatók azonban nem kötelesek ezeket a hitelesítő adatokat visszavonni a bejelentés után.

A kutatók szerint két külön problémáról van szó: meg kell akadályozni, hogy a titkok egyáltalán bekerüljenek a tárolóba, és külön feladat a már kiszivárgott adatok visszavonása. A push protection jelentősen csökkenti a támogatott szivárgások számát, de nem tudja letiltani azokat a hitelesítő adatokat, amelyek már korábban kikerültek.

Az adatbázis arra utal, hogy a kiszivárgott hitelesítő adatok valós száma jóval magasabb lehet a vizsgálatban megerősített 543 699-nél. A The Stack v3 csak az alapértelmezett ágat tartalmazza a bejárás időpontjában, és nem foglalja magában a törölt commitokat, az átírt előzményeket, a visszavont titkokat, illetve azokat a hitelesítő adatokat, amelyek kizárólag más ágakban szerepelnek.

A Truffle Security ajánlása egyértelmű: ha egy hitelesítő adat egyszer bekerült egy nyilvános tárolóba, onnantól kompromittáltnak kell tekinteni, és azonnal le kell cserélni. A fejlesztőknek érdemes a tároló előzményeit is átvizsgálni, és ahol lehet, rövid élettartamú, automatikusan lejáró hitelesítő adatokat használni.

Forrás: Truffle Security