Prima oară când am văzut un raport de securitate cu peste patru sute de „probleme critice”, omul care mi l-a arătat a râs scurt și a spus că jumătate dintre ele sunt praf în ochi. Avea dreptate. După două zile de verificări manuale, din lista aceea imensă rămăseseră unsprezece lucruri care contau cu adevărat, iar dintre ele doar trei puteau fi exploatate de cineva din afară.
Povestea asta se repetă în multe companii, cu variații de mărime. Instrumentele automate de scanare produc volume uriașe de rezultate, iar oamenii care le primesc ajung să piardă mai mult timp triind decât reparând. Aici intervine ideea de test de penetrare autonom, care nu se mai mulțumește să semnaleze o suspiciune, ci încearcă să o și demonstreze.
Ce urmează este o explicație pe îndelete a modului în care funcționează un astfel de sistem. Fără jargon inutil, dar și fără să pretind că totul e simplu, pentru că nu este.
Ce este, de fapt, un pentest și de ce a devenit o rutină obligatorie
Un test de penetrare înseamnă să pui pe cineva să se comporte ca un atacator, cu acordul tău scris, pe sistemele tale. Nu e o scanare de suprafață, ci o încercare reală de a intra, de a escalada privilegii, de a ajunge la date. Scopul nu e să sperie pe nimeni, ci să afle ce s-ar întâmpla dacă un om rău intenționat ar avea aceleași unelte și puțină răbdare.
Ideea nu e nouă. În anii șaizeci, echipe numite „tiger teams” testau sistemele militare americane exact în felul ăsta, iar în 1974 un raport al armatei descria deja metodologia. Diferența e că atunci vorbeam de câteva zeci de sisteme, iar azi o singură companie de talie medie poate avea sute de subdomenii, API-uri, aplicații interne și integrări cu terți.
Presiunea de reglementare a împins testarea de la statutul de bună practică la cel de obligație. Directiva NIS2, cerințele PCI DSS pentru comercianții care procesează carduri, auditurile ISO 27001, toate cer dovezi periodice că cineva chiar a încercat să spargă sistemul. Pentesterii buni sunt puțini, sunt scumpi și au agenda plină, așa că oferta nu ține pasul cu cererea.
De aici a pornit toată discuția despre automatizare. Nu din pasiune pentru tehnologie, ci dintr-o aritmetică simplă între câte aplicații trebuie testate și câți oameni există care știu să facă asta bine.
De la scanere automate la agenți care iau decizii singuri
Scanerul clasic și limita lui de bun simț
Un scanner de vulnerabilități tradițional funcționează cam ca un inspector cu un clipboard. Are o listă de semnături cunoscute, trimite cereri, compară răspunsurile cu ce se așteaptă să vadă și bifează. Dacă versiunea de bibliotecă raportată de server apare într-o bază de date de vulnerabilități, apare o alertă.
Problema e că inspectorul ăsta nu înțelege contextul. Nu știe dacă biblioteca vulnerabilă e folosită efectiv în codul aplicației, dacă ruta expusă e protejată de un firewall, dacă parametrul suspect ajunge vreodată într-o interogare de bază de date. Raportează ce vede, iar interpretarea rămâne complet în sarcina omului.
De aici vin faimoasele false positives, alertele care sună grav dar nu înseamnă nimic în practică. Și, mai periculos, false negatives, adică problemele reale pe care scannerul nu le vede pentru că ele apar doar din combinarea a trei lucruri aparent inofensive. Un pentester uman le găsește pentru că gândește în trasee, nu în bife.
Momentul în care modelele lingvistice au intrat în joc
Prin 2023 și 2024, lumea offensive security a început să experimenteze serios cu modele lingvistice mari. Nu ca să scrie rapoarte mai frumoase, deși asta s-a întâmplat oricum, ci pentru că modelele se dovedeau surprinzător de bune la citirea răspunsurilor HTTP, la înțelegerea logicii unei aplicații și la generarea de payloaduri adaptate.
A apărut apoi conceptul de agent, adică un model care nu răspunde doar o dată, ci primește un obiectiv, are acces la unelte și decide singur ce pas urmează. Îi dai un target, îi dai un scanner, un proxy, un browser automatizat, și îl lași să lucreze în buclă. Observă, formulează o ipoteză, testează, citește rezultatul, ajustează.
Diferența față de un script obișnuit este că traseul nu e scris dinainte de nimeni. Un script rulează aceiași pași indiferent de ce găsește. Un agent își schimbă planul în funcție de ce vede, cam cum face un om care se plimbă prin aplicație și observă că formularul de recuperare a parolei se comportă ciudat.
Anatomia unui test autonom, pas cu pas
Delimitarea terenului de joacă
Orice test serios începe cu scope, adică lista exactă a domeniilor, IP-urilor și funcționalităților pe care ai voie să le atingi. La un sistem autonom, partea asta devine și mai importantă, pentru că un agent scăpat din lesă poate rătăci pe infrastructura altcuiva în zece minute. Utilizatorul definește granițele, iar sistemul trebuie să le respecte tehnic, nu doar declarativ.
Tot aici se stabilesc regulile de angajament. Ce intensitate e permisă, dacă se poate testa ceva care ar putea afecta disponibilitatea, dacă există ferestre orare în care nu se rulează nimic. Într-un magazin online, de exemplu, nimeni nu vrea ca testul să pornească vineri seara, când traficul e la maxim.
Se definesc și credențialele. Un test fără autentificare simulează un atacator complet din exterior, unul cu cont de utilizator obișnuit simulează un client rău intenționat, iar unul cu cont de administrator caută probleme de escaladare internă. Fiecare variantă dă o imagine diferită și complementară.
Recunoașterea și cartografierea aplicației
Prima fază tehnică seamănă cu o plimbare metodică prin clădire. Sistemul enumeră subdomenii, identifică servicii active, culege headere, descoperă rute, formulare, parametri, endpointuri de API. Dacă aplicația e una modernă, cu JavaScript care încarcă dinamic conținut, un browser automatizat parcurge interfața și înregistrează fiecare cerere plecată către server.
Rezultatul e o hartă a suprafeței de atac. Nu doar o listă de adrese, ci o înțelegere a felului în care se leagă lucrurile între ele. Unde se intră cu date, unde se ies date, care funcționalități cer autentificare și care nu, ce roluri există în aplicație.
Aici modelele de limbaj aduc un avantaj real față de instrumentele vechi. Pot citi denumirile parametrilor, textele din interfață, structura unui răspuns JSON, și pot deduce ce face o funcție chiar dacă nu e documentată nicăieri. Un parametru numit „invoice_id” într-un endpoint de descărcare spune multe unui model antrenat pe milioane de linii de cod.
Formularea ipotezelor de atac
Cu harta în față, sistemul începe să pună întrebări de tipul „ce s-ar întâmpla dacă”. Dacă schimb numărul facturii din URL, primesc factura altcuiva. Dacă trimit un caracter ciudat în câmpul de căutare, aplicația îmi arată o eroare de bază de date. Dacă apelez direct endpointul de ștergere, fără să trec prin interfață, chiar se șterge ceva.
Ipotezele astea se prioritizează. Un sistem bine construit nu aruncă mii de payloaduri la întâmplare, pentru că ar produce zgomot enorm și ar risca să destabilizeze aplicația. Alege încercările cu cea mai mare probabilitate de succes, în funcție de ce a observat în faza de recunoaștere.
Ce e interesant aici e că modelul poate construi lanțuri. Nu testează fiecare problemă separat, ci încearcă să vadă dacă o informație obținută într-un loc deschide o ușă în altul. Un token expus într-un fișier de configurare devine cheia pentru un panou de administrare, care la rândul lui permite încărcarea unui fișier, care duce la execuție de cod.
Încercarea propriu-zisă și dovada
Momentul care desparte un pentest autonom de o scanare obișnuită este exploatarea controlată. Sistemul nu se oprește la „acest parametru pare vulnerabil la SQL injection”, ci încearcă efectiv să extragă un fragment de informație care confirmă asta. Nu golește baza de date, ci demonstrează că ar putea.
Dovada se numește, în jargon, proof of concept. Poate fi cererea HTTP exactă care a produs rezultatul, răspunsul serverului, o captură, un fragment de date extras și anonimizat. Rostul ei e să elimine discuția „poate e fals pozitiv” înainte ca ea să înceapă.
Partea delicată e că exploatarea trebuie să rămână reversibilă și lipsită de daune. Un agent care rulează fără supraveghere are nevoie de limite tehnice clare, altfel un test de securitate se transformă într-un incident de securitate. De aceea acțiunile distructive sunt de obicei blocate explicit, iar cele cu risc rămân în sarcina omului.
Verificarea deterministă, partea mai puțin spectaculoasă
Modelele lingvistice au un defect binecunoscut. Uneori sunt convingătoare și greșite în același timp. Un model poate „crede” că a exploatat ceva, poate scrie un raport impecabil despre asta, iar realitatea să fie că serverul a returnat pur și simplu o pagină de eroare.
Soluția practică este să pui peste stratul probabilistic un strat determinist. Adică o verificare scrisă în cod obișnuit, care nu interpretează nimic, ci compară fapte. A apărut sau nu șirul de caractere așteptat în răspuns. S-a modificat sau nu valoarea din baza de date. Codul de status a fost 200 sau 403.
Această combinație, agent inteligent plus validator rigid, e miezul arhitecturilor serioase de testare autonomă. Fără ea, sistemul devine o mașină de generat povești plauzibile. Cu ea, fiecare concluzie vine însoțită de traseul complet care a produs-o, iar specialistul poate reface pașii manual dacă are dubii.
Raportul și ce face echipa cu el
Un raport bun nu este o listă de vulnerabilități sortate după severitate teoretică. Este o poveste despre ce poate face un atacator în aplicația ta, în ce ordine, cu ce efect. Un XSS dintr-un formular de contact intern contează mult mai puțin decât unul din pagina de checkout, chiar dacă scorul CVSS e identic.
Sistemele autonome moderne livrează, pe lângă descriere, și materialul necesar pentru reproducere. Dezvoltatorul primește cererea exactă, nu o explicație generală despre ce înseamnă injecția SQL. Asta scurtează dramatic timpul dintre raportare și reparare, pentru că elimină ping-pongul clasic în care programatorul spune că nu poate reproduce problema.
Ultima verigă e retestarea. După ce echipa repară ceva, testul se rulează din nou doar pe zona respectivă, ca să confirme că fixul chiar funcționează și nu a mutat problema în altă parte. La un sistem automat, retestarea costă câteva minute, ceea ce schimbă complet economia procesului.
De ce mai multe rezultate nu înseamnă automat mai multă siguranță
Aici e capcana în care cad multe echipe care cumpără primul instrument cu AI pe care îl găsesc. Volumul de findings crește, sentimentul de productivitate crește, iar securitatea reală rămâne la fel. Pentru că între a descoperi și a repara stă o etapă lungă de validare pe care nimeni nu o vede în materialele de marketing.
Datele din piață confirmă senzația asta. Un studiu realizat în iunie 2026 pe 158 de profesioniști din cybersecurity care folosesc AI în pentesting a arătat că aproape 88% dintre cei care generează findings cu AI se lovesc de rezultate care cer o validare manuală serioasă. Aproximativ unul din patru respondenți spune că trebuie să verifice în amănunt sau să refacă peste un sfert din ce produce sistemul.
Tot acolo apare o cifră care mi s-a părut cea mai elocventă. Întrebate dacă ar putea procesa peste cinci sute de posibile vulnerabilități într-un singur proiect, aproape șapte din zece echipe au spus că ar fi sub presiune considerabilă sau că pur și simplu nu ar reuși. Doar una din cinci are deja un proces pregătit pentru un asemenea volum.
Cu alte cuvinte, blocajul nu mai e la descoperire. S-a mutat la triere, prioritizare și remediere, adică exact acolo unde automatizarea ajută cel mai puțin dacă nu vine cu dovezi. Criteriile după care oamenii aleg astăzi instrumentele reflectă asta, pentru că atât calitatea rezultatelor cât și dovada exploatabilității cântăresc mai greu decât prețul.
Mai există un cost pe care puțini îl calculează, cel al încrederii. Dacă un instrument raportează repetat lucruri care nu se confirmă, echipa începe să verifice cu suspiciune inclusiv rezultatele corecte. Ai plătit pentru mai puțină muncă manuală și ai primit o listă nouă de verificat.
Cum arată abordarea asta într-o companie din România
Nu e o discuție pur teoretică, iar exemplele nu vin doar din Silicon Valley. Pentest-Tools.com dezvoltă AI care găsește vulnerabilități și care, mai important, verifică dacă ele pot fi exploatate înainte de a ajunge în raport. Compania are peste 2.100 de clienți în 119 țări și se apropie de zece ani de creștere organică, ceea ce în domeniul ăsta înseamnă destul de mult.
Produsul lor de testare autonomă, AI Pentests, a fost prezentat public la DEF CON 34, unde compania a fost primul expozant din România. Ideea de bază urmează exact logica descrisă mai sus. Sistemul investighează aplicația în limitele stabilite de utilizator, urmărește posibile trasee de atac și încearcă să confirme problemele găsite, cu un mecanism determinist de verificare peste partea de AI.
Adrian Furtună, fondatorul companiei, spune un lucru care merită reținut, și anume că viteza ajută doar dacă poți avea încredere în rezultatul final. Formularea e simplă, dar rezumă bine diferența dintre un instrument care impresionează la demo și unul cu care poți lucra luni la rând. Filtrarea înainte de raport, nu după, e ceea ce face diferența pentru un tester care nu vrea să-și piardă zilele reverificând.
Detaliul care mi-a plăcut din relatările de la DEF CON e că publicul tehnic nu s-a mulțumit cu eticheta „powered by AI”. Oamenii au întrebat ce modele sunt folosite, cum e construită infrastructura din jur, cum sunt controlate rezultatele. Scepticismul ăsta e sănătos și, cu puțin noroc, va deveni standardul cu care privim toate produsele de securitate.
Unde greșește inteligența artificială și de ce omul rămâne în ecuație
Zona în care sistemele autonome se descurcă cel mai bine este cea repetitivă și standardizabilă. Enumerarea suprafeței de atac, testarea configurațiilor, verificarea versiunilor, căutarea tiparelor cunoscute de injecție. Aici răbdarea unei mașini bate orice om, pentru că nu se plictisește după a treia sută de parametru.
Zona în care se descurcă prost este logica de business. Un model nu știe că în aplicația ta un utilizator cu rol de contabil nu ar trebui să vadă salariile din altă filială, pentru că asta ține de organigrama companiei, nu de cod. Fraudele de logică, adică abuzarea unor funcționalități care funcționează exact cum au fost programate, rămân teritoriul omului.
Mai e o categorie unde prudența e obligatorie. Testarea sistemelor de producție, a infrastructurii critice, a tot ce poate cădea și poate produce pierderi reale. Practicienii folosesc AI mai ales acolo unde pot observa și corecta ușor erorile, și mult mai puțin în etapele care cer gândire critică și interacțiune directă cu sisteme sensibile.
Există și riscul invers, mai puțin discutat. Un agent autonom cu acces la unelte ofensive este, tehnic vorbind, aceeași tehnologie pe care o pot folosi și atacatorii. Diferența stă în autorizare, în limitele impuse și în trasabilitatea acțiunilor, nu în capabilitate. De aceea logarea completă a fiecărui pas nu e un moft de conformitate, ci o necesitate operațională.
Ce poate cere realist o firmă mică sau medie
Dacă ai un magazin online, o aplicație SaaS mică sau un site cu formulare care colectează date personale, nu ai nevoie de un program de securitate cu zece oameni. Ai nevoie de o testare periodică serioasă și de un proces prin care rezultatele ajung efectiv la cineva care le repară. Partea a doua e cea la care majoritatea eșuează.
Un pentest manual clasic la o aplicație web de complexitate medie durează între cinci și zece zile de muncă și costă, în România, câteva mii de euro. Se face o dată sau de două ori pe an, iar între două teste aplicația se schimbă de o sută de ori. Ferestrele de expunere sunt exact acele luni în care nimeni nu se uită.
Aici testarea autonomă schimbă cu adevărat ceva. Poate rula după fiecare release important, poate acoperi zonele repetitive continuu și poate semnala rapid regresiile. Nu înlocuiește pentestul manual anual, dar reduce numărul de surprize pe care le găsește pentesterul uman, care își poate concentra atunci timpul pe lucrurile grele.
Recomandarea mea practică, dacă evaluezi un astfel de instrument, e să ceri să vezi dovezile, nu numărul de findings. Întreabă cum se face validarea, dacă primești cererea exactă care a produs rezultatul, ce procent din findings au proof of concept atașat. Un furnizor care se ferește de întrebările astea îți spune deja destul.
Cum se așază toate astea într-un flux de lucru sănătos
Modelul care funcționează în practică arată cam așa. Testarea automată rulează continuu sau la fiecare schimbare semnificativă, filtrează și validează, iar în raport ajung doar lucrurile susținute cu dovezi. Echipa de securitate primește o listă scurtă, nu un raport de trei sute de pagini pe care îl deschide nimeni.
Peste stratul ăsta stă omul, care preia zonele complexe. Logica de business, lanțurile lungi de atac, evaluarea impactului real asupra companiei, discuția cu dezvoltatorii despre cum se repară corect. Timpul câștigat prin automatizare se investește în judecată, nu în verificat rezultate care ar fi trebuit filtrate din start.
Ultima piesă, cea mai des uitată, e bucla de remediere. Un finding care stă trei luni în backlog nu valorează nimic, oricât de elegant a fost descoperit. Integrarea cu sistemul de ticketing, responsabil desemnat, termen, retestare automată după fix, asta transformă un raport într-o îmbunătățire reală.
Există și un beneficiu secundar la care nu se gândește lumea. Când dezvoltatorii primesc feedback rapid, cu exemple concrete din propriul cod, învață. După câteva luni de astfel de cicluri, tipurile de greșeli se schimbă, iar cele elementare aproape dispar din aplicație.
Ce se schimbă în anii care vin pentru cine trebuie să-și apere aplicația
Direcția e destul de clară, chiar dacă viteza e greu de estimat. Volumul de rezultate va continua să crească, pentru că modelele devin mai bune la găsit, iar suprafața de atac a oricărei companii se lățește cu fiecare integrare nouă. Avantajul competitiv nu va veni din liste mai lungi, ci din capacitatea de a ajunge rapid la cele câteva probleme care chiar contează.
Mă aștept să vedem și o maturizare a limbajului comercial. Eticheta „AI-powered” nu mai impresionează pe nimeni din industrie, iar întrebările devin tot mai tehnice. Ce se validează automat, ce rămâne în sarcina omului, cum se demonstrează exploatabilitatea, ce se întâmplă cu datele testate.
Pentru companiile care trebuie doar să funcționeze, concluzia practică e mai puțin dramatică decât pare. Nu trebuie să devii expert în agenți autonomi ca să beneficiezi de ei, dar trebuie să știi ce să ceri și ce să verifici. Un raport cu dovezi, un proces care duce la reparare și un om care înțelege contextul aplicației tale fac mai mult decât orice tehnologie cumpărată pe repede înainte.
Iar dacă ești în situația de a alege, întreabă-te un singur lucru înainte de a semna. Câte dintre rezultatele pe care le vei primi vor fi lucruri pe care le poți da mâine dimineață unui dezvoltator, cu încrederea că nu îi irosești ziua. Restul, oricât de impresionant sună, e tot praf în ochi.
