De ce Codex Security nu include un raport SAST

De zeci de ani, testarea statică a securității aplicațiilor (SAST) a fost una dintre cele mai eficiente modalități prin care echipele de securitate pot scala revizuirea codului. 

Însă, atunci când am creat Codex Security, am făcut o alegere de proiectare deliberată: nu am început prin a importa un raport de analiză statică și a-i cere agentului să-l trieze. Am conceput sistemul astfel încât să înceapă cu depozitul în sine: arhitectura sa, limitele de încredere și comportamentul preconizat și să valideze ceea ce găsește înainte de a-i cere unei persoane să-și consume timpul în acest fel. 

Motivul este simplu: cele mai dificile vulnerabilități, de obicei, nu sunt probleme de fluxuri de date. Acestea se întâmplă atunci când codul pare să impună o verificare de securitate, dar acea verificare nu garantează de fapt proprietatea pe care se bazează sistemul. Cu alte cuvinte, provocarea nu constă doar în urmărirea modului în care datele se deplasează printr-un program, ci în a determina dacă mecanismele de apărare din cod chiar funcționează.

SAST este adesea prezentat ca un canal bine definit: identifică o sursă de intrare nesigură, urmărește datele prin program și semnalează cazurile în care acele date ajung la un punct sensibil fără a fi igienizate. Este un model elegant și acoperă o mulțime de buguri reale.

În practică, SAST trebuie să facă aproximări pentru a rămâne gestionabil la scară largă, mai ales în baze de cod reale, cu indirecție, dispecerizare dinamică, apelări inverse, reflecție și flux de control complex influențat de frameworkuri. Aceste aproximări nu sunt o critică la adresa SAST, ci reflectă realitatea încercării de a analiza codul fără a-l executa.

Acesta, în sine, nu este motivul pentru care Codex Security nu începe cu un raport SAST.

Problema fundamentală este ce se întâmplă după ce reușești să urmărești sursa până la destinație.

Chiar și atunci când analiza statică urmărește corect intrarea prin mai multe funcții și straturi, tot trebuie să răspunzi la întrebarea care determină de fapt dacă există o vulnerabilitate:

Să luăm un model comun: codul apelează ceva de genul sanitize_html() înainte de a reda conținut nesigur. Un analizor static poate vedea că mecanismul de igienizare a rulat. Ceea ce nu poate stabili, de obicei, este dacă acel mecanism de igienizare este suficient pentru contextul specific de redare, motorul de șabloane, comportamentul de codificare și transformările ulterioare implicate.

Aici lucrurile devin complicate. Problema nu constă doar în faptul dacă datele ajung la o destinație. Important este dacă verificările din cod limitează efectiv valoarea așa cum presupune sistemul.

Altfel spus: există o mare diferență între „codul apelează un mecanism de igienizare” și „sistemul este sigur.”

Iată un model care apare tot timpul în sistemele reale.

O aplicație web primește o sarcină utilă JSON, extrage un redirect_url, îl validează în funcție de un regex din lista de permisiuni, îl decodează din URL și transmite rezultatul către un handler de redirecționare.

Un raport clasic sursă-destinație poate descrie fluxul:

intrare nesigură → verificare regex → decodare URL → redirecționare

Dar adevărata întrebare nu este dacă verificarea există. Ci dacă acea verificare va continua să constrângă valoarea după transformările care urmează.

Dacă regexul rulează înainte de decodare, constrânge efectiv URL-ul decodat așa cum interpretează handlerul de redirecționare?

Pentru a răspunde la această întrebare, este necesar un raționament asupra întregului lanț de transformare: ce permite acel regex, cum funcționează decodarea și normalizarea, cum gestionează analizarea URL-urilor cazurile limită și cum rezolvă logica de redirecționare schemele și autoritățile.

Multe dintre vulnerabilitățile care contează în practică se prezintă astfel: erori legate de ordinea operațiilor, normalizare parțială, ambiguități de analiză sintactică și neconcordanțe între validare și interpretare. Fluxul de date este vizibil. Slăbiciunea constă în modul în care constrângerile se propagă sau nu de-a lungul lanțului de transformare.

Acesta nu este doar un model teoretic. În CVE-2024-29041⁠(se deschide într-o fereastră nouă), Express a fost afectat de o problemă de redirecționare deschisă, în care URL-urile incorecte puteau ocoli implementările comune ale listelor de permisiuni din cauza modului în care țintele de redirecționare erau codificate și apoi interpretate. Fluxul de date era simplu. Întrebarea cea mai dificilă, și cea care a stabilit dacă eroarea exista, a fost dacă validarea mai era valabilă și după lanțul de transformare.

Codex Security este construit în jurul unui obiectiv simplu: reducerea triajului prin scoaterea la iveală a problemelor cu dovezi mai solide. În produs, asta înseamnă utilizarea unui context specific depozitului (inclusiv un model de amenințări) și validarea problemelor cu semnal puternic într-un mediu izolat înainte de a le scoate la iveală. 

Când Codex Security întâlnește o limită care seamănă cu o „validare” sau o „igienizare”, nu o tratează ca pe o casetă de selectare. Încearcă să înțeleagă ce anume încearcă să garanteze codul, iar apoi încearcă să infirme acea garanție.

În practică, asta tinde să arate ca un amestec dintre:

• Citirea căii de cod relevante cu contextul complet al depozitului, așa cum ar face-o un cercetător în securitate, și căutarea neconcordanțelor dintre intenție și implementare. Aceasta include comentariile, dar modelul nu crede neapărat comentariile, așa că adăugarea //Halvar spune: acesta nu este un bug deasupra codului nu îl derutează, dacă există într-adevăr un bug.
• Reducerea problemei la cea mai mică porțiune care poate fi testată (de exemplu, canalul de transformare aferent unei singure intrări), astfel încât să o poți analiza fără ca restul sistemului să constituie un obstacol. În acest sens, Codex Security extrage mici porțiuni de cod și apoi scrie micro-fuzzere pentru ele.
• Efectuarea unui raționament privind constrângerile la nivelul transformărilor, în loc de a trata fiecare verificare în mod independent. Acolo unde este cazul, acest lucru poate include formularea sub forma unei întrebări de fezabilitate. Cu alte cuvinte, îi oferim modelului acces la un mediu Python cu z3-solver, iar acesta știe să îl folosească atunci când este necesar, exact așa cum ar face un om atunci când trebuie să rezolve o problemă de constrângeri de intrare deosebit de complicată. Acest lucru este util în special pentru a vizualiza depășirile de numere întregi sau buguri similare din arhitecturi non-standard.
• Testarea ipotezelor într-un mediu de validare sandbox, atunci când este posibil, pentru a face distincția între „asta ar putea fi o problemă” și „asta este o problemă”. Nu există o dovadă mai bună decât un PoC complet, de la început până la sfârșit, cu codul compilat în modul de depanare. 

Aceasta este schimbarea esențială: în loc să se oprească la „există o verificare”, sistemul merge mai departe până la „invarianta este valabilă (sau nu), și iată dovada” Și modelul alege cel mai bun instrument pentru acea sarcină.

O reacție rezonabilă este: de ce să nu le facem pe ambele? Să începem cu un raport SAST, apoi să folosim agentul pentru un raționament mai aprofundat.

Există cazuri în care rezultatele precalculate sunt utile, în special pentru clase de buguri cunoscute și restrânse. Dar pentru un agent conceput să descopere și să valideze vulnerabilități în context, pornirea de la un raport SAST creează trei moduri de eșec previzibile.

În primul rând, poate încuraja restrângerea prematură. O listă de rezultate este o hartă a locurilor unde a fost deja căutat un instrument. Dacă o tratezi ca punct de plecare, poți determina sistemul să depună un efort disproporționat în aceleași regiuni, folosind aceleași abstractizări și ratând clase de probleme care nu se potrivesc viziunii generale a instrumentului.

În al doilea rând, poate introduce judecăți implicite care sunt greu de anulat. Multe rezultate SAST codifică presupuneri despre igienizare, validare sau limite de încredere. Dacă aceste presupuneri sunt greșite — sau doar incomplete — introducerea lor în bucla de raţionament poate determina agentul să treacă de la „investigare” în „confirmare sau respingere”, ceea ce nu este ceea ce vrem ca agentul să facă.

În al treilea rând, poate face mai dificilă evaluarea sistemului de raţionament. Dacă rezultatul SAST se află la începutul canalului, devine dificil de separat ceea ce agentul a descoperit prin propria analiză de ceea ce a preluat de la un alt instrument. Acea separare este importantă dacă vrei să măsori cu acuratețe capacitățile sistemului, ceea ce este necesar pentru ca sistemul să se îmbunătățească în timp.

Așadar, am creat Codex Security pentru a porni de acolo de unde începe cercetarea în domeniul securității: de la cod și de la intenția sistemului, folosind validarea pentru a ridica nivelul de încredere înainte de a interveni manual.

Instrumentele SAST pot fi excelente la ceea ce sunt concepute să facă: impunerea standardelor de programare sigură, identificarea problemelor simple de la sursă la destinație și detectarea modelelor cunoscute la scară, cu compromisuri previzibile. Ele pot reprezenta o componentă puternică a apărării aprofundate.

Această postare abordează o temă mai restrânsă: se referă la motivul pentru care un agent conceput să efectueze un raționament asupra comportamentului și să valideze rezultatele nu ar trebui să-și înceapă activitatea pornind de la o listă statică de rezultate.

De asemenea, merită menționată o limitare conexă a gândirii pure de la sursă la destinație: nu orice vulnerabilitate este o problemă de flux de date. Multe eșecuri reale sunt probleme legate de starea sistemului și de invarianță — ocoliri ale fluxului de lucru, lacune de autorizare și buguri de tipul „sistemul se află într-o stare incorectă”. În cazul acestor tipuri de buguri, o valoare coruptă nu ajunge la nicio „destinație periculoasă”. Riscul constă în ceea ce programul presupune că va fi întotdeauna adevărat. 

Ne așteptăm ca ecosistemul de instrumente de securitate să continue să se îmbunătățească: analiza statică, fuzzingul, mecanismele de protecție la rulare și fluxurile de lucru agentice vor avea toate un rol important.

Ceea ce ne dorim de la Codex Security este să exceleze în aspectul care implică cele mai mari costuri pentru echipele de securitate: transformarea unei situații de genul „asta pare suspect” într-una de genul „asta e o problemă reală, iată cum se manifestă și iată o soluție care respectă intenția sistemului”.  

Dacă vrei să afli mai multe despre cum scanează Codex Security depozitele, validează rezultatele și propune remedieri, consultă documentația noastră⁠(se deschide într-o fereastră nouă).