CyberJurnal | 30 octombrie 2026
Când un dezvoltator publică accidental o cheie într-un repository public, informația poate rămâne utilizabilă mult după ce codul a fost descărcat, clonat sau indexat de alte servicii. O cercetare publicată pe 28 octombrie 2026 arată amploarea problemei pe Gitee, una dintre cele mai mari platforme de găzduire a codului din China: 26.400 de credențiale unice, verificate ca active la momentul scanării, descoperite în peste 7,25 milioane de repository-uri.
Cum a fost realizat studiul
Cercetătorul independent Ben Zimmermann, în colaborare cu echipa Kingfisher de la MongoDB, a scanat 7.256.531 de repository-uri publice, folosind două motoare diferite de căutare a secretelor: TruffleHog și Kingfisher. Validarea s-a făcut prin interogări către API-urile furnizorilor corespunzători, iar rezultatele au fost deduplicate după valoarea credențialei.
Conform raportului publicat de MongoDB, cele două motoare aveau acoperiri complementare: unul identifica mai bine anumite chei cloud, iar celălalt avea detectori mai eficienți pentru servicii AI.
Ce tipuri de secrete au fost găsite
Raportul menționează acces pentru Alibaba Cloud, YouTube API, DeepSeek, OpenAI, Hugging Face și alți furnizori. Au fost observate atât chei pentru servicii mici, cât și acreditări cu posibil impact asupra unor organizații mari.
O cheie validă nu înseamnă automat că a fost exploatată. Semnificația depinde de permisiunile ei: o cheie doar de citire pentru un serviciu limitat diferă radical de un token cu drepturi de administrare a unei organizații sau a infrastructurii cloud.
De ce două scanere găsesc mai mult decât unul
Cercetarea a înregistrat 12.737 de rezultate unice prin TruffleHog și 14.664 prin Kingfisher, cu o suprapunere de 1.001. Diferența arată că nu există un singur instrument care să recunoască toate formatele, toți furnizorii și toate tipurile de secrete.
Pentru proiectele multicloud și aplicațiile AI, un audit eficient trebuie să cuprindă pipeline-urile CI/CD, fișierele de configurare, istoricul Git, logurile de build și artifactele publicate. Ștergerea unui fișier din ultima versiune a repository-ului nu invalidează o cheie care a apărut în commituri vechi.
Ce trebuie să facă o echipă DevOps
Identificați cheile publicate, revocați-le și emiteți altele cu permisiuni minime. Mutați secretele în sisteme dedicate, folosiți identități de workload și acreditări cu durată scurtă acolo unde este posibil, apoi activați scanarea preventivă în etapa de commit și în CI. Examinați și logurile serviciilor pentru acces neobișnuit în intervalul expunerii.
Cercetătorii au notificat furnizorii cu cele mai importante volume de chei, dar nu confirmaseră încă revocarea tuturor credențialelor la data publicării.
Concluzie: expunerea secretelor în repository-uri este o problemă de arhitectură operațională, nu doar o greșeală punctuală a dezvoltatorului. Combinarea scanerelor și rotația rapidă a credențialelor trebuie să devină rutină.
Sursă primară: MongoDB — Scanning 7.25 Million Public Repositories on Gitee, 28 octombrie 2026.
Imagine: ilustrație editorială originală CyberJurnal.
