Неліктен Codex Security SAST есебін қамтымайды

Ондаған жылдар бойы қолданба қауіпсіздігін статикалық тестілеу (SAST) қауіпсіздік командаларына код шолуын ауқымдаудың ең тиімді тәсілдерінің бірі болып келді. 

Бірақ біз Codex Security-ті жасағанда, саналы түрде жобалық таңдау жасадық: статикалық талдау есебін импорттап, агенттен оны триаждауды сұраудан бастаған жоқпыз. Біз жүйені репозиторийдің өзінен—оның архитектурасынан, сенім шекараларынан және көзделген мінез-құлқынан—басталатындай етіп жобаладық және ол адамнан оған уақыт жұмсауды сұрамас бұрын, тапқанын тексеретіндей етіп құрдық. 

Мұның себебі қарапайым: ең қиын осалдықтар әдетте деректер ағыны мәселелері емес. Олар код қауіпсіздік тексеруін орындайтындай көрінгенімен, сол тексеру жүйе сүйенетін қасиетке шын мәнінде кепілдік бермеген кезде пайда болады. Басқаша айтқанда, мәселе тек деректердің бағдарлама ішінде қалай қозғалатынын қадағалауда емес — кодтағы қорғаныстардың шынымен жұмыс істейтінін анықтауда.

SAST көбіне таза конвейер ретінде сипатталады: сенімсіз кіріс көзін анықтау, деректерді бағдарлама арқылы қадағалау және ол деректердің тазартусыз сезімтал қабылдағышқа жететін жағдайларын белгілеу. Бұл — әсем модель, әрі ол көптеген нақты қателерді қамтиды.

Іс жүзінде SAST ауқымда қолдануға қолайлы болып қалу үшін жуықтатулар жасауға мәжбүр — әсіресе жанама сілтемелер, динамикалық диспетчерлеу, callback-тер, reflection және фреймворкке тәуелді басқару ағыны бар нақты код базаларында. Бұл жуықтатулар SAST-қа тағылған мін емес; бұл — кодты орындамай тұрып ол туралы ой қорытуға тырысудың шындығы.

Мұның өзі Codex Security-тің неге SAST есебінен бастамайтынының себебі емес.

Тереңірек мәселе — көзден қабылдағышқа дейінгі жолды сәтті қадағалағаннан кейін не болатынында.

Статикалық талдау кірісті бірнеше функция мен қабат арқылы дұрыс қадағаласа да, ол әлі де осалдық бар-жоғын шын мәнінде анықтайтын сұраққа жауап беруі керек:

Жиі кездесетін үлгіні алайық: код сенімсіз мазмұнды көрсету алдында sanitize_html() тәрізді нәрсені шақырады. Статикалық талдаушы санитайзердің іске қосылғанын көре алады. Бірақ әдетте ол сол санитайзердің нақты көрсету контексті, шаблон қозғалтқышы, кодтау мінез-құлқы және кейінгі түрлендірулер үшін шынымен жеткілікті екенін анықтай алмайды.

Міне, дәл осы жерде бәрі күрделене түседі. Мәселе тек деректердің қабылдағышқа жетуінде емес. Мәселе — кодтағы тексерулер мәнді жүйе болжайтындай түрде шын мәнінде шектей ме, жоқ па.

Басқаша айтсақ: «код санитайзерді шақырады» деу мен «жүйе қауіпсіз» деудің арасында үлкен айырмашылық бар.

Мынадай үлгі нақты жүйелерде үнемі кездеседі.

Веб-қолданба JSON payload алады, одан redirect_url өрісін шығарады, оны allowlist regex бойынша тексереді, URL-ді декодтайды да, нәтижені redirect өңдегішіне береді.

Классикалық көзден қабылдағышқа дейінгі есеп ағынды былай сипаттай алады:

сенімсіз кіріс → regex тексеруі → URL декодтау → redirect

Бірақ нақты сұрақ — тексерудің бар-жоғында емес. Мәселе — кейінгі түрлендірулерден соң сол тексеру мәнді әлі де шектей ме.

Егер regex декодтауға дейін іске қосылса, ол redirect өңдегіші түсіндіретін декодталған URL-ді шынымен керек деңгейде шектей ме?

Бұған жауап беру бүкіл түрлендіру тізбегі туралы ой қорыту дегенді білдіреді: regex неге рұқсат береді, декодтау мен қалыпқа келтіру қалай жұмыс істейді, URL талдауы шеткі жағдайларды қалай өңдейді және redirect логикасы схемалар мен authority-лерді қалай шешеді.

Іс жүзінде маңызды болатын көптеген осалдықтар дәл осылай көрінеді: операциялар ретіндегі қателер, ішінара қалыпқа келтіру, талдаудағы екіұштылықтар және валидация мен интерпретация арасындағы сәйкессіздіктер. Деректер ағыны көрініп тұр. Әлсіздік — шектеулердің түрлендіру тізбегі арқылы қалай тарайтынында немесе тарамай қалатынында.

Бұл тек теориялық үлгі емес. CVE-2024-29041⁠(жаңа терезеде ашылады) жағдайында Express-ке open redirect мәселесі әсер етті: қате пішімделген URL-дер redirect нысаналарының кодталуы мен кейін қалай интерпретациялануына байланысты allowlist-тің кең таралған іске асыруларын айналып өте алды. Деректер ағыны қарапайым болды. Неғұрлым қиын сұрақ — әрі ақаудың бар-жоғын анықтаған сұрақ — түрлендіру тізбегінен кейін валидацияның әлі де күшінде қалуында еді.

Codex Security қарапайым мақсат айналасында құрылған: күштірек дәлелдері бар мәселелерді шығару арқылы триажды азайту. Өнімде бұл репозиторийге тән контексті (соның ішінде қауіп моделі) қолдануды және жоғары сигналды мәселелерді көрсетпес бұрын оқшауланған ортада тексеруді білдіреді. 

Codex Security «валидация» немесе «санитизация» болып көрінетін шекараға тап болғанда, оны жай ғана белгі қоятын пункт ретінде қарастырмайды. Ол код ненің кепілдігін беруге тырысып тұрғанын түсінуге тырысады — сосын сол кепілдікті жоққа шығаруға тырысады.

Іс жүзінде бұл көбіне мыналардың қоспасына ұқсайды:

• Қауіпсіздік зерттеушісі сияқты толық репозиторий контекстімен тиісті код жолын оқу және ниет пен іске асыру арасындағы сәйкессіздіктерді іздеу. Бұған пікірлер де кіреді, бірақ модель пікірлерге міндетті түрде сене бермейді, сондықтан кодыңыздың үстіне //Halvar says: this is not a bug деп жазу, егер шынымен қате болса, оны шатастырмайды.
• Жүйенің қалған бөлігі кедергі келтірмей ой қорытуға болатындай, мәселені тексеруге болатын ең кіші бөлікке дейін қысқарту (мысалы, бір кіріс айналасындағы түрлендіру конвейері). Осы мағынада Codex Security кодтың өте кішкентай бөліктерін бөліп алып, солар үшін micro-fuzzer-лер жазады.
• Әр тексеруді бөлек қарастырмай, түрлендірулер арасындағы шектеулер туралы ой қорыту. Қажет жерінде бұл қанағаттандырылу мәселесі ретінде формализацияны қамтуы мүмкін. Басқаша айтқанда, біз модельге z3-solver бар Python ортасына қол жеткізу мүмкіндігін береміз, және ол әсіресе күрделі кіріс шектеуі мәселесіне жауап беру қажет болғанда, адам сияқты оны орнымен қолдана алады. Бұл, әсіресе, стандартты емес архитектуралардағы бүтін санның асып кетуі сияқты қателерді қарауда пайдалы.
• Мүмкін болғанда гипотезаларды sandbox-та оқшауланған тексеру ортасында орындау, «мұнда мәселе болуы мүмкін» мен «мұнда мәселе бар» дегеннің аражігін ажырату үшін. Код debug режимінде компиляцияланған толық end-to-end PoC-тен артық дәлел жоқ. 

Міне, негізгі ауысым осы: жүйе «тексеру бар» деген жерде тоқтамай, «инвариант орындалады (немесе орындалмайды), міне дәлел» дегенге қарай ұмтылады. Ал модель бұл жұмыс үшін ең жақсы құралды таңдайды.

Орынды реакция мынадай болуы мүмкін: неге екеуін де қолданбасқа? SAST есебінен бастап, содан кейін агентті тереңірек ой қорыту үшін пайдалану.

Алдын ала есептелген findings кей жағдайда пайдалы — әсіресе тар, белгілі қате кластары үшін. Бірақ контекст ішінде осалдықтарды табуға және тексеруге арналған агент үшін SAST есебінен бастау үш болжамды сәтсіздік режимін тудырады.

Біріншіден, бұл тым ерте тарылтуға итермелеуі мүмкін. Findings тізімі — құралдың қайда қарап қойғанының картасы. Егер оны бастапқы нүкте деп қабылдасаңыз, жүйені сол аймақтарға пропорционалдан тыс күш жұмсауға, сол абстракцияларды қолдануға және құралдың дүниетанымына сыймайтын мәселелер кластарын жіберіп алуға бейімдей аласыз.

Екіншіден, бұл кейін қайтару қиын жасырын пайымдарды енгізуі мүмкін. Көптеген SAST findings санитизация, валидация немесе сенім шекаралары туралы болжамдарды кодтайды. Егер бұл болжамдар қате болса — немесе жай ғана толық болмаса — оларды ой қорыту цикліне беру агентті «зерттеуден» «растау не жоққа шығаруға» ығыстыруы мүмкін, ал біз агенттің дәл олай істегенін қаламаймыз.

Үшіншіден, бұл ой қорыту жүйесін бағалауды қиындатуы мүмкін. Егер конвейер SAST шығысынан басталса, агенттің өз талдауы арқылы не ашқанын және басқа құралдан нені мұраға алғанын ажырату қиын болады. Мұндай ажырату жүйе мүмкіндіктерін дәл өлшегіңіз келсе маңызды, өйткені жүйенің уақыт өте жақсаруы үшін бұл қажет.

Сондықтан біз Codex Security-ті қауіпсіздік зерттеуі басталатын жерден басталатындай етіп жасадық: кодтан және жүйенің ниетінен, ал валидацияны адамды алаңдатпас бұрын сенімділік шегін көтеру үшін қолданамыз.

SAST құралдары өздері арналған нәрседе тамаша бола алады: қауіпсіз кодтау стандарттарын сақтау, қарапайым көзден қабылдағышқа дейінгі мәселелерді ұстау және белгілі үлгілерді болжамды ымыралармен ауқымда анықтау. Олар көпқабатты қорғаныстың мықты бөлігі бола алады.

Бұл жазба ауқымы тарлау: онда мінез-құлық туралы ой қорытып, findings-ті тексеруге арналған агент неге жұмысын статикалық findings тізіміне байлап бастамауы керектігі туралы айтылады.

Сондай-ақ таза көзден қабылдағышқа дейінгі ойлаудың байланысты бір шектеуін атап өткен жөн: әрбір осалдық деректер ағыны мәселесі емес. Көптеген нақты ақаулар күй мен инвариант мәселелері — workflow-ды айналып өту, авторизациядағы олқылықтар және «жүйе дұрыс емес күйде тұр» деген қателер. Мұндай қателерде ластанған мән бір ғана «қауіпті қабылдағышқа» жетпейді. Қауіп бағдарлама әрқашан шын болады деп болжайтын нәрседе жатыр. 

Біз қауіпсіздік құралдары экожүйесі жақсара береді деп күтеміз: статикалық талдау, fuzzing, runtime қорғаныстары және агенттік жұмыс ағындарының бәрінің де өз рөлі болады.

Біз Codex Security-тің мына тұста мықты болғанын қалаймыз: қауіпсіздік командалары үшін ең қымбат нәрсені — «бұл күмәнді көрінеді» дегенді «бұл шынайы мәселе, міне ол қалай бұзылады, әрі міне жүйе ниетіне сай келетін түзету» дегенге айналдыру.

Егер Codex Security репозиторийлерді қалай сканерлейтіні, findings-ті қалай тексеретіні және түзетулерді қалай ұсынатыны туралы көбірек білгіңіз келсе, құжаттамамызды⁠(жаңа терезеде ашылады) қараңыз.