Într-un raport recent, firma de securitate Truffle Security a descris rezultatul unei verificări la scară mare: din codul public de pe GitHub, 543.699 de credențiale unice mai erau valide când au fost testate, pe 27 și 28 iulie 2026. Ele apăreau în 1.103.438 de locuri, pentru că aceeași credențială poate fi copiată în mai multe fișiere și în mai multe depozite. BleepingComputer a preluat cifrele și a precizat că nu le-a verificat independent. Este o măsurătoare făcută de un furnizor, nu un incident cu o victimă numită.
Ce a măsurat studiul, în termeni exacți
- Confirmat în raport: setul analizat este un instantaneu cu 224.553.295 de depozite publice GitHub, adunat pentru antrenarea modelelor de limbaj, cu 58.467.468.698 de intrări de fișiere. Colectarea s-a încheiat pe 7 august 2025.
- Confirmat în raport: doar ramura implicită a fiecărui depozit și doar codul public. Istoricul comiterilor și depozitele private nu sunt incluse. Truffle spune singur că populația reală este mai mare.
- Confirmat în raport: fiecare credențială candidată a fost testată pe 27 și 28 iulie 2026 la serviciul care a emis-o. Cele 543.699 sunt, deci, credențiale prezente în codul din august 2025 care funcționau încă la aproape un an distanță.
- Neconfirmat de studiu: câte dintre ele au fost furate sau folosite, cine le deține și dacă proprietarii au fost anunțați. Raportul nu publică numele depozitelor tocmai pentru că accesele funcționează.
Cifra de 784 de zile: vârsta fișierului, nu durata expunerii
Cea mai citată cifră este mediana de 784 de zile. Raportul o definește ca timpul scurs de la ultima modificare a fișierului până la verificare. Nu este o măsură a cât timp a fost credențiala expusă public, iar Truffle notează că vârstele sunt probabil subestimate: un fișier editat după scurgere pare mai nou decât scurgerea. La percentila 90, vârsta este de 6,3 ani. Cea mai veche credențială găsită era într-un fișier modificat ultima dată pe 13 iunie 2009: date de acces la o bază de date, într-o configurație de server web.
Diferența contează pentru felul în care citești studiul. „O credențială valabilă stă ani întregi într-un fișier” este susținut de date. „Atacatorii au avut ani de zile acces” nu este.
De ce unele credențiale mor singure, iar altele nu
Raportul compară furnizorii, iar cele două cifre care apar și la BleepingComputer sunt grăitoare. Dintre jetoanele npm găsite în cod, 101.886 au fost comise și doar unul mai era valid la testare. Dintre credențialele de cont de serviciu Google Cloud, 126.963 au fost comise și 69.041 erau încă valide, adică aproximativ 54%.
Explicația propusă de Truffle, deci interpretarea lor, este că diferența vine din faptul dacă furnizorul rulează un proces care revocă automat o credențială scursă. Fără revocare, detectarea nu face nimic: cheia continuă să funcționeze. Pentru un cititor din afară, concluzia utilă este mai simplă: nu presupune că furnizorul tău te protejează. Verifică.
Ce face și ce nu face protecția la push
- Din februarie 2024, GitHub activează implicit blocarea credențialelor cunoscute la push. Potrivit raportului, în cele douăsprezece luni din jurul lansării, expunerea categoriilor protejate a scăzut cu 53%, iar a celor neprotejate cu 7%.
- Totuși, 199.843 dintre credențialele valide (36,8%) au fost expuse după ce protecția devenise implicită.
- Potrivit raportului, 51,8% dintre credențialele valide sunt de tipuri pe care protecția nu le blochează implicit, de exemplu șiruri de conectare la baze de date, chei API Google și chei private.
Protecția la push este deci utilă și incompletă. Ea prinde ceea ce a fost definit ca model recunoscut. Ce este în afara modelului trece, iar ce a ajuns deja în cod nu este atins.
Ce nu se știe
- Ce procent dintre cele 543.699 de credențiale au fost folosite de atacatori. BleepingComputer notează explicit că studiul nu arată asta.
- Dacă proprietarii au fost anunțați. Raportul nu spune.
- Ce sectoare sau organizații le dețin. Nicio sursă citită nu leagă studiul de organizații din România, iar articolul nu face o astfel de afirmație.
- Cât de mare este problema în depozitele private sau în istoricul comiterilor. Studiul nu le acoperă.
Ce recomandă Truffle și ce adăugăm noi
Recomandările de mai jos aparțin Truffle Security, firma care vinde instrumente de detectare a secretelor și are, deci, un interes în subiect. Le citez pentru că sunt rezonabile, nu pentru că ar fi neutre.
- Tratează o credențială comisă ca epuizată în clipa în care a ajuns în depozit. Rotește întâi, curăță istoricul după.
- Scanează și istoricul propriilor depozite, nu doar starea curentă.
- Preferă credențiale care expiră singure.
- Află dacă furnizorul tău are un program de revocare a credențialelor scursă.
Partea de mai jos este a noastră. Este despre oameni și decizii, nu despre instrumente. Un caz similar la scară mică, în care ștergerea postării nu a invalidat secretul, este descris în articolul nostru despre credențiala unui service principal publicată într-un issue public.
Comportamentul pe care îl antrenezi, pe roluri
- Dezvoltatorii: dacă ai comis o credențială, nu începe cu curățarea istoricului. Anunță, rotește, abia apoi curăță. Ștergerea din cod sau dintr-un comentariu nu oprește un acces care funcționează.
- Dezvoltatorii: șirurile de conectare, cheile API și cheile private nu sunt acoperite întotdeauna de protecția la push. Nu te baza pe faptul că push-ul a trecut.
- Responsabilii de echipă: știu fiecare credențială pe cine o are ca proprietar și cine poate s-o rotească în afara programului de lucru.
- Platforma și operațiunile: preferă acces cu durată limitată, acolo unde furnizorul o permite, în locul cheilor valabile la nesfârșit.
- Conducerea: întreabă cât durează de la „am găsit o credențială în cod” până la „cea nouă e în folosință”, nu câte instrumente de scanare avem.
Exercițiul: 40 de minute, cu o singură echipă și un singur depozit
Participă echipa care întreține depozitul, cine administrează contul furnizorului principal de cloud și cine răspunde de securitate. Nu aveți nevoie de nicio credențială reală: lucrați pe liste și pe responsabilități.
- Pasul 1 (10 minute) — listați tipurile de credențiale pe care le folosește echipa: chei API, șiruri de conectare, chei private, conturi de serviciu. Pentru fiecare, scrieți cine o emite și cine o poate rota.
- Pasul 2 (10 minute) — pentru fiecare tip, notați: expiră singură? Furnizorul o revocă dacă apare public? Protecția la push o recunoaște?
- Pasul 3 (10 minute) — scenariul: un coleg găsește o credențială validă într-un fișier modificat ultima dată acum doi ani. Cine este anunțat, cine rotește, în cât timp, și cine verifică dacă a fost folosită?
- Pasul 4 (10 minute) — scrieți regula „rotește întâi, curăță istoricul după” și numiți proprietarul ei. Decideți ce se face cu tipurile care nu expiră și nu sunt acoperite de nicio protecție.
Ce măsori
- Timpul de la raportarea unei credențiale expuse până la intrarea în folosință a celei noi.
- Procentul de credențiale cu proprietar numit.
- Procentul de credențiale care expiră singure.
- Numărul de tipuri de credențiale fără detectare automată.
- Câte depozite au fost scanate inclusiv în istoric, nu doar în starea curentă.
- Câte expuneri sunt prinse înainte de push și câte după.
Concluzia nu este că GitHub este nesigur sau că studiul dovedește un val de atacuri. Dovedește altceva, mai modest și mai util: un număr foarte mare de credențiale au rămas în cod vizibil și au continuat să funcționeze mult după ce cineva le-a pus acolo. Diferența dintre un secret expus și unul inofensiv este, de multe ori, un singur pas pe care nimeni nu l-a făcut: rotirea.