Wis puluhan taun, static application security testing (SAST) dadi salah siji cara paling efektif kanggo tim keamanan ngembangake review kode.
Nanging nalika mbangun Codex Security, kita nggawe pilihan rancangan sing disengaja: kita ora miwiti kanthi ngimpor laporan analisis statis lan njaluk agen kanggo nindakake triase. Kita ngrancang sistem supaya miwiti saka gudang kode dhewe—arsitektur, wates kapercayan, lan prilaku sing dikarepake—lan kanggo mvalidasi apa sing ditemokake sadurunge njaluk manungsa ngentekake wektu kanggo kuwi.
Sebabé prasaja: kerentanan sing paling angel biasane dudu masalah dataflow. Iki kedadeyan nalika kode katon ngetrapake pamriksan keamanan, nanging pamriksan kuwi sakjané ora njamin properti sing dadi sandaran sistem. Kanthi tembung liya, tantangane ora mung nglacak carane data obah liwat program—nanging nemtokake apa pertahanan ing kode kuwi tenan bisa digunakake.
SAST kerep digambarake dadi pipeline sing resik: ngenali sumber input sing ora dipercaya, nglacak data liwat program, lan nandhani kasus nalika data kuwi tekan sink sing sensitif tanpa sanitasi. Iki model sing elegan, lan nutupi akèh bug nyata.
Ing praktiké, SAST kudu nggawe pendekatan perkiraan supaya tetep bisa ditangani ing skala gedhe—utamané ing codebase nyata sing kebak indirection, dynamic dispatch, callback, reflection, lan control flow sing abot framework. Pendekatan perkiraan kuwi dudu cacat kanggo SAST; kuwi realita saka upaya nalar babagan kode tanpa nglakokake.
Kuwi, dhewe, dudu sebab kenapa Codex Security ora miwiti saka laporan SAST.
Masalah sing luwih jero yaiku apa sing kedadeyan sawisé sampeyan kasil nglacak sumber menyang sink.
Sanajan analisis statis kanthi bener nglacak input liwat pirang-pirang fungsi lan lapisan, isih kudu njawab pitakon sing sakjané nemtokake apa ana kerentanan:
Delengen pola umum: kode nelpon kaya sanitize_html() sadurunge ngerender konten sing ora dipercaya. Analyzer statis bisa ndeleng manawa sanitizer wis mlaku. Sing biasane ora bisa ditemtokake yaiku apa sanitizer kuwi sakjané cukup kanggo konteks rendering tartamtu, template engine, prilaku encoding, lan transformasi hilir sing melu.
Ing kéné perkara dadi ruwet. Masalahé ora mung apa data tekan sink. Nanging apa pamriksan ing kode kuwi sakjané mbatesi nilaine kanthi cara sing diasumsèkaké sistem.
Kanthi cara liya: ana bedane gedhe antarane “kode nelpon sanitizer” lan “sistemé aman.”
Iki pola sing kerep banget muncul ing sistem nyata.
Sawijining aplikasi web nampa payload JSON, njupuk redirect_url, mvalidasi nganggo regex allowlist, nindakake URL-decode, lan nerusake asilé menyang handler redirect.
Laporan source-to-sink klasik bisa njlentrehake alirané:
input ora dipercaya → pamriksan regex → URL decode → redirect
Nanging pitakon sing nyata dudu apa pamriksan kuwi ana. Nanging apa pamriksan kuwi isih mbatesi nilai sawisé transformasi sing ngetutaké.
Yen regex mlaku sadurunge decoding, apa tenan mbatesi URL sing wis didekode kaya cara handler redirect napsiraké?
Kanggo njawab kuwi, kudu nalar babagan kabeh ranté transformasi: apa sing diidinaké regex, carane decoding lan normalisasi tumindak, carane parsing URL nangani edge case, lan carane logika redirect ngrampungaké scheme lan authority.
Akeh kerentanan sing wigati ing praktik katon kaya iki: kesalahan urutan operasi, normalisasi parsial, ambiguitas parsing, lan ketidakcocokan antarane validasi lan interpretasi. Dataflow-é katon. Kelemahane ana ing carane kendala nyebar—utawa gagal nyebar—liwat ranté transformasi.
Iki ora mung pola teoretis. Ing CVE-2024-29041(mbukak ing jendhela anyar), Express kena masalah open redirect nalika URL cacat bisa ngliwati implementasi allowlist umum amarga cara target redirect dienkode banjur diinterpretasi. Dataflow-é lugas. Pitakon sing luwih angel—lan sing nemtokake apa bug kuwi ana—yaiku apa validasi isih tetep berlaku sawisé ranté transformasi.
Codex Security dibangun ngubengi tujuan sing prasaja: nyuda triase kanthi nampilake masalah kanthi bukti sing luwih kuwat. Ing produk, iki tegesé nggunakake konteks khusus repo (kalebu model ancaman) lan mvalidasi masalah sinyal dhuwur ing lingkungan terisolasi sadurunge ditampilaké.
Nalika Codex Security nemoni wates sing katon kaya “validation” utawa “sanitization,” sistem ora nganggep kuwi minangka centhang kothak. Sistem nyoba mangerteni apa sing arep dijamin kode—banjur nyoba mbantah jaminan kuwi.
Ing praktik, iki biasane katon kaya campuran saka:
- Maca jalur kode sing relevan nganggo konteks gudang kode sing lengkap, kaya peneliti keamanan, lan nggoleki ketidakcocokan antarane niyat lan implementasi. Iki kalebu komentar, nanging model ora mesthi percaya komentar mula nambahake //Halvar says: this is not a bug ing ndhuwur kode sampeyan ora bakal mbingungake, yen tenan ana bug.
- Nyuda masalah dadi irisan paling cilik sing bisa diuji (contone, pipeline transformasi ing sakupenge siji input), supaya sampeyan bisa nalar babagan kuwi tanpa keganggu sistem liyane. Ing pangerten iki, Codex Security njupuk irisan kode cilik banjur nulis micro-fuzzer kanggo kuwi.
- Nalar babagan kendala ing sakulon transformasi, tinimbang nganggep saben pamriksan kanthi mandiri. Yen cocog, iki bisa kalebu formalisasi dadi pitakon satisfiability. Kanthi tembung liya, kita menehi model akses menyang lingkungan Python nganggo z3-solver lan model iki trampil nggunakaké nalika perlu, kaya manungsa uga kudu nindakake nalika njawab masalah kendala input sing rumit. Iki migunani banget kanggo ndeleng integer overflow utawa bug sing padha ing arsitektur non-standar.
- Nglakokaké hipotesis ing lingkungan validasi sing disandbox yen bisa, supaya bisa mbedakake antarane “iki bisa dadi masalah” lan “iki pancen masalah”. Ora ana bukti sing luwih apik tinimbang PoC end-to-end lengkap kanthi kode dikompilasi ing mode debug.
Iki owah-owahan kunciné: tinimbang mandheg ing “ana pamriksan,” sistem nyurung menyang “invariané tetep bener (utawa ora), lan iki buktiné”. Lan model milih alat paling apik kanggo tugas kuwi.
Reaksi sing lumrah yaiku: kenapa ora loro-loroné? Miwiti saka laporan SAST, banjur gunakake agen kanggo nalar luwih jero.
Ana kasus nalika temuan sing wis dihitung dhisik migunani—utamané kanggo kelas bug tartamtu sing sempit lan wis dingerteni. Nanging kanggo agen sing dirancang kanggo nemokake lan mvalidasi kerentanan ing konteks, miwiti saka laporan SAST nggawe telung mode gagal sing bisa ditebak.
Kaping pisan, iki bisa nyengkuyung penyempitan sing kesusu. Dhaptar temuan iku peta saka endi alat wis ndeleng. Yen dianggep titik wiwitan, sampeyan bisa nggawe bias sistem supaya ngentekake usaha sing ora seimbang ing wilayah sing padha, nganggo abstraksi sing padha, lan kliwatan kelas masalah sing ora cocog karo cara pandang alat kuwi.
Kaping pindho, iki bisa ngenalake penilaian implisit sing angel dibalèkaké. Akeh temuan SAST ngodekaké asumsi babagan sanitasi, validasi, utawa wates kapercayan. Yen asumsi kuwi salah—utawa mung ora lengkap—nglebokake kuwi menyang loop nalar bisa nggeser agen saka “nyelidiki” dadi “ngonfirmasi utawa mbantah,” lan kuwi dudu sing dikarepake saka agen.
Kaping telu, iki bisa nggawe evaluasi sistem nalar dadi luwih angel. Yen pipeline diwiwiti saka output SAST, dadi angel misahake apa sing ditemokake agen liwat analisisé dhewe saka apa sing diwarisake saka alat liyane. Pamisahan kuwi penting yen sampeyan pengin ngukur kapabilitas sistem kanthi akurat, lan kuwi dibutuhake supaya sistem bisa terus saya apik saka wektu ke wektu.
Mula kita mbangun Codex Security supaya miwiti saka panggonan riset keamanan diwiwiti: saka kode lan niyat sistem, kanthi validasi digunakaké kanggo ngunggahake standar kapercayan sadurunge kita ngganggu manungsa.
Alat SAST bisa apik banget kanggo apa sing dirancang: ngetrapake standar coding aman, nyekel masalah source-to-sink sing lugas, lan ndeteksi pola sing wis dikenal ing skala gedhe kanthi tradeoff sing bisa diprediksi. Iki bisa dadi bagean kuwat saka defense-in-depth.
Kiriman iki luwih sempit: iki babagan kenapa agen sing dirancang kanggo nalar babagan prilaku lan mvalidasi temuan ora kena miwiti pakaryané kanthi kaiket marang dhaptar temuan statis.
Uga penting kanggo nyorot watesan sing gegandhengan saka cara mikir source-to-sink murni: ora saben kerentanan iku masalah dataflow. Akeh kegagalan nyata iku masalah state lan invarian—workflow bypass, celah otorisasi, lan bug “sistem ana ing state sing salah”. Kanggo jinis bug iki, nilai sing kena taint ora tekan siji “sink mbebayani”. Risiko ana ing apa sing diasumsèkaké program bakal tansah bener.
Kita ngarepake ekosistem tooling keamanan bakal terus saya apik: analisis statis, fuzzing, runtime guard, lan alur kerja agentic kabèh bakal nduweni peran.
Sing kita karepake saka Codex Security yaiku trampil ing bagean sing paling larang kanggo tim keamanan: ngowahi “iki katon curiga” dadi “iki nyata, iki carane gagalé, lan iki perbaikan sing cocog karo niyat sistem.”
Yen sampeyan pengin sinau luwih akeh babagan carane Codex Security mindhai gudang kode, mvalidasi temuan, lan ngusulake perbaikan, delengen dokumentasi kita(mbukak ing jendhela anyar).
