Valul de rapoarte generate cu AI a schimbat economia bug bounty-ului. Programele nu se retrag pentru că nu mai există vulnerabilități, ci pentru că timpul maintainerilor se duce pe rapoarte care nu pot fi reproduse. Concluzia practică pentru oricine învață securitate în 2026: valoarea nu stă în a produce un raport, ci în a produce o dovadă pe care altcineva o poate verifica în câteva minute.

Contextul e concret. Într-un material semnat de BleepingComputer și sponsorizat de TryHackMe, From Beginner to Bug Hunter: Learning Cybersecurity in the AI Era, se arată că uneltele AI au ieftinit dramatic generarea de rapoarte, dar nu au rezolvat problema validării lor. curl, instrumentul de transfer folosit de milioane de servere, și-a oprit programul plătit pe 31 ianuarie 2026, după ce calitatea submisiilor a scăzut: proporția vulnerabilităților confirmate a coborât sub 5% începând cu 2025, față de peste 15% în anii anteriori. În total, programul găsise 87 de vulnerabilități confirmate și plătise peste 100.000 de dolari.

Asta e miezul discuției. Nu AI-ul a stricat bug bounty-ul, ci lipsa de rigoare în raportare. Un model poate genera un text convingător despre o vulnerabilitate imaginară în câteva secunde. Un maintainer trebuie să reproducă fiecare submisie, să verifice impactul, să evalueze eligibilitatea. Când raportul e fals, costul nu e zero: e timpul pe care echipa mică de securitate nu îl mai petrece pe probleme reale.

De ce programele se retrag, de fapt

Merită separată cauza de efect. Bug bounty-ul plătește findings eligibile conform unor reguli scrise. Fiecare submisie trebuie revizuită, reprodusă și evaluată. Volumul de rapoarte superficiale consumă exact resursa cea mai rară într-un proiect open source: atenția maintainerului.

Cifrele din material descriu experiența curl, nu o tendință globală. La fel stau lucrurile și în cazul Google: pauza anunțată are un scop definit, submisiile legate de supply chain și rapoartele deja deschise rămân neafectate, iar programele mai largi de recompensare au plătit cercetătorilor 17,1 milioane de dolari în 2025. Adică presiune pe programe punctuale, nu dispariția oportunităților.

Există și o revenire. În aprilie, Daniel Stenberg a raportat că proporția vulnerabilităților confirmate a urcat la aproximativ 15% - 16%. Cercetătorii găseau probleme reale, iar AI-ul era folosit pe scară largă în acele rapoarte. Lecția nu e "AI rău" sau "AI bun", ci că instrumentul funcționează atunci când omul din spate își asumă proba.

Pentru un marketer sau antreprenor care citește asta și se întreabă ce legătură are cu el, legătura e directă. Aceeași economie a rapoartelor neverificabile apare în auditurile de reclame, în rapoartele de SEO generate automat și în dashboard-urile care arată cifre fără să explice de unde vin. Cine produce dovezi reproductibile câștigă încredere; cine produce volum produce zgomot.

Ce înseamnă un finding verificabil

Un raport util nu e o poveste, e o rețetă. Materialul sursă propune o structură simplă, care se aplică dincolo de securitate:

Diferența dintre "am găsit o problemă" și "uite cum o reproduce oricine în trei pași, cu două conturi de test" e diferența dintre un raport care se închide și unul care se plătește. Exemplul din material e clar: dacă schimbi un identificator de factură și primești un răspuns de succes, asta nu dovedește încă o problemă de control al accesului. Trebuie să arăți că un cont poate accesa factura privată a altui cont și că asta încalcă permisiunile intenționate ale aplicației.

Aici intervine disciplina de măsurare pe care o aplicăm în agenție la audituri: distingem constatarea măsurată de ipoteză și de recomandare. O verificare incompletă nu dovedește absența unei funcții. Un scan automat care nu găsește nimic nu înseamnă că nu există nimic. Iar un raport automat care "găsește" tot nu înseamnă că ai dovezi. Ambele extreme sunt la fel de costisitoare.

Cum arată un prim drum de învățare, fără hype

Materialul propune un plan de patru săptămâni, structurat pe ce poți explica și repeta, nu pe câte tool-uri ai deschis. E o abordare sănătoasă, pentru că mută focusul de la output la competență.

În prima săptămână, bazele: rețelistică, sisteme de operare, funcționarea web. Desenezi un flux simplu de request și explici unde se verifică identitatea și permisiunile. În a doua, alegi un singur tip de vulnerabilitate și îl exersezi în laboratoare autorizate, cu notițe scurte despre dovezile fiecărui rezultat. În a treia, folosești AI-ul pentru indicii după ce ai încercat singur, apoi revii la un laborator anterior fără ajutor și te uiți la logurile pe care un apărător le-ar folosi pentru a detecta activitatea. În a patra, scrii un raport complet și rogi un coleg să îl reproducă din instrucțiunile tale, sau îl urmezi tu de la zero și repari ce lipsește.

Ce mi se pare cel mai valoros în acest plan e ultimul pas. Reproducerea de către altcineva e testul cel mai dur și cel mai ieftin pe care îl poți face singur. Dacă un om care nu a văzut laboratorul tău ajunge la același rezultat urmând notele tale, ai un finding. Dacă nu, ai un draft.

Un detaliu pe care materialul îl atinge corect: AI-ul e util pentru a explica o eroare nefamiliară, a sugera întrebări de investigat sau a-ți verifica claritatea notițelor. Randamentul crește când îi dai un punct specific de confuzie, după ce ai încercat singur. "Explică-mi cum se leagă cookie-ul de sesiune de contul logat" e o întrebare bună. "Analizează tot și spune-mi ce e vulnerabil" e o pierdere de timp.

Limitele pe care nimeni nu le spune destul de tare

Trei lucruri se pierd des în discuția despre AI și securitate.

Primul: plata depinde de validitate, eligibilitate și regulile programului. Un finding real, dar în afara scopului, nu se plătește. Un finding valid, dar duplicat, nu se plătește. Un finding care presupune un impact nedemonstrat nu se plătește.

Al doilea: un program care se închide nu înseamnă că domeniul moare. Închiderile descrise în material au scopuri definite și coexistă cu programe care plătesc sume record. Generalizarea de la curl la "bug bounty-ul e mort" e exact tipul de concluzie pe care o ia un model dintr-un titlu, nu un operator dintr-un raport.

Al treilea: abilitățile se transferă. Aceeași rigoare în verificarea dovezilor contează în securitate operațională, în răspuns la incidente și în testare de penetrare. Iar dincolo de securitate, în orice rol în care cineva ia decizii pe baza unor rapoarte: marketing, produs, analytics.

Ce înseamnă pentru tine, ca antreprenor sau marketer român

Dacă ai un site de e-commerce sau o afacere cu trafic, discuția asta te privește pe trei planuri concrete.

Rapoartele pe care le primești. Tot mai multe "audituri de securitate" și "audituri SEO" vin generate de unelte AI, cu liste lungi de probleme și zero pași de reproducere. Tratează-le ca pe submisiile de calitate îndoielnică: cere dovada. Care e URL-ul exact, care e requestul, care e captura, care e pasul de verificare. Un furnizor care nu poate arăta proba nu are un finding, are o presupunere.

Volumul nu e progres. În bug bounty, mai multe rapoarte au însemnat mai puțină valoare pe raport. În marketing, mai multe reclame paid social nu rezolvă problema de creativ, iar mai multe emailuri nu rezolvă problema de ofertă. Indicatorul care contează e rata la care ceva se confirmă, nu câte încercări ai făcut. Pentru perspectiva pe paid social, vezi de ce volumul de reclame nu rezolvă creativul.

Controlul accesului, inclusiv la tine în platformă. Multe incidente încep cu permisiuni prea largi: un cont de colaborator cu acces la tot, un API key uitat într-un script, un dashboard public. Nu e nevoie de un exploit sofisticat. E nevoie de cineva care verifică cine are acces la ce și dacă asta e intenționat. Aici intră și discuția despre agenții AI care primesc acces la date reale, subiect pe care îl analizăm în materialul despre Shopify și agentul AI al clientului care ia comision pe vânzări. Cu cât mai mulți agenți au acces, cu atât mai important e să știi exact ce pot atinge.

Un pas concret pe care îl poți face săptămâna asta, fără buget: deschide lista de utilizatori și integări a platformei tale și notează, pentru fiecare, ce date vede și ce poate face. Marchează ce nu mai e folosit și revocă. Apoi cere, pentru orice raport de audit primit recent, un singur exemplu reproductibil. Dacă îl primești, ai găsit un furnizor serios. Dacă nu, ai economisit timp.

FAQ

Mai merită să încerc bug bounty ca începător în 2026? Da, dacă pornești cu disciplina dovezii. Bariera nu mai e generarea de rapoarte, ci demonstrarea lor. Programele care plătesc au nevoie de findings reproductibile, iar cererea pentru oameni care pot arăta proba rămâne. Închiderile punctuale nu înseamnă dispariția oportunităților.

Pot folosi AI când învăț securitate? Da, cu o regulă simplă: încearcă întâi singur, apoi cere un indiciu punctual pe un loc concret în care te-ai blocat, apoi testează și explică de ce a funcționat. AI-ul e bun la explicații și la verificarea clarității notițelor, nu la substituirea verificării.

Ce diferențiază un raport care se plătește de unul ignorat? Reproductibilitatea. Activ și versiune, pași exacți, permisiuni necesare, comportament așteptat versus rezultat real, dovezi curățate de date sensibile, impact demonstrat și presupuneri marcate explicit. Dacă altcineva poate ajunge la același rezultat urmând instrucțiunile, ai un raport.

Arc: AI ajută, omul decide, agenția execută

AI-ul comprimă timpul de analiză. Poate explica o eroare, poate sugera un plan de testare, poate reformula notițele până devin lizibile. Ce nu poate face e să își asume proba. Verificarea unui finding, decizia dacă merită trimis, judecata dacă un audit raportat e real sau zgomot, toate rămân la om. La fel stă treaba și în marketing: AI-ul strânge datele și propune ipoteze, dar media buyer-ul știe ce e semnal și ce e zgomot, iar decizia de buget se ia pe dovezi, nu pe rapoarte înșelătoare.

Pasul concret îl face ALLSoft Agency. Dacă vrei un audit în care fiecare constatare vine cu proba ei și fiecare recomandare e marcată ca ipoteză, nu ca verdict, scrie-ne pe allsoftagency.ro. Fără hype, fără cifre inventate, doar ce se poate demonstra.