Securitatea IA are nevoie de o a doua opinie

IA scrie software mai repede decât îl putem securiza. Reușiți să țineți pasul?

Până terminați de citit această propoziție, dezvoltatorii și agenții lor de IA vor fi trimis câteva mii de modificări de cod. În aceeași perioadă a anului trecut, numărul ar fi fost de aproximativ 150.

În ultimul an, dezvoltarea de software generat de IA a accelerat până la niveluri uimitoare. GitHub a înregistrat 7,38 miliarde de modificări de cod numai în septembrie 2026, de peste cinci ori mai multe decât în aceeași perioadă a anului precedent. Implicațiile de securitate ale acestei explozii sunt profunde. Fiecare dintre aceste modificări conține cod pe care cineva ar trebui să îl înțeleagă, să îl întrețină și să îl securizeze. Cloud Security Alliance a constatat că dezvoltatorii care folosesc IA în companii din Fortune 50 trimit cod într-un ritm de trei până la patru ori mai mare decât colegii lor, în timp ce numărul constatărilor de securitate lunare a crescut de aproximativ zece ori.

Acum, să ne gândim cine preia această creștere a volumului de muncă. Echipa CISO are același număr de membri ca în urmă cu un an, dar restanțele nu au rămas la fel. Numărul vulnerabilităților raportate crește, cel al remedierilor lunare scade, iar vulnerabilitățile critice nerezolvate se înmulțesc. Nu e de mirare că Gartner afirmă că epuizarea profesională a CISO devine un risc operațional critic.

Tentația celui mai nou model

Când cifra este atât de mare, instinctul este să urmărim o cifră și mai mare: mai multe constatări, o acoperire mai amplă, mai multe scanări. Dar e ca și cum ai scoate apa dintr-o barcă ce se scufundă și ai cere o găleată mai mare, când de fapt trebuie să găsești spărtura. Un program de securitate nu se măsoară prin volumul constatărilor. Se măsoară prin proporția constatărilor reale și prin câte dintre cele mai critice sunt remediate efectiv.

Modelele de IA de ultimă generație sunt remarcabile în identificarea exploatărilor inedite și a vulnerabilităților necatalogate, folosind raționamentul probabilistic. Însă rezultatele variază. Potrivit cercetărilor Checkmarx, dacă rulați aceeași scanare asupra aceluiași cod de cinci ori, constatările coincid doar în aproximativ o treime dintre cazuri.

Tocmai această inconsecvență face ca analiza bazată pe reguli să rămână importantă. Este mai puțin flexibilă decât IA de ultimă generație, dar aplică de fiecare dată aceeași logică verificată, astfel încât echipele să poată avea încredere în rezultate și să le verifice. IA detectează ceea ce regulile nu observă, de exemplu vulnerabilități cunoscute în forme neobișnuite sau defecte care devin exploatabile numai când interacționează componente separate ale codului. Împreună, IA și analiza bazată pe reguli scot la iveală mai multe probleme importante, cu mai puține alarme false.

Nimic din toate acestea nu este un argument împotriva IA. Este un argument în favoarea unei a doua opinii în materie de securitate. Indiferent ce motor alegeți, evaluați-l cu ajutorul a trei întrebări.

Prima întrebare: fidelitatea

Când scanerul semnalează o problemă, merită să vă ocupați de ea?

Fidelitatea înseamnă încredere. O constatare care nu corespunde unei probleme reale îi costă pe dezvoltatori o după-amiază și erodează și mai mult credibilitatea echipei de securitate. La scară largă, alarmele false îi fac pe oameni să nu mai asculte. Alertele ajung să fie doar un „strigăt «lupul»” și se pierd în zgomotul de fond.

Aici contează consecvența. Analiza deterministă oferă întotdeauna același răspuns pentru același cod, ceea ce consolidează încrederea și permite auditarea rezultatelor.

A doua întrebare: acuratețea

Identificați toate problemele relevante, în special pe cele mai importante?

Fidelitatea vă arată dacă o constatare merită atenția dumneavoastră, dar nu vă spune ce probleme a omis scanerul. Folosim o măsură practică, provenită din știința datelor, numită scor F1. Scorul F1 evaluează performanța pe o scară de la 1 la 0, pe baza a doi factori:

• Precizia: proporția constatărilor raportate care corespund unor probleme reale. O precizie ridicată înseamnă mai puține alarme false.
• Rata de detectare: proporția vulnerabilităților reale pe care scanerul le identifică efectiv. O rată de detectare ridicată înseamnă că puține probleme trec neobservate.

Un scaner poate părea precis dacă semnalează aproape nimic sau temeinic dacă semnalează totul, dar în ambele cazuri scorul F1 poate fi scăzut. Media industriei este de aproximativ 0,20. Am depus eforturi susținute pentru a rezolva această problemă și am obținut rezultate cu o acuratețe de trei până la patru ori mai mare decât cea a unui scaner obișnuit.

O acuratețe mai bună ușurează toate etapele ulterioare pentru dezvoltatori. Echipa dumneavoastră petrece mai puțin timp verificând constatările și mai mult timp remediind problemele.

A treia întrebare: rentabilitatea investiției (ROI)

Cum putem maximiza investițiile și resursele?

Aceasta este întrebarea cel mai adesea ignorată în etapa-pilot și cea la care răspunsul este cel mai dureros în producție.

Modelele de ultimă generație facturează în funcție de numărul de tokenuri, iar tokenurile sunt consumate indiferent dacă o scanare identifică sau nu ceva. La prețurile publicate în prezent, scanarea unui depozit de cod cu un milion de linii costă peste o mie de dolari. Diferențele dintre modelele de utilizare a tokenurilor sunt mari; prețul variază în funcție de modelul ales și de cât raționament este necesar pentru a finaliza sarcina.

Înmulțiți aceste costuri pentru fiecare modificare de cod, cerere de integrare și depozit dintr-o companie mare. Uber, care cheltuiește 3,4 miliarde de dolari pe an pentru cercetare și dezvoltare (R&D), și-ar fi epuizat întregul buget pentru IA pe 2026 în câteva luni de la introducerea instrumentelor de programare bazate pe IA.

Numim acest lucru taxa pe tokenuri. E ca și cum ai lua un Ferrari ca să cumperi câteva lucruri de la magazin: plătești pentru o putere de care deplasarea nu are nevoie. Credențialele hardcodate și injecția SQL sunt tipare previzibile, pe care analiza deterministă le identifică în mod fiabil.

Securitatea aplicațiilor trebuie să evolueze

Acesta este raționamentul din spatele arhitecturii Checkmarx Fusion. Motoarele bazate pe reguli stabilesc adevărul de referință în mod reproductibil și la un cost mai mic decât analiza bazată pe tokenuri. Modelele de frontieră se ocupă de ceea ce regulile nu pot anticipa: tipare noi, logică complexă și posibilitatea exploatării în context. Apoi, un strat de analiză a constatărilor combină rezultatele într-un singur set de încredere.

Analiza deterministă oferă certitudine. AI oferă acoperire. Acoperirea și încrederea cresc împreună. În comparație cu un LLM care lucrează singur, constatăm o fidelitate de până la patru ori mai mare, o acuratețe de două până la patru ori mai mare și un cost de aproximativ o treime.

Identificarea problemelor este doar începutul. Același principiu se aplică și prevenirii. Să luăm un exemplu. Dacă le oferim dezvoltatorilor instrumentele necesare chiar în momentul în care creează codul, în IDE-ul în care îl scriu, putem opri problemele înainte să apară. În mod similar, în cazul vulnerabilităților care totuși trec de verificări, de ce să nu le oferim dezvoltatorilor remedieri gata de integrat prin merge pentru cele mai importante? Acestea sunt provocările pe care le abordăm, cu scopul de a reduce treptat volumul de probleme restante, obținând cel mai rapid impact cu efortul cel mai mic.

Codul este deja în execuție. Poți ține pasul?

AI le-a oferit atacatorilor un avantaj de viteză. Pentru a reduce acest decalaj, nu este suficient să mai adăugăm încă un instrument. Este vorba despre o decizie privind modul în care întreaga organizație dezvoltă și securizează software-ul. Codul scris astăzi va susține activitatea companiei tale ani la rând. Întrebarea pentru liderii din domeniul securității nu mai este cu cât de mult te ajută AI să dezvolți mai rapid, ci dacă programele tale pot ține pasul cu ceea ce creează AI.

Așadar, nu te lăsa copleșit de cifre. Pune-i oricărui program trei întrebări: Pot avea încredere în ceea ce identifică? Identifică suficiente dintre problemele care contează? Este realist să îl implementez în întreaga organizație? Combinarea preciziei deterministe cu raționamentul modelelor de frontieră îți oferă cele mai mari șanse să răspunzi afirmativ la toate trei.

Dezvoltarea software-ului nu încetinește. Acum, sarcina noastră este să reducem decalajul de risc: distanța dintre viteza cu care este creat software-ul și viteza cu care riscurile sunt identificate și remediate.