Zero-day-urile – acele vulnerabilități pe care nimeni nu le cunoaște până când sunt exploatate – au devenit un teren de testare pentru AI. În mai 2026, Google Threat Intelligence Group a raportat un caz fără precedent: pentru prima dată, cercetătorii au avut un grad ridicat de încredere că un actor amenințător a folosit AI pentru a dezvolta un exploit zero-day. Exploit-ul apărea într-un script Python și ocolea autentificarea cu doi factori pe un instrument open-source de administrare a sistemelor, folosit pe scară largă, atunci când atacatorul avea deja credențiale valide. Ce i-a făcut pe cercetători să creadă că AI a fost implicată? Scriptul avea comentarii neobișnuit de detaliate, un scor de vulnerabilitate fabricat și un stil de codare extrem de structurat, specific ieșirilor generate de modele lingvistice. Nu au atribuit codul unui model anume, dar semnalele erau clare.
Ceea ce face acest caz cu adevărat important nu este doar utilizarea AI-ului, ci natura vulnerabilității în sine. Nu era vorba de un crash, o eroare de memorie sau un input nesigur – probleme pe care fuzzer-ele și instrumentele de analiză statică le găsesc cu ușurință. Era o presupunere de încredere codificată direct în logică, o contradicție logică între permisiuni, funcții și comportamentul așteptat. Exact acest tip de raționament transversal este cel la care un model de limbaj se pricepe deosebit de bine, pentru că poate examina modul în care interacționează diferite părți ale unui codebase. Astfel, AI deschide o nouă rută de atac, una care nu lasă urme tehnice evidente.
Datele Google sugerează că nu este un caz izolat. Conform analizei Google Threat Intelligence Group pentru 2025, cercetătorii au urmărit 90 de zero-day-uri exploatate în sălbăticie, comparativ cu 78 în 2024. Software-ul enterprise și dispozitivele de tip appliance au reprezentat 43 de cazuri, adică 48% din total. Ambele cifre sunt recorduri în setul de date Google. Tendința este clară: atacatorii devin mai rapizi, iar AI-ul le oferă un avantaj semnificativ în descoperirea și valorificarea vulnerabilităților.
Dar iată paradoxul: deși AI-ul accelerează analiza codului, multe întârzieri apar după ce vulnerabilitatea a fost identificată. Odată ce un flaw devine public, echipele de securitate trebuie să afle mai întâi unde rulează. Într-un mediu de containere, acest lucru poate fi extrem de dificil. O imagine de container poate conține pachete de sistem de operare, biblioteci de aplicații și dependențe moștenite din imaginea de bază, alături de shell-uri sau utilitare care nu au nicio legătură cu scopul vizibil al workload-ului. O componentă vulnerabilă poate sta la mai multe straturi sub aplicația propriu-zisă și poate apărea în numeroase imagini, chiar dacă organizația nu a adăugat-o niciodată direct.
Log4Shell a expus această problemă la scară largă în 2021. Biblioteca Log4j afectată fusese încorporată într-o gamă largă de produse și servicii. Pentru multe organizații, obținerea patch-ului a fost doar începutul. Au trebuit să identifice fiecare server, aplicație și container care avea o versiune vulnerabilă înainte de a putea finaliza remedierea. Software bills of materials (SBOM) oferă o evidență mai clară a ceea ce conține fiecare imagine. Imaginile mai mici pot reduce căutarea, excluzând pachetele de care workload-ul nu are nevoie. Minimus analizează exact această problemă: reducerea pachetelor, vizibilitatea dependențelor și reconstruirea imaginilor după ce o componentă afectată este dezvăluită.
Beneficiul nu este prevenirea zero-day-urilor – o imagine minimă poate conține în continuare un flaw necunoscut. Dar oferă echipelor mai puține pachete de investigat, mai puține puncte de expunere și mai puțin software de înlocuit sau retestat odată ce problema devine cunoscută. Este o chestiune de igienă digitală care face diferența între ore și zile de muncă.
AI-ul este folosit și pentru a scurta timpul dintre dezvăluire și dezvoltarea patch-ului. Modelele pot inspecta codul sursă, pot compara rapoartele de vulnerabilitate cu evidențele pachetelor și pot propune modificări pentru versiunile afectate. Dar toate acestea sunt inutile dacă evidențele pachetelor sunt învechite sau dacă nimeni nu știe care imagini conțin componenta vulnerabilă. Un exemplu concret este CodeMender, agentul AI dezvoltat de Google DeepMind, care a contribuit cu 72 de corecții de securitate la proiecte open-source consacrate în primele șase luni de funcționare. Sistemul combină raționamentul modelului cu analiza statică, testarea runtime și fuzzing pentru a produce și evalua patch-uri propuse. Dar patch-urile nu au fost acceptate automat. Cercetătorii umani au revizuit fiecare modificare înainte de a fi trimisă, verificând regresii și confirmând că abordează cauza de bază, nu doar simptomul vizibil.
Chiar și o modificare de cod aprobată nu termină treaba. Echipele trebuie să identifice imaginile afectate, să le reconstruiască cu dependența corectată și să testeze rezultatul înainte de implementare. Într-un mediu prost documentat, localizarea fiecărei instanțe poate dura mai mult decât producerea patch-ului în sine. Inventarele exacte oferă instrumentelor automate ceva concret cu care să lucreze. Ele conectează un flaw nou dezvăluit la versiunea de pachet, imaginea și workload-ul care necesită de fapt atenție.
AI-ul accelerează analiza codului atât pentru atacatori, cât și pentru apărători, dar multe întârzieri apar în continuare după ce vulnerabilitatea a fost identificată. O echipă poate petrece ore întregi deschizând imagini și verificând manual listele de pachete. Alta poate căuta într-un inventar actualizat și vedea aproape imediat care workload-uri conțin versiunea afectată. Această diferență are puțin de-a face cu sofisticarea instrumentului de descoperire. Vine din deciziile luate mai devreme despre inventarele software, compoziția imaginilor și modul în care containerele sunt construite și înlocuite.
Pe măsură ce cercetarea vulnerabilităților devine tot mai rapidă, iar AI-ul devine un aliat atât pentru bine, cât și pentru rău, organizațiile care investesc în igiena containerelor și în evidențe precise ale dependențelor vor fi cele care supraviețuiesc. Nu este vorba doar despre a fi primul care aplică un patch, ci despre a ști exact unde să-l aplici. Iar acest lucru nu poate fi rezolvat doar cu AI – necesită disciplină, procese clare și o înțelegere profundă a propriului mediu. Într-o lume în care fiecare secundă contează, pregătirea înseamnă totul.
De ce este important:
Acest articol evidențiază o schimbare fundamentală în securitatea cibernetică: AI-ul nu doar că grăbește descoperirea vulnerabilităților, dar redefinește întreaga cronologie a răspunsului. Pentru liderii IT și echipele de securitate, înțelegerea faptului că viteza de reacție depinde mai puțin de instrumentele de detectare și mai mult de igiena infrastructurii – inventare exacte, imagini minimale, evidențe clare ale dependențelor – este crucială. Într-un peisaj în care atacatorii folosesc AI pentru a găsi flaw-uri logice ascunse, organizațiile care nu își pun la punct aceste fundații vor rămâne în urmă, indiferent cât de avansate sunt instrumentele lor de apărare.
