Pentest traditional vs Pentest automat cu AI

Salut! Noi suntem AISafe Labs, o echipă de cercetători în securitate din Timișoara, și ne petrecem cam tot timpul la granița dintre cele două lumi din titlu: am făcut ani de zile pentest clasic, manual, iar acum construim o platformă care face pentest cu AI. Așa că întrebarea „pentest automat sau pentest clasic?” e pentru noi o discuție pe care o purtăm săptămânal cu clienți, auditori și cu noi înșine.

În 2026, întrebarea a devenit inevitabilă. Agenții LLM au ajuns să găsească vulnerabilități reale în proiecte serioase, iar bugetele de securitate nu au crescut în același ritm cu suprafața de atac. În același timp, piața e plină de instrumente care își spun „AI pentest” dar sunt, la o privire mai atentă, scanere clasice cu un chatbot deasupra. Articolul ăsta pune ordine: ce face bine un pentest clasic, unde te costă, ce schimbă un pentest automat condus de AI și unde ai în continuare nevoie de oameni.

---

Partea pe care mulți furnizori de instrumente automate o trec sub tăcere: un pentester bun e greu de înlocuit, din motive concrete.

Creativitate și intuiție de atacator. Un om cu experiență simte de la distanță locurile unde aplicația ascunde probleme: un mecanism de resetare a parolei scris în grabă, un endpoint de export care arată altfel decât restul API-ului, un parametru care pare să fi supraviețuit unei refactorizări. Vulnerabilitățile spectaculoase ies rar dintr-o listă de verificări; ies din încăpățânarea cuiva care petrece trei ore pe un comportament ciudat.

Context de business. Un pentester înțelege că „un utilizator poate vedea facturile altui utilizator” e catastrofal într-o aplicație bancară și doar neplăcut într-o aplicație internă de pontaj. Severitatea reală a unei vulnerabilități depinde de business, iar oamenii se descurcă (încă) mult mai bine la judecata asta decât orice model.

Acceptare la audit și în contracte. Un raport semnat de o firmă de pentest cu testeri certificați (OSCP, CREST și restul alfabetului) are greutate peste tot. Clienții enterprise îl cer în due diligence, auditorii îl bifează fără discuții, iar în unele industrii reglementate e obligatoriu.

Testare a lanțurilor complexe. Atacurile care combină social engineering, infrastructură și aplicație, cum e un exercițiu complet de red team, rămân teritoriul oamenilor.

Nimic din ce am scris mai sus nu e o caricatură a pentestului clasic: metodologia după care lucrează un pentester serios, de exemplu OWASP Web Security Testing Guide↗, e un standard matur, rafinat de comunitate de peste două decenii. Problema pentestului clasic e costul.

---

Dacă ai comandat vreodată un pentest, cifrele astea îți sună cunoscute:

Pentru bugete, scope și furnizori locali, vezi ghidul Totul despre pentest în România în 2026↗.

Ultimul rând e cel mai subestimat. Un pentest clasic e o fotografie: excelentă ca rezoluție, dar făcută o dată pe an. Dacă echipa ta face deploy zilnic, între două fotografii ai sute de release-uri netestate. Vulnerabilitatea introdusă în februarie stă liniștită în producție până la pentestul din noiembrie. Modelul „point-in-time” avea sens când software-ul se livra trimestrial; cu CI/CD, intervalul dintre teste a devenit cea mai mare gaură din program.

Mai e ceva: fiindcă orele sunt scumpe, pentestul clasic se concentrează aproape mereu pe aplicațiile „importante”. Aplicațiile secundare, API-urile interne și panourile de administrare, exact locurile pe unde intră atacatorii reali, nu prind buget.

---

Distincția de reținut din articolul ăsta: „automat” acoperă două categorii de instrumente care nu au aproape nimic în comun.

Scanerele clasice (Nessus, OpenVAS, ZAP, Burp în modul automat) există de peste douăzeci de ani și lucrează pe bază de reguli: trimit payload-uri cunoscute, caută semnături cunoscute, compară versiuni cu baze de date de CVE-uri. Sunt utile, ieftine și rapide, dar au două limite structurale. Prima: nu înțeleg logica aplicației. Un scaner nu va observa că endpoint-ul /api/invoices/{id} nu verifică dacă factura aparține utilizatorului autentificat, fiindcă pentru asta trebuie să înțelegi ce ar trebui să facă aplicația, nu doar ce face. A doua: nu își validează rezultatele. Scanerul raportează „posibil SQL injection” pe baza unui timing sau a unui mesaj de eroare și îți lasă ție munca de verificare. Rezultatul îl știe oricine a primit un raport de scaner: sute de intrări, majoritatea zgomot, iar echipa învață repede să le ignore, inclusiv pe cele reale.

Pentestul agentic cu AI funcționează altfel. Un agent LLM lucrează ca un pentester: citește aplicația, își construiește un model despre cum funcționează, formulează ipoteze de atac și apoi le verifică prin exploatare efectivă. Diferența în practică:

Când am publicat comparația noastră între un singur prompt generic dat unui coding agent și un audit specializat↗ (articolul e în engleză), exact asta a ieșit la suprafață: un LLM generic cu promptul „fă un security audit” produce rapoarte care seamănă cu ale unui scaner, multe rezultate, puțin impact real. Un sistem agentic construit pentru securitate, care își construiește threat model-ul aplicației și își verifică fiecare ipoteză, produce rapoarte care seamănă cu ale unui pentester. Tehnologia de bază e aceeași; arhitectura din jurul ei face toată diferența.

Deci când evaluezi un „pentest automat”, prima întrebare nu e „folosește AI?”, ci: își demonstrează vulnerabilitățile prin exploatare sau doar le enumeră?

---

Dacă acceptăm că un agent bine construit se apropie de modul de lucru al unui pentester, toată socoteala se schimbă:

Viteză. Un test care ocupa 1–3 săptămâni în calendar rulează în ore, deci poți testa înainte de release, nu la luni după.

Paralelism. Un pentester citește fișierele pe rând. O platformă agentică poate analiza în paralel zeci de zone ale aplicației, cu aceeași atenție pe endpoint-ul obscur de administrare ca pe login. Acoperirea nu mai depinde de orele facturabile.

Retestare continuă. Fotografia devine film. Fiecare release major poate primi propriul test, iar remedierile pot fi verificate imediat, nu la următorul proiect anual. Pentru echipele cu CI/CD, ăsta e câștigul cel mai mare: intervalul dintre introducerea unei vulnerabilități și descoperirea ei se reduce de la luni la zile.

Preț. Când costul marginal al unui test scade cu un ordin de mărime, aplicațiile „care nu prindeau buget” intră și ele sub test, deci acoperi tot portofoliul, nu doar aplicația vedetă.

Consecvență. Un agent nu are zile proaste, nu se plictisește la al patrulea CRUD identic și aplică aceeași rigoare la ora 3 dimineața.

---

Merită o secțiune separată, fiindcă aici pică cele mai multe instrumente automate.

Costul real al unei alarme false e timpul inginerului senior care petrece o jumătate de zi verificând un „critical” care se dovedește teoretic, de trei ori la rând, după care nu mai deschide rapoartele deloc. Un instrument care detectează mult dar validează puțin are valoare negativă: consumă exact resursa pe care trebuia să o economisească, încrederea echipei.

Instrumentul care merită banii rezolvă asta printr-un pas obligatoriu de validare: fiecare posibilă vulnerabilitate e demonstrată prin exploatare într-un mediu izolat înainte să ajungă în raport, iar ce nu se reproduce nu se raportează. Un raport scurt, pe care îl poți pune în practică imediat, valorează mai mult decât unul impresionant ca număr de pagini.

Când evaluezi orice platformă de pentest automat, întreabă explicit: ce procent dintre vulnerabilitățile raportate vine cu proof of concept reproductibil? Răspunsul separă scanerele costumate în AI de pentestul real.

---

Întrebarea practică pe care o primim cel mai des. Răspunsul cinstit: depinde de framework, iar nuanțele contează.

SOC 2: pentestul nu e o cerință formală↗, dar aproape toți auditorii îl așteaptă ca dovadă a eficacității controalelor. Ce contează pentru auditor e ca testul să acopere sistemele in-scope, să existe un raport cu metodologie clară și dovezi de remediere. Rapoartele generate de platforme automate care documentează metodologia și validarea sunt în general acceptate.

ISO 27001: standardul nu cere explicit pentest↗; cere management al vulnerabilităților tehnice, iar forma o dictează analiza ta de risc. Un program de testare continuă automată e un argument bun la audit, adesea mai bun decât un pentest anual, pentru că demonstrează un proces, nu un eveniment.

PCI DSS: aici regulile se strâng. Cerința 11.4 cere pentesturi interne și externe cel puțin anual↗, după o metodologie recunoscută, executate de un tester calificat și independent față de organizație. Un instrument automat singur nu bifează cerința; te ajută mult între testele anuale, dar testul de conformitate rămâne al oamenilor calificați.

Sectoare reglementate (financiar-bancar): schemele de tip threat-led penetration testing, CBEST în Marea Britanie sau TIBER-EU în Europa, cer explicit furnizori acreditați↗, cu echipe de red team formate din oameni certificați. Aici automatizarea rămâne un complement și probabil va rămâne așa o vreme.

Concluzia pragmatică: pentru SOC 2 și ISO 27001, un pentest automat cu vulnerabilități validate și raport serios trece în majoritatea cazurilor. Pentru PCI DSS și sectoarele reglementate, planifică în continuare testul uman certificat și folosește automatizarea pentru tot ce se întâmplă între două audituri.

---

Am fi ipocriți să pretindem altceva: există zone în care agenții AI, inclusiv ai noștri, nu înlocuiesc încă un om bun.

• Lanțuri de atac multi-sistem: escaladări care traversează aplicație, cloud, Active Directory și un om care dă click pe un link. Red teaming-ul complet rămâne uman.
• Severitate dependentă de business: agentul poate spune „un manager poate aproba propriile cereri”; doar cineva care înțelege compania poate spune dacă asta e o problemă de fraudă de milioane sau un detaliu acceptat.
• Clase de bug-uri exotice: race conditions subtile, atacuri criptografice noi, hardware, protocoale proprietare nedocumentate.
• Conversația cu auditorii și avocații: un raport îl susțin oamenii.
• Decizia finală: chiar și cu validare automată, alegerea între „acceptăm riscul” și „reparăm acum” e a echipei tale.

Modelul mental corect e „AI schimbă ce merită să facă pentesterul”: mai puțin timp pe enumerarea metodică a sute de endpoint-uri, mai mult pe atacurile creative pe care nicio mașină nu le încearcă încă.

---

Noi construim AISafe exact pe linia de demarcație descrisă mai sus. Rulăm audituri de cod sursă white-box și pentesturi black-box și white-box cu agenți care lucrează în paralel pe toată suprafața aplicației, iar între detecție și raport am pus un pas obligatoriu de exploatare: agentul reproduce vulnerabilitatea într-un mediu izolat și, dacă nu poate demonstra impactul, ipoteza nu ajunge în raport. În benchmarkul nostru pe Gokapi asta a însemnat nouă vulnerabilități cu impact direct și zero alarme false. Livrăm pași de reproducere, severitate justificată și rezumat executiv, plus review de securitate pe fiecare Pull Request față de modelul de amenințări construit la audit și monitorizare continuă a endpointurilor și permisiunilor descoperite acolo. Rezultatele vin în ore, deci poți rula la fiecare lansare de versiune.

Ce am enumerat mai sus la capitolul oameni rămâne valabil și pentru agenții noștri: judecata de context de business (dacă „un manager își poate aproba propriile cereri” înseamnă fraudă de milioane sau un detaliu acceptat de ani de zile), munca criptografică și de protocol nouă, lanțurile complete de red team care includ social engineering și decizia finală între „acceptăm riscul” și „reparăm acum”. Ce intră în planul gratuit și cât costă restul găsești pe pagina de prețuri↗.

---

Răspunsul scurt: pentru aproape toată lumea, combinația, dar cu ponderi foarte diferite față de acum cinci ani.

Greșeala pe care o vedem cel mai des e menținerea unui model din altă epocă: un singur pentest anual pe o singură aplicație, într-o companie care face deploy de zece ori pe zi pe cincisprezece servicii. Oricât de bun ar fi pentesterul, matematica nu iese.

Iar dacă evaluezi instrumente, revino la cele două întrebări din articol: înțelege instrumentul logica aplicației sau doar aplică reguli? Și își validează vulnerabilitățile prin exploatare sau îți pasează ție triajul? Restul, oricât AI ar scrie pe cutie, e detaliu.