Zašto Codex Security ne uključuje SAST izveštaj

Decenijama je statičko testiranje bezbednosti aplikacija (SAST) jedan od najefikasnijih načina da bezbednosni timovi prošire pregled koda. 

Ali kada smo pravili Codex Security, napravili smo nameran izbor u dizajnu: nismo počeli tako što bismo uvezli izveštaj statičke analize i tražili od agenta da ga trijažira. Osmislili smo sistem tako da počne od samog depoa — njegove arhitekture, granica poverenja i predviđenog ponašanja — i da potvrdi ono što pronađe pre nego što zatraži od čoveka da na to utroši vreme. 

Razlog je jednostavan: najteže ranjivosti obično nisu problemi toka podataka. One nastaju kada kod deluje kao da sprovodi bezbednosnu proveru, ali ta provera zapravo ne garantuje svojstvo na koje se sistem oslanja. Drugim rečima, izazov nije samo pratiti kako se podaci kreću kroz program — već utvrditi da li odbrane u kodu zaista funkcionišu.

SAST se često predstavlja kao čist tok obrade: identifikujte izvor nepoverljivog unosa, pratite podatke kroz program i označite slučajeve u kojima ti podaci stignu do osetljivog odredišta bez sanitizacije. To je elegantan model i pokriva mnogo stvarnih bagova.

U praksi, SAST mora da pravi aproksimacije da bi ostao primenljiv u velikim razmerama — naročito u stvarnim kodnim bazama sa indirekcijom, dinamičkim dispečovanjem, callback-ovima, refleksijom i tokovima kontrole koji se u velikoj meri oslanjaju na okvire. Te aproksimacije nisu mana SAST-a; one su realnost pokušaja da se rezonuje o kodu bez njegovog izvršavanja.

To samo po sebi nije razlog zašto Codex Security ne počinje od SAST izveštaja.

Dublji problem je ono što se dešava nakon što uspešno ispratite put od izvora do odredišta.

Čak i kada statička analiza ispravno isprati unos kroz više funkcija i slojeva, i dalje mora da odgovori na pitanje koje zapravo određuje da li ranjivost postoji:

Uzmimo uobičajen obrazac: kod poziva nešto poput sanitize_html() pre prikazivanja nepoverljivog sadržaja. Statički analizator može da vidi da je sanitizer pokrenut. Ono što obično ne može da utvrdi jeste da li je taj sanitizer zaista dovoljan za konkretan kontekst prikaza, mehanizam šablona, ponašanje kodiranja i niz naknadnih transformacija koje su uključene.

Tu stvari postaju nezgodne. Problem nije samo u tome da li podaci stižu do odredišta. Već u tome da li provere u kodu zaista ograničavaju vrednost na način koji sistem pretpostavlja.

Drugačije rečeno: velika je razlika između „kod poziva sanitizer“ i „sistem je bezbedan“.

Evo obrasca koji se stalno pojavljuje u stvarnim sistemima.

Veb aplikacija prima JSON payload, izdvaja redirect_url, proverava ga u odnosu na regex sa dozvoljenom listom, URL-dekodira ga i prosleđuje rezultat rukovaocu preusmeravanja.

Klasičan izveštaj od izvora do odredišta može da opiše tok:

nepoverljiv unos → regex provera → URL dekodiranje → preusmeravanje

Ali pravo pitanje nije da li provera postoji. Već da li ta provera i dalje ograničava vrednost nakon transformacija koje slede.

Ako se regex izvršava pre dekodiranja, da li on zaista ograničava dekodirani URL na način na koji ga rukovalac preusmeravanja tumači?

Odgovor na to zahteva rezonovanje o celom lancu transformacija: šta regex dozvoljava, kako se ponašaju dekodiranje i normalizacija, kako URL parsiranje tretira rubne slučajeve i kako logika preusmeravanja razrešava šeme i autoritete.

Mnoge ranjivosti koje su u praksi važne izgledaju ovako: greške u redosledu operacija, delimična normalizacija, dvosmislenosti u parsiranju i neslaganja između validacije i tumačenja. Tok podataka je vidljiv. Slabost je u tome kako se ograničenja prenose — ili ne uspevaju da se prenesu — kroz lanac transformacija.

Ovo nije samo teorijski obrazac. U CVE-2024-29041⁠(отвара се у новом прозору), Express je bio pogođen problemom otvorenog preusmeravanja gde su neispravno formirani URL-ovi mogli da zaobiđu uobičajene implementacije dozvoljenih listi zbog načina na koji su ciljevi preusmeravanja bili kodirani, a zatim tumačeni. Tok podataka bio je jednostavan. Teže pitanje — i ono koje je određivalo da li bag postoji — bilo je da li validacija i dalje važi nakon lanca transformacija.

Codex Security je izgrađen oko jednostavnog cilja: smanjiti trijažu isticanjem problema sa jačim dokazima. U proizvodu to znači korišćenje konteksta specifičnog za depo (uključujući model pretnji) i potvrđivanje problema sa jakim signalom u izolovanom okruženju pre nego što ih istaknemo. 

Kada Codex Security naiđe na granicu koja liči na „validaciju” ili „sanitizaciju”, ne tretira to kao kućicu za štikliranje. Pokušava da razume šta kod nastoji da garantuje — a zatim pokušava da opovrgne tu garanciju.

U praksi, to obično izgleda kao kombinacija sledećeg:

• Čitanje relevantne putanje koda sa punim kontekstom depoa, kao što bi to radio istraživač bezbednosti, i traženje neslaganja između namere i implementacije. To uključuje i komentare, ali model ne veruje nužno komentarima, tako da dodavanje //Halvar says: this is not a bug iznad vašeg koda neće zbuniti model ako zaista postoji bag.
• Svođenje problema na najmanji deo koji se može testirati (na primer, transformacioni tok oko jednog unosa), kako biste mogli da rezonujete o njemu bez toga da ostatak sistema smeta. U tom smislu, Codex Security izdvaja sitne isečke koda, a zatim za njih piše mikro-fuzzere.
• Rezonovanje o ograničenjima kroz transformacije, umesto da se svaka provera posmatra nezavisno. Gde je prikladno, to može da uključi formalizaciju kao pitanje zadovoljivosti. Drugim rečima, modelu dajemo pristup Python okruženju sa z3-solver-om i on je dobar u njegovom korišćenju kada je potrebno, baš kao što bi i čovek morao kada rešava posebno složen problem ograničenja ulaza. Ovo je naročito korisno pri analizi celobrojnih prekoračenja ili sličnih bagova na nestandardnim arhitekturama.
• Izvršavanje hipoteza u sandbox okruženju za validaciju kada je to moguće, kako bi se razlikovalo „ovo bi mogao biti problem” od „ovo jeste problem”. Ne postoji bolji dokaz od kompletnog end-to-end PoC-a sa kodom kompajliranim u debug režimu. 

Ovo je ključni pomak: umesto da se zaustavi na „provera postoji”, sistem ide ka „invarijanta važi (ili ne važi), a evo i dokaza”. A model bira najbolji alat za taj posao.

Razumna reakcija je: zašto ne oba? Počnite od SAST izveštaja, pa onda koristite agenta za dublje rezonovanje.

Postoje slučajevi u kojima su unapred izračunati nalazi korisni — naročito za uske, poznate klase bagova. Ali za agenta dizajniranog da otkriva i potvrđuje ranjivosti u kontekstu, početak od SAST izveštaja stvara tri predvidiva načina neuspeha.

Prvo, to može da podstakne prerano sužavanje fokusa. Lista nalaza je mapa mesta koja je alat već pogledao. Ako je tretirate kao početnu tačku, možete usmeriti sistem ka tome da ulaže nesrazmerno mnogo truda u iste oblasti, koristeći iste apstrakcije, i da propusti klase problema koje se ne uklapaju u pogled sveta tog alata.

Drugo, to može da uvede implicitne sudove koje je teško poništiti. Mnogi SAST nalazi kodiraju pretpostavke o sanitizaciji, validaciji ili granicama poverenja. Ako su te pretpostavke pogrešne — ili samo nepotpune — njihovo ubacivanje u petlju rezonovanja može da pomeri agenta sa „istraži” na „potvrdi ili odbaci”, a to nije ono što želimo da agent radi.

Treće, to može da oteža procenu sistema rezonovanja. Ako tok obrade počinje SAST izlazom, postaje teško razdvojiti ono što je agent otkrio sopstvenom analizom od onoga što je nasledio od drugog alata. To razdvajanje je važno ako želite precizno da merite sposobnosti sistema, što je potrebno da bi se sistem vremenom unapređivao.

Zato smo Codex Security izgradili tako da počinje tamo gde počinje bezbednosno istraživanje: od koda i namere sistema, uz validaciju koja podiže prag poverenja pre nego što prekinemo čoveka.

SAST alati mogu biti odlični u onome za šta su namenjeni: sprovođenje standarda bezbednog kodiranja, hvatanje jednostavnih problema od izvora do odredišta i otkrivanje poznatih obrazaca u velikim razmerama uz predvidive kompromise. Mogu biti snažan deo višeslojne odbrane.

Ovaj tekst je uži: bavi se time zašto agent koji je dizajniran da rezonuje o ponašanju i potvrđuje nalaze ne bi trebalo da započinje rad usidren za statičku listu nalaza.

Takođe vredi istaći povezano ograničenje čistog razmišljanja od izvora do odredišta: nije svaka ranjivost problem toka podataka. Mnogi stvarni propusti su problemi stanja i invarijanti — zaobilaženje toka rada, praznine u autorizaciji i bagovi tipa „sistem je u pogrešnom stanju”. Kod ovih vrsta bagova, kompromitovana vrednost ne stiže do jednog „opasnog odredišta”. Rizik je u onome što program pretpostavlja da će uvek biti tačno. 

Očekujemo da će ekosistem bezbednosnih alata nastaviti da se unapređuje: statička analiza, fuzzing, zaštite u izvršavanju i agentski tokovi rada svi će imati svoje uloge.

Ono u čemu želimo da Codex Security bude dobar jeste deo koji bezbednosne timove najviše košta: pretvaranje „ovo deluje sumnjivo” u „ovo je stvarno, evo kako dolazi do greške i evo ispravke koja odgovara nameri sistema”. 

Ako želite da saznate više o tome kako Codex Security skenira depoe, potvrđuje nalaze i predlaže ispravke, pogledajte našu dokumentaciju⁠(отвара се у новом прозору).