Proč zabezpečení Codex neobsahuje zprávu SAST?

Po desetiletí bylo statické testování zabezpečení aplikací (SAST) jedním z nejúčinnějších způsobů, jak bezpečnostní týmy provádějí kontrolu kódu. 

Když jsme však vyvíjeli Codex Security, udělali jsme při návrhu záměrné rozhodnutí: nezačali jsme tím, že bychom importovali zprávu ze statické analýzy a požádali agenta, aby ji roztřídil. Systém jsme navrhli tak, aby začínal samotným úložištěm – jeho architekturou, hranicemi důvěry a zamýšleným chováním – a aby ověřil, co zjistí, dříve než požádá člověka, aby tomu věnoval čas. 

Důvod je jednoduchý: nejzávažnější zranitelnosti obvykle nepředstavují problémy s tokem dat. Vznikají tehdy, když se zdá, že kód vynucuje bezpečnostní kontrolu, ale tato kontrola ve skutečnosti nezaručuje vlastnost, na kterou se systém spoléhá. Jinými slovy, výzvou není jen sledovat, jak se data pohybují programem – jde o to určit, zda obranné mechanismy v kódu skutečně fungují.

Proces SAST je často popisován jako čistý postup: najdi zdroj nedůvěryhodného vstupu, sleduj tok dat programem a označ případy, kdy se neošetřená data dostanou do citlivého úložiště. Je to elegantní model a pokrývá spoustu reálných chyb.

V praxi musí SAST provádět aproximace, aby zůstal ve velkém měřítku zvládnutelný – zejména v reálných kódových bázích s nepřímým přístupem, dynamickým odesíláním, zpětnými voláními, reflexí a řídicím tokem náročným na framework. Tyto aproximace nejsou pro SAST žádným problémem; jsou realitou v rámci snahy uvažovat o kódu, aniž by ho bylo nutné spustit.

To samo o sobě není důvod, proč Codex Security nezačíná zprávou SAST.

Hlubší problém spočívá v tom, co se stane poté, co úspěšně vysledujete zdroj k cíli.

I když statická analýza správně sleduje vstup napříč více funkcemi a vrstvami, stále musí odpovídat na otázku, která skutečně určuje, zda zranitelnost existuje:

Vezměme si běžný vzorec: kód před vykreslením nedůvěryhodného obsahu volá něco jako sanitize_html(). Statický analyzátor dokáže rozpoznat, že sanitizace proběhla. Co obvykle nedokáže určit, je, zda je tato sanitizace skutečně dostatečná pro konkrétní kontext vykreslování, engine šablon, chování při kódování a následné zapojené transformace.

A tady se věci komplikují. Problém není jen v tom, zda se data dostanou do úložiště. Jde o to, zda kontroly v kódu skutečně omezují hodnotu způsobem, jaký systém předpokládá.

Jinými slovy: je velký rozdíl mezi „kód volá sanitizér“ a „systém je bezpečný.“

Tento vzorec se v reálných systémech objevuje často.

Webová aplikace přijímá datový obsah ve formátu JSON , extrahuje redirect_url, ověřuje jej vůči regexu povolených hodnot, dekóduje URL a předává výsledek obslužné rutině přesměrování.

Klasická zpráva o zdroji a cíli může popsat tok:

Nedůvěryhodný vstup → kontrola regexem → dekódování URL → přesměrování

Skutečnou otázkou ale není, zda tato kontrola existuje. Jde o to, zda ta kontrola po transformacích, které následují, stále omezuje hodnotu.

Pokud se regulární výraz spustí před dekodováním, omezí to skutečně dekódovanou URL adresu tak, jak ji interpretuje obslužná rutina přesměrování?

Odpověď na to znamená uvažovat o celém transformačním řetězci: co regulární výraz umožňuje, jak se chová dekódování a normalizace, jak parsování URL zachází s okrajovými případy a jak logika přesměrování řeší schémata a autority.

Mnoho zranitelností, které jsou v praxi důležité, vypadá takto: chyby v pořadí operací, částečná normalizace, nejednoznačnosti při analýze a nesoulady mezi validací a interpretací. Tok dat je viditelný. Slabinou je, jak se omezení šíří nebo nešíří transformačním řetězcem.

Nejedná se pouze o teoretický vzorec. V rámci chyby CVE-2024-29041⁠(otevře se v novém okně) byl Express ovlivněn problémem s otevřeným přesměrováním, kdy chybně formátované URL adresy mohly obcházet běžné implementace povolených seznamů kvůli způsobu kódování a následné interpretaci cílů přesměrování. Datový tok byl jednoduchý. Obtížnější otázkou, tou, která rozhodla o tom, zda chyba existovala, bylo, zda validace stále platila i po transformačním řetězci.

Codex Security je postaven na jednoduchém cíli: snížit počet případů třídění odhalením problémů s pomocí silnějších důkazů. V produkčním prostředí to znamená použití kontextu specifického pro daný repozitář (včetně modelu hrozeb) a ověření problémů s vysokou úrovní signálu v izolovaném prostředí před jejich odhalením. 

Když Codex Security narazí na hranici, která vypadá jako „validace“ nebo „sanitizace“, nepovažuje to za něco, co je třeba jen odškrtnout. Snaží se pochopit, co se kód snaží zaručit – a pak se snaží tuto záruku zfalšovat.

V praxi to obvykle vypadá jako kombinace:

• Čtení relevantní kódové cesty s plným kontextem repozitáře, způsobem, jakým by to dělal bezpečnostní výzkumník, a hledání nesouladů mezi záměrem a implementací. To zahrnuje i komentáře, ale model komentářům nutně nevěří, takže pokud k vašemu kódu přidáte //Halvar říká: toto není chyba, tak ho to nepoplete, pokud se tam chyba skutečně nachází.
• Zúžení problému na nejmenší testovatelnou část (například transformační kanál kolem jediného vstupu), abyste o něm mohli uvažovat, aniž by vám překážel zbytek systému. V tomto smyslu Codex Security vybírá malé kousky kódu a poté pro ně píše mikrofuzzery.
• Úvaha o omezeních napříč transformacemi, spíše než samostatné zacházení s každou kontrolou. V případě potřeby to může zahrnovat formalizaci jako otázku splnitelnosti. Jinými slovy, modelu dáváme přístup k prostředí Pythonu se z3-solver a ten ho v případě potřeby dobře používá, stejně jako by to musel dělat člověk při řešení obzvláště složitého problému s omezeními vstupu. Tohle je obzvlášť užitečné při hledání přetečení celých čísel nebo podobných chyb v nestandardních architekturách.
• Pokud je to možné, provádějte hypotézy v uzavřeném validačním prostředí, abyste rozlišili variantu „toto by mohl být problém“ od varianty „toto je problém“. Není lepší důkaz než plnohodnotný end-to-end PoC se zkompilovaným kódem v režimu ladění. 

Toto je klíčový posun: místo aby se systém zastavil na bodě „kontrola existuje“, směřuje k bodu „invariant platí (nebo neplatí) a zde je důkaz“. A model zvolí pro danou práci nejvhodnější nástroj.

Rozumná reakce je: proč neudělat obojí? Začněte se sestavou SAST a poté použijte agenta k hlubšímu uvažování.

Existují případy, kdy jsou předem vypočítané závěry užitečné – zejména pro úzké, známé třídy chyb. Ale pro agenta určeného k objevování a ověřování zranitelností v kontextu vytváří zahájení se zprávou SAST tři předvídatelné možnosti selhání.

Za prvé to může podpořit předčasné zúžení. Seznam nálezů je mapa znázorňující, kam se nástroj již podíval. Pokud to budeš brát jako výchozí bod, můžeš systém vychýlit k tomu, aby vynakládal neúměrné úsilí ve stejných oblastech, používal stejné abstrakce a přehlížel celé třídy problémů, které neodpovídají pohledu nástroje.

Za druhé může zavádět implicitní úsudky, které je obtížné vyvrátit. Mnoho zjištění SAST kóduje předpoklady o sanitizaci, validaci nebo hranicích důvěryhodnosti. Pokud jsou tyto předpoklady chybné – nebo jen neúplné – jejich zařazení do smyčky uvažování může agenta posunout z pozice „zkoumat“ do pozice „potvrdit nebo zamítnout“, což od něj nechceme.

Za třetí, může to ztížit vyhodnocení systému uvažování. Pokud pipeline začíná výstupem SAST, je obtížné oddělit to, co agent objevil vlastní analýzou, od toho, co převzal z jiného nástroje. Toto oddělení je důležité, pokud chcete přesně měřit schopnosti systému, což je nezbytné k tomu, aby se systém postupem času zlepšoval.

Proto jsme vytvořili Codex Security tak, aby začínal tam, kde začíná i bezpečnostní výzkum: u kódu a záměru systému. Ověřování nám pak zvyšuje míru jistoty, než do toho zapojíme člověka.

Nástroje SAST mohou být vynikající v tom, k čemu jsou navrženy: vynucování standardů bezpečného kódování, zachycování zjevných problémů od zdroje až k úložišti a detekování známých vzorů ve velkém měřítku s předvídatelnými kompromisy. Tyto nástroje mohou být účinnou součástí hloubkové obrany.

Tento příspěvek má užší zacílení: jde o to, proč by agent určený k uvažování o chování a ověřování zjištění neměl začínat svou práci na základě statického seznamu zjištění.

Za zmínku stojí také související omezení čistě myšlení „od zdroje k úložišti“: ne každá zranitelnost je problémem s tokem dat. Mnoho skutečných selhání souvisí se stavem systému a porušením invariantů – s obcházením workflow, mezerami v autorizaci a chybami typu „systém je v nesprávném stavu“. U těchto typů chyb se kontaminovaná hodnota nedostane do jediného „nebezpečného cíle“. Riziko spočívá v tom, co program předpokládá, že bude vždy pravdivé. 

Očekáváme, že ekosystém nástrojů pro zabezpečení se bude dál zlepšovat: statická analýza, fuzzing, runtime ochrany a agentní pracovní postupy budou všechny hrát svou roli.

Chceme, aby Codex Security byl dobrý v té části, která bezpečnostní týmy stojí nejvíce: proměnit přístup „tohle vypadá podezřele“ na přístup „tohle je skutečné, tady je návod, jak to selhává, a tady je oprava, která odpovídá záměru systému“. 

Pokud se chceš dozvědět víc o tom, jak Codex Security skenuje úložiště, ověřuje zjištění a navrhuje opravy, podívej se do naší dokumentace⁠(otevře se v novém okně).