В продължение на десетилетия статичното тестване на сигурността на приложенията (SAST) е един от най-ефективните начини екипите по сигурността да разширят обхвата на прегледа на кода.
Но когато създадохме Codex Security, направихме умишлен избор от гледна точка на разработката: не започнахме с импортиране на отчет от статичен анализ и не помолихме агента да го класифицира. Проектирахме системата да започва със самото хранилище – неговата архитектура, граници на доверие и предвидено поведение – и да проверява това, което открива, преди да помоли човек да отдели време за това.
Причината е проста: най-трудните рискове обикновено не са проблеми с потока на данните. Те възникват, когато кодът изглежда, че прилага проверка за сигурност, но тази проверка всъщност не гарантира свойството, на което системата разчита. С други думи, предизвикателството не е само да се проследи как данните се движат през една програма, а да се определи дали защитите в кода наистина работят.
SAST често се представя като чист поток: засичане на източник на ненадежден вход, проследяване на данните през програмата и маркиране на случаите, в които тези данни достигат чувствителен приемник без пречистване. Това е елегантен модел и обхваща много реални грешки.
На практика SAST трябва да прави предположения, за да остане управляем при мащаб – особено в реални кодови бази с индирекция, динамично пренасочване, обратни извиквания, рефлексия и контролен поток, силно зависим от рамки. Тези предположения не са критика към SAST; те са част на опитите да се разсъждава за код, без той да се изпълнява.
Само по себе си това не е причината Codex Security да не започва със SAST доклад.
По-големият проблем е какво се случва, след като успешно проследите източник до крайна точка.
Дори когато статичният анализ правилно проследява входните данни през множество функции и слоеве, той все пак трябва да отговори на въпроса, който всъщност определя дали съществува уязвимост:
Вземете общ шаблон: кодът извиква нещо като sanitize_html() преди рендиране на ненадеждно съдържание. Статичният анализатор вижда, че функцията за почистване на данни е била извикана. Това, което обикновено не може да определи, е дали този чистач на данни действително е достатъчен за конкретния контекст на рендиране, шаблонния механизъм, кодиращото поведение и включените низходящи трансформации.
Тук нещата стават сложни. Проблемът не е само дали данните достигат до крайна точка. Въпросът е дали проверките в кода действително ограничават стойността по начина, по който системата приема, че го правят.
Казано по друг начин: има голяма разлика между „кодът извиква средство за почистване“ и „системата е безопасна“.
Ето една закономерност, която често се среща в реални системи.
Уеб приложение получава JSON данни, извлича redirect_url, валидира го спрямо списък с позволени regex шаблони, декодира URL адреса и подава резултата на модул за обработка на пренасочвания.
Класически доклад за източник и приемник може да опише потока:
ненадежден вход → проверка с regex → URL декодиране → пренасочване
Но истинският въпрос не е дали проверката съществува. Става въпрос за това дали тази проверка все още ограничава стойността след преобразуванията, които следват.
Ако regex се изпълнява преди декодиране, наистина ли ограничава декодирания URL по начина, по който обработчикът за пренасочване го интерпретира?
Отговорът на това означава структурирано анализиране на цялата верига на трансформация: какво позволява regex, как реагират декодирането и нормализацията, как URL парсингът обработва гранични случаи и как логиката за пренасочване разрешава схеми и авторитети.
Много от рисковете, които са важни на практика, изглеждат така: грешки в реда на операциите, частична нормализация, неясноти при разбор и несъответствия между валидирането и интерпретацията. Вижда се потокът от данни. Пропускът е в това как ограниченията се разпространяват или не успяват да се разпространят по веригата на трансформацията.
Това не е просто теоретична закономерност. В CVE-2024-29041(отваря се в нов прозорец) Express беше засегнат от уязвимост за отворено пренасочване, при която неправилно форматирани URL адреси можеха да заобикалят често срещани приложения на списък с разрешени адреси (allowlist), поради начина, по който целите за пренасочване бяха кодирани и след това интерпретирани. Потокът от данни беше ясен. По-трудният въпрос (и този, който определяше дали грешката съществува) беше дали потвърждението все още важи след веригата от трансформации.
Codex Security е изграден около проста цел: да намали необходимостта от триаж, като разкрива проблеми с по-силни доказателства. В продукта това означава използване на контекст, специфичен за хранилището (включително модел на заплахите), и потвърждаване на проблеми с висок приоритет в изолирана среда, преди да бъдат изведени.
Когато Codex Security срещне граница, която изглежда като „потвърждение“ или „почистване“, той не я третира като отметка. Той се опитва да разбере какво се опитва да гарантира кодът и след това се опитва да опровергае тази гаранция.
На практика това обикновено изглежда като смесица от:
- Прочитане на съответния път на кода с пълен контекст на хранилището, по начина, по който би го направил изследовател по сигурността, и търсене на несъответствия между намерение и реализация. Това включва коментари, но моделът не вярва непременно на коментарите, така че добавянето на //Халвар обяснява, че това не е грешка над кода ви не го обърква, ако наистина има грешка.
- Свеждане на проблема до най-малкия тестван сегмент (например конвейера за преобразуване около единичен вход), за да можете да разсъждавате върху него, без останалата част от системата да пречи. В този смисъл Codex Security извлича малки части от код и след това пише микрофъзери за тях.
- Структурирано анализиране относно ограниченията при трансформации, вместо да се разглежда всяка проверка поотделно. Където е уместно, това може да включва формализиране като въпрос за удовлетворимост. С други думи, предоставяме на модела достъп до Python среда със z3-solver, и той я използва ефективно, когато е необходимо, както би направил човек при решаване на сложен проблем с входни ограничения. Това е особено полезно за разглеждане на препълване на цели числа или подобни бъгове на нестандартни архитектури.
- Изпълнение на хипотези в изолирана среда за проверка, когато е възможно, за да се разграничи „това може да е проблем“ от „това е проблем“. Няма по-добро доказателство от пълен PoC от край до край с кода, компилиран в режим на отстраняване на грешки.
Това е ключовата промяна: вместо да спира на „съществува проверка“, системата се насочва към „константата е в сила (или не е) и ето доказателствата“. И моделът избира най-добрия инструмент за тази задача.
Разумна реакция би била: защо да не направим и двете? Започнете със SAST отчет, след това използвайте агента, за да разсъждавате по-задълбочено.
Има случаи, когато предварително изчислените констатациите са полезни, особено за тесни и известни класове грешки. Но за агент, предназначен да открива и валидира уязвимости в контекста, започването с доклад от SAST води до три предвидими режима на отказ.
Първо, това може да насърчи преждевременно стесняване. Списък с констатации е карта на това, къде инструментът вече е търсил. Ако го приемете за отправна точка, можете да наклоните системата към това да полага непропорционално усилие в същите области, да използва същите абстракции и да пропуска цели класове проблеми, които не се вписват в светогледа на инструмента.
Второ, това може да въведе скрити преценки, които е трудно да се разгадаят. Много SAST констатации съдържат предположения за почистване, проверка или граници на доверие. Ако тези предположения са погрешни или просто непълни, подаването им в цикъла за структурирано анализиране може да измести агента от „разследвай“ към „потвърди или отхвърли“, което не е това, което искаме агентът да прави.
Трето, това може да затрудни оценяването на системата за структурирано анализиране. Ако потокът започва с изходни данни от SAST, става трудно да се отдели това, което агентът е открил чрез собствения си анализ, от това, което е наследил от друг инструмент. Това разграничение е важно, ако искате да измервате точно възможностите на системата, което е необходимо, за да може системата да става по-добра с течение на времето.
Затова създадохме Codex Security, за да започнем там, откъдето започват проучванията по сигурността: от кода и намеренията на системата, като използваме потвърждение, за да повишим летвата на увереността, преди да прекъснем човек.
Инструментите за статичен анализ на кода (SAST) могат да бъдат изключително полезни за това, за което са създадени: прилагане на стандарти за сигурно програмиране, идентифициране на ясни проблеми от източник до приемник и откриване на известни модели в голям мащаб с предвидими компромиси. Те могат да бъдат силна част от задълбочената защита.
Тази публикация е по-тясно фокусирана: тя разглежда защо агент, проектиран да анализира поведението и да потвърждава резултатите, не трябва да започва работа, обвързана със статичен списък с резултати.
Също така си струва да се отбележи свързано ограничение на чисто мислене от източник към приемник: не всяка уязвимост е проблем на потока от данни. Много реални сривове са проблеми със състоянието и константите – заобикаляне на работния процес, пропуски в оторизацията и грешки от типа „системата е в неправилно състояние“. При тези видове грешки замърсена стойност не достига до нито един „опасен приемник“. Рискът е в това, което програмата приема, че винаги ще бъде вярно.
Очакваме екосистемата от инструменти за сигурност да продължи да се подобрява: статичен анализ, тестване с предоставяне на структуриран текст (fuzzing), защити при изпълнение и агентни работни процеси – всички те имат своята роля.
Това, в което искаме Codex Security да е добър, е частта, която струва най-много на екипите по сигурността: да превръща „това изглежда подозрително“ в „това е реално, ето как се проваля и ето корекция, която съответства на предназначението на системата“.
Ако желаете да научите повече за начина, по който Codex Security сканира хранилищата, валидира откритията и предлага решения, посетете нашата документация(отваря се в нов прозорец).
