
GitHub trece la ModernBERT: scanarea secretelor e cu 86% mai rapidă

În analiza GitHub publicată la 13 octombrie 2026, compania descrie un flux de scanare a secretelor care folosește expresii regulate și un clasificator ModernBERT: timpul median de execuție după push a scăzut cu 86% față de fluxul anterior bazat pe un model lingvistic mare (LLM), iar acceptarea alertelor, ponderată după proprietarul depozitului, a crescut cu 11,5%. Creșterea acceptării sugerează că alertele au devenit mai utile pentru clienții incluși în experiment, dar nu arată câte alarme false primește acum fiecare dezvoltator.
Disponibilitatea depinde de momentul în care este verificat codul. Conform notei GitHub din 7 octombrie 2026, clienții cu alerte AI pentru parole au trecut automat la noul model, în timp ce detectarea AI a secretelor prin protecția la push se află în previzualizare privată. Reducerea timpului median a fost măsurată pentru scanările de după push; nu reprezintă timpul economisit la fiecare verificare care poate opri un push.
Cum separă ModernBERT un secret de un șir asemănător
Fluxul începe cu expresii regulate care selectează rapid valori ce ar putea fi parole, chei sau alte credențiale. Această selecție este largă în mod intenționat: un secret eliminat aici nu mai ajunge la clasificator. În consecință, printre candidați intră și valori inofensive cu aceeași formă, precum identificatori de compilare, sume de control sau exemple din documentație.
ModernBERT primește valoarea candidată împreună cu informații despre locul în care apare: calea fișierului, tipul posibilului secret, numele variabilelor și codul din apropiere. Modelul produce un scor pe baza căruia scannerul decide dacă acea valoare merită să devină alertă. Un șir cu formă de parolă lângă configurația unei baze de date de producție oferă alte indicii decât unul aflat într-un fișier de teste; forma șirului, singură, nu rezolvă diferența.
Constatările cu încredere ridicată sunt transmise mai departe, iar valorile care par substituenți, exemple ori date de test sunt filtrate. Cele două componente îndeplinesc astfel sarcini diferite: regulile găsesc candidați fără să ceară modelului să parcurgă tot conținutul, iar clasificatorul folosește contextul acolo unde o potrivire de formă ar produce zgomot. Rezultatul urmărit este ca dezvoltatorul să primească mai puține constatări inofensive fără ca scannerul să piardă secrete reale.
De ce un clasificator compact poate fi mai potrivit decât un LLM
Decizia repetată de scanner este restrânsă: candidatul trebuie alertat sau filtrat. Un clasificator de tip encoder poate fi ajustat pentru această decizie și poate returna direct un scor, fără să genereze un răspuns în limbaj natural. În vechiul flux, evaluarea prin apeluri către un LLM la distanță adăuga latență și cost; aici modelul compact rulează pe infrastructura de inferență a companiei.
Exemplele folosite la antrenare au inclus date provenite din experiența produsului, candidați selectați din depozite prin expresii regulate și cazuri sintetice dificile. Printre acestea se află valori autentice, dar și șiruri care le imită convingător: substituenți din documentație, date de test și identificatori fără rol de autentificare. Înainte de separarea datelor pentru antrenare și evaluare, exemplele care împărțeau același depozit sau aceeași valoare au fost grupate pentru a limita apariția unor cazuri aproape identice în ambele seturi.
Modelul antrenat este exportat în format ONNX și cuantizat pentru inferență rapidă. Performanța măsurată aparține însă fluxului implementat, care include selecția prin regex, clasificarea și infrastructura de execuție. Rezultatul nu stabilește că orice model compact ar depăși orice LLM într-o altă sarcină; arată avantajul acestei configurații pentru o decizie frecventă și bine delimitată.
Ce măsoară precizia, recall-ul și acceptarea alertelor
Relatarea Blockchain.News consemnează rezultatele atribuite GitHub: în evaluarea offline a scanării după push, precizia a fost cu 13% mai mare și recall-ul cu 19% mai mare decât în fluxul LLM anterior, pe același trafic public; costul de servire al clasificatorului a fost cu peste 98% mai mic decât cel al apelurilor la LLM de la distanță. Procentele descriu comparații diferite, așa că reducerea costului nu trebuie citită ca o reducere a prețului plătit de un client.
Precizia arată ce parte dintre valorile semnalate sunt într-adevăr secrete. Recall-ul arată ce parte dintre secretele reale din setul evaluat au fost găsite. Creșterea simultană a acestor indicatori sugerează că filtrarea valorilor inofensive nu a fost obținută prin ratarea unei părți mai mari dintre secretele etichetate.
Acceptarea alertelor măsoară reacția clienților la constatările primite în experimentul A/B, nu clasificarea unui set de exemple cu răspunsuri cunoscute. Ponderarea după proprietarul depozitului reduce influența clienților care rezolvă în bloc un volum foarte mare de alerte. O acceptare mai mare este compatibilă cu mai puține întreruperi inutile, dar poate reflecta și felul în care clienții tratează alertele; ea nu este o rată directă a alarmelor false.
GitHub a publicat schimbările relative, fără valorile absolute ale preciziei și recall-ului sau numărul de candidați evaluați. Din aceste procente nu se poate calcula câte alerte false au dispărut într-un depozit și nici câte secrete au rămas nedetectate. O evaluare independentă, pe date etichetate și cu rate absolute publicate, ar permite aprecierea mai precisă a diferenței dincolo de testele companiei.
Ce se schimbă pentru dezvoltatori la push
Scanarea de după push creează alerte pentru codul ajuns deja în depozit, astfel încât dezvoltatorii și echipele de securitate să poată investiga o posibilă credențială. Protecția la push verifică modificarea înainte de acceptare și poate oferi ocazia eliminării secretului din acea modificare. În acest al doilea moment, o alarmă falsă poate întrerupe direct trimiterea codului, iar un secret ratat poate intra în istoricul depozitului.
Viteza noului clasificator face posibilă extinderea detectării secretelor generice la protecția la push, însă accesul la această funcție este încă limitat. Pentru clienții care primesc deja alerte AI pentru parole, efectul imediat privește calitatea constatărilor investigate după trimiterea codului. Următorul reper util pentru a judeca impactul asupra întreruperilor va fi publicarea unor rezultate separate pentru protecția la push, odată cu extinderea accesului la ea.
Citește și:
Articole similare


PageBreak a confirmat peste 500 de breșe XSS, cu aproape zero alarme false

Protejezi ramura principală pe GitHub? Ruleset-ul evită regula care se pierde

JSON valid nu înseamnă date corecte: două validări pentru ieșirea unui LLM

Qdrant sau Weaviate: 4,55 ms nu bat automat un recall de 99%

Cache-ul semantic taie apelurile LLM, dar poate reutiliza răspunsul greșit
Abonează-te la newsletter
Primește cele mai noi știri despre Web3, IA și cripto direct în inbox.