Prečo Codex Security neobsahuje správu SAST

Po celé desaťročia bolo statické testovanie bezpečnosti aplikácií (SAST) jedným z najúčinnejších spôsobov, ako bezpečnostné tímy vykonávali kontrolu kódu. 

No keď sme vytvárali Codex Security, urobili sme v návrhu zámernú voľbu – nezačali sme importovaním správy zo statickej analýzy s následným požiadaním agenta, aby ju triedil. Systém sme navrhli tak, aby začínal samotným repozitárom – jeho architektúrou, hranicami dôvery a zamýšľaným správaním – na overenie toho, čo nájde predtým, ako požiada človeka, aby tomu venoval čas. 

Dôvod je jednoduchý: najväčšie zraniteľnosti zvyčajne nie sú problém toku údajov. K zraniteľnostiach dochádza vtedy, keď kód zdanlivo vynucuje bezpečnostnú kontrolu, ale táto kontrola v skutočnosti nezaručuje vlastnosť, na ktorú sa systém spolieha. Inými slovami, výzvou nie je len sledovať, ako sa údaje pohybujú programom, ale ide o určenie toho, či obranné mechanizmy v kóde naozaj fungujú.

SAST sa často rámcuje ako čistý kanál: identifikovať zdroj nedôveryhodného vstupu, sledovať údaje v programe a označiť prípady, keď sa tieto údaje dostanú do citlivého zásobníka bez sanitácie. Je to elegantný model a pokrýva veľa skutočných chýb.

V praxi musí SAST robiť aproximácie, aby zostal zvládnuteľný vo veľkom meradle, najmä v reálnych kódových základniach s nepriamymi odkazmi, dynamickým dispečingom, spätnými volaniami, reflexiou a riadením toku silne závislého od rámcov. Tieto aproximácie nie sú kritikou SAST – sú realitou snahy uvažovať o kóde bez jeho spustenia.

To samo osebe nie je dôvod, prečo Codex Security nezačína SAST správou.

Hlbší problém je, čo sa stane potom, ako úspešne vystopuješ zdroj až k cieľu.

Aj keď statická analýza správne sleduje vstup naprieč viacerými funkciami a vrstvami, stále musí odpovedať na otázku, ktorá v skutočnosti rozhoduje o tom, či zraniteľnosť existuje:

Vezmime si bežný vzor: kód volá niečo ako sanitize_html() pred renderovaním nedôveryhodného obsahu. Statický analyzátor môže vidieť, že sanitizér sa spustil. To, čo zvyčajne nedokáže určiť, je, či je tento sanitizer skutočne dostatočný pre konkrétny kontext renderovania, šablónovací engine, správanie kódovania a následné transformácie, ktoré sú do toho zapojené.

Tu sa veci začínajú komplikovať. Problém nie je len v tom, či sa údaje dostanú na výstup. Ide o to, či kontroly v kóde skutočne obmedzujú hodnotu spôsobom, aký systém predpokladá.

Inak povedané: je veľký rozdiel medzi „kód volá sanitačný nástroj“ a „systém je bezpečný.“

Tu je vzor, ktorý sa v reálnych systémoch objavuje neustále.

Webová aplikácia prijme JSON payload, extrahuje redirect_url, overí ho pomocou regexu zo zoznamu povolených hodnôt, dekóduje URL a výsledok odovzdá handleru presmerovania.

Klasická správa typu source-to-sink môže opísať tok.

nedôveryhodný vstup → kontrola regex → dekódovanie URL → presmerovanie

Otázka však nie je, či kontrola existuje. Ide o to, či táto kontrola stále obmedzuje hodnotu po nasledujúcich transformáciách.

Ak sa regex spustí pred dekódovaním, obmedzuje skutočne dekódovanú URL tak, ako ju interpretuje obslužný modul presmerovania?

Aby sme na to odpovedali, musíme uvažovanie o celom reťazci transformácií: čo regex povoľuje, ako sa správa dekódovanie a normalizácia, ako parsovanie URL spracúva okrajové prípady, a ako logika presmerovania rieši schémy a autority.

Mnohé zraniteľnosti, na ktorých v praxi záleží, vyzerajú takto: chyby v poradí operácií, čiastočná normalizácia, nejednoznačnosti pri parsovaní a nesúlad medzi validáciou a interpretáciou. Tok údajov je viditeľný. Slabina je v tom, ako sa obmedzenia prenášajú alebo neprenášajú cez transformačný reťazec.

Toto nie je len teoretický vzorec. V prípade CVE-2024-29041⁠(otvorí sa v novom okne) bol Express ovplyvnený problémom so zneužiteľným presmerovaním, pri ktorom chybne vytvorené URL adresy mohli obísť bežné implementácie zoznamu povolených položiek, a to kvôli spôsobu, akým boli ciele presmerovania kódované a následne interpretované. Tok údajov bol jednoduchý. Ťažšou otázkou, ktorá určovala, či chyba existovala, bolo, či validácia stále platila po reťazci transformácií.

Codex Security je postavený na jednoduchom cieli: znížiť triedenie tým, že odhalí problémy s presvedčivejšími dôkazmi. V produkte to znamená používať kontext špecifický pre úložisko (vrátane modelu hrozieb) a overovať problémy s vysokou prioritou v izolovanom prostredí pred ich zverejnením. 

Keď Codex Security narazí na hranicu, ktorá vyzerá ako „overovanie“ alebo „sanitizácia“, nepovažuje to za odškrtnuté políčko. Snaží sa pochopiť, akú záruku sa kód snaží poskytnúť – a potom sa snaží túto záruku vyvrátiť.

V praxi to zvyčajne vyzerá ako kombinácia:

• Čítanie relevantnej cesty kódu s úplným kontextom repozitára, tak ako by to robil bezpečnostný výskumník, a hľadanie nezhôd medzi zámerom a implementáciou. To zahŕňa komentáre, ale model nemusí komentárom vždy veriť, takže pridanie //Halvar hovorí: toto nie je chyba nad tvoj kód ho nezmätie, ak tam naozaj chyba je.
• Zúženie problému na najmenší testovateľný výsek (napríklad transformačný proces okolo jedného vstupu), aby sa o ňom dalo uvažovať bez toho, aby ti v tom zavadzal zvyšok systému. V tomto zmysle Codex Security vyberá malé úryvky kódu a potom pre ne píše mikro-fuzzery.
• Uvažovanie o obmedzeniach naprieč transformáciami, namiesto toho, aby sa každá kontrola posudzovala nezávisle. Tam, kde je to vhodné, môže to zahŕňať formalizáciu ako otázku splniteľnosti. Inými slovami, dávame modelu prístup k prostrediu Python so z3-solverom, a model je dobrý v jeho používaní, keď je to potrebné, rovnako ako by to musel robiť človek pri odpovedaní na obzvlášť zložitý problém so vstupnými obmedzeniami. Toto je obzvlášť užitočné pri skúmaní pretečení celých čísel alebo podobných chýb na neštandardných architektúrach.
• Spúšťanie hypotéz v sandboxovom validačnom prostredí, ak je to možné, umožní rozlíšiť „toto by mohol byť problém“ od „toto je problém“. Neexistuje lepší dôkaz než plnohodnotný PoC od začiatku do konca s kódom skompilovaným v režime ladenia. 

Toto je kľúčový posun: namiesto toho, aby sa systém zastavil pri „existuje kontrola“, smeruje k „invariant platí (alebo neplatí), a tu sú dôkazy“. A model si vyberie najlepší nástroj na danú úlohu.

Rozumná reakcia je: prečo neurobiť oboje? Začni so správou SAST a potom použi agenta na hlbšie uvažovanie.

Existujú prípady, keď sú vopred vypočítané zistenia užitočné – najmä pri úzkych, známych triedach chýb. No pre agenta navrhnutého na objavovanie a overovanie zraniteľností v kontexte vytvára začatie zo správy SAST tri predvídateľné režimy zlyhania.

Po prvé, môže to podporovať predčasné zúženie. Zoznam zistení je mapa toho, kde už nástroj hľadal. Ak to budeš považovať za východiskový bod, môžeš systém vychýliť k tomu, aby vynakladal neúmerné úsilie v tých istých oblastiach, používal tie isté abstrakcie a prehliadal triedy problémov, ktoré nezapadajú do svetonázoru nástroja.

Po druhé, môže to vniesť implicitné úsudky, ktoré sa ťažko rozuzľujú. Mnohé zistenia zo statickej analýzy (SAST) obsahujú predpoklady o sanitizácii, validácii alebo hraniciach dôvery. Ak sú tieto predpoklady nesprávne – alebo len neúplné – ich zapojenie do cyklu uvažovania môže agenta prepnúť zo „skúmať“ na „potvrdiť alebo zamietnuť“, a to nechceme.

Po tretie, môže to sťažiť hodnotenie systému uvažovania. Ak sa potrubie začína výstupom SAST, je ťažké oddeliť, čo agent objavil vlastnou analýzou, od toho, čo zdedil z iného nástroja. Toto oddelenie je dôležité, ak chceš presne merať schopnosti systému, čo je potrebné na to, aby sa systém časom zlepšoval.

Preto sme vytvorili Codex Security tak, aby začínal tam, kde začína bezpečnostný výskum – od kódu a zámeru systému. Validáciu používame na zvýšenie miery istoty ešte predtým, než vyrušíme človeka.

Nástroje SAST môžu byť vynikajúce v tom, na čo sú navrhnuté: presadzovanie štandardov bezpečného kódovania, zachytávanie priamočiarych problémov typu source-to-sink a detekcia známych vzorov vo veľkom rozsahu s predvídateľnými kompromismi. Môžu byť silnou súčasťou obrany do hĺbky.

Tento príspevok je zameraný užšie: ide o to, prečo by agent navrhnutý na uvažovanie o správaní a overovanie zistení nemal začať svoju prácu ukotvením v statickom zozname zistení.

Stojí tiež za zmienku súvisiace obmedzenie čisto zdrojovo-spotrebiteľského uvažovania: nie každá zraniteľnosť je problémom toku údajov. Mnohé skutočné zlyhania sú problémy so stavom a invariantmi – obchádzanie pracovných postupov, medzery v autorizácii a chyby typu „systém je v nesprávnom stave“. Pri týchto typoch chýb sa kontaminovaná hodnota nedostane do jediného „nebezpečného zásobníka.” Riziko spočíva v tom, čo program predpokladá, že bude vždy pravdivé. 

Očakávame, že ekosystém nástrojov na zabezpečenie sa bude naďalej zlepšovať: statická analýza, fuzzing, runtime ochrany a agentické pracovné postupy budú zohrávať svoje úlohy.

To, v čom chceme, aby bol Codex Security dobrý, je tá časť, ktorá bezpečnostné tímy stojí najviac: premeniť „toto vyzerá podozrivo“ na „toto je skutočné, tu je, ako to zlyháva, a tu je oprava, ktorá zodpovedá zámeru systému“. 

Ak sa chceš dozvedieť viac o tom, ako Codex Security skenuje repozitáre, overuje zistenia a navrhuje opravy, pozri si našu dokumentáciu⁠(otvorí sa v novom okne).