Selama beberapa dekade, pengujian keamanan aplikasi statis (SAST) telah menjadi salah satu cara paling efektif bagi tim keamanan untuk meningkatkan skala peninjauan kode.
Namun ketika kami membangun Codex Security, kami membuat pilihan desain yang disengaja: kami tidak memulai dengan mengimpor laporan analisis statis dan meminta agen untuk meninjaunya. Kami merancang sistem untuk memulai dengan repositori itu sendiri—arsitekturnya, batas kepercayaannya, dan perilaku yang dimaksudkan—dan untuk memvalidasi apa yang ditemukannya sebelum meminta manusia meluangkan waktu untuk itu.
Alasannya sederhana: kerentanan yang paling sulit biasanya bukan masalah aliran data. Kerentanan terjadi ketika kode tampak menerapkan pemeriksaan keamanan, tetapi pemeriksaan itu sebenarnya tidak menjamin properti yang diandalkan sistem. Dengan kata lain, tantangannya bukan hanya melacak bagaimana data bergerak melalui sebuah program—melainkan menentukan apakah pertahanan dalam kode benar-benar berfungsi.
SAST sering kali digambarkan sebagai pipeline yang bersih: mengidentifikasi sumber input yang tidak tepercaya, melacak data melalui program, dan menandai kasus ketika data tersebut mencapai sink sensitif tanpa sanitasi. Ini adalah model yang elegan, dan ini mencakup banyak bug yang nyata.
Dalam praktiknya, SAST harus membuat pendekatan perkiraan agar tetap dapat ditangani pada skala besar—terutama dalam basis kode nyata dengan pengalihan tidak langsung (indirection), pemanggilan dinamis (dynamic dispatch), callback, refleksi (reflection), dan alur kontrol yang sarat framework. Perkiraan tersebut bukanlah kritik terhadap SAST; itu adalah realitas dari upaya mencoba menalar kode tanpa mengeksekusinya.
Namun, hal itu sendiri bukan alasan mengapa Codex Security tidak dimulai dengan laporan SAST.
Masalah yang lebih mendalam adalah apa yang terjadi setelah Anda berhasil melacak sumber ke sink.
Bahkan saat analisis statis melacak masukan dengan benar di berbagai fungsi dan lapisan, analisis tersebut tetap harus menjawab pertanyaan yang benar-benar menentukan apakah sebuah kerentanan ada:
Ambil pola umum: kode memanggil sesuatu seperti sanitize_html() sebelum merender konten yang tidak tepercaya. Penganalisis statis dapat melihat bahwa sanitizer telah dijalankan. Yang biasanya tidak dapat ditentukan adalah apakah sanitizer tersebut benar-benar memadai untuk konteks rendering tertentu, mesin template, perilaku encoding, dan transformasi hilir yang terlibat.
Di situlah semuanya menjadi rumit. Masalahnya bukan hanya apakah data mencapai sebuah sink. Ini tentang apakah pemeriksaan dalam kode benar-benar membatasi nilainya dengan cara yang diasumsikan sistem.
Dengan kata lain: ada perbedaan besar antara “kode memanggil sanitizer” dan “sistemnya aman.”
Berikut pola yang sering muncul di sistem nyata.
Sebuah aplikasi web menerima payload JSON, mengekstrak redirect_url, memvalidasinya terhadap regex allowlist, melakukan dekode URL terhadapnya, dan meneruskan hasilnya ke pengendali pengalihan.
Sebuah laporan sumber-ke-sink klasik dapat menjelaskan alurnya:
input tidak tepercaya → pemeriksaan regex → dekode URL → pengalihan
Namun pertanyaan sebenarnya bukanlah apakah pemeriksaan itu ada. Ini tentang apakah pemeriksaan tersebut masih membatasi nilai setelah transformasi yang mengikutinya.
Jika regex berjalan sebelum dekode, apakah itu benar-benar membatasi URL yang sudah didekode sebagaimana pengendali pengalihan menafsirkannya?
Menjawab itu berarti melakukan penalaran tentang seluruh rantai transformasi: apa yang diizinkan regex, bagaimana proses dekode dan normalisasi berperilaku, bagaimana penguraian URL memperlakukan kasus tepi, dan bagaimana logika pengalihan menyelesaikan skema dan otoritas.
Banyak kerentanan yang penting dalam praktik terlihat seperti ini: kesalahan urutan operasi, normalisasi parsial, ambiguitas penguraian, dan ketidakcocokan antara validasi dan interpretasi. Alur data terlihat. Kelemahannya terletak pada bagaimana kendala menyebar—atau gagal menyebar—melalui rantai transformasi.
Ini bukan hanya pola teoretis. Dalam CVE-2024-29041(terbuka di jendela baru), Express terpengaruh oleh masalah pengalihan terbuka (open redirect) di mana URL yang cacat dapat melewati implementasi allowlist yang umum karena cara target pengalihan dikodekan lalu diinterpretasikan. Alur data tersebut mudah. Pertanyaan yang lebih sulit—dan yang menentukan apakah bug itu ada—adalah apakah validasi tersebut masih berlaku setelah rantai transformasi.
Codex Security dibangun berdasarkan tujuan sederhana: mengurangi triase dengan memunculkan isu dengan bukti yang lebih kuat. Dalam produknya, itu berarti menggunakan konteks khusus repo (termasuk model ancaman) dan memvalidasi masalah bersinyal kuat dalam lingkungan terisolasi sebelum menampilkannya.
Saat Codex Security menjumpai batas yang terlihat seperti “validation” atau “sanitization,” Codex Security tidak memperlakukannya sebagai sekadar kotak centang. Codex Security mencoba memahami jaminan apa yang coba dipastikan oleh kode—lalu mencoba membuktikan bahwa jaminan itu salah.
Dalam praktiknya, hal itu cenderung tampak seperti campuran dari:
- Membaca jalur kode yang relevan dengan konteks repositori penuh, seperti yang dilakukan seorang peneliti keamanan, dan mencari ketidaksesuaian antara maksud dan implementasi. Ini termasuk komentar, tetapi model tidak selalu mempercayai komentar jadi menambahkan //Halvar mengatakan: ini bukan bug di atas kode Anda tidak akan membingungkannya, jika memang ada bug.
- Mengurangi masalah menjadi potongan terkecil yang dapat diuji (misalnya, pipeline transformasi di sekitar satu input), sehingga Anda dapat menalarnya tanpa sisa sistem menghalangi. Dalam pengertian ini, Codex Security mengambil potongan kode kecil lalu menulis mikro-fuzzer untuk potongan tersebut.
- Penalaran tentang batasan di berbagai transformasi, alih-alih memperlakukan setiap pemeriksaan secara independen. Jika sesuai, ini dapat mencakup formalisasi sebagai pertanyaan keterpenuhan. Dengan kata lain, kami memberikan model akses ke lingkungan Python dengan z3-solver dan model ini mahir menggunakannya saat diperlukan, sebagaimana manusia harus melakukannya ketika menjawab soal batasan input yang sangat rumit. Ini sangat bermanfaat terutama untuk melihat luapan bilangan bulat atau bug serupa pada arsitektur nonstandar.
- Menjalankan hipotesis dalam lingkungan validasi yang disandbox jika memungkinkan, untuk membedakan “ini bisa menjadi masalah” dari “ini adalah masalah”. Tidak ada bukti yang lebih baik daripada PoC end-to-end secara menyeluruh dengan kode yang dikompilasi dalam mode debug.
Ini adalah pergeseran kunci: alih-alih berhenti pada “sebuah pemeriksaan ada,” sistem mendorong ke arah “invarian tersebut terpenuhi (atau tidak), dan inilah buktinya”. Dan model memilih alat bantu terbaik untuk pekerjaan tersebut.
Reaksi yang masuk akal adalah: mengapa tidak melakukan keduanya? Mulai dengan laporan SAST, lalu gunakan agen untuk melakukan penalaran yang lebih mendalam.
Ada kasus di mana temuan yang dihitung sebelumnya berguna—terutama untuk kelas bug yang spesifik dan sudah diketahui. Namun, untuk sebuah agen yang dirancang untuk menemukan dan memvalidasi kerentanan dalam konteks, memulai dari laporan SAST menciptakan tiga mode kegagalan yang dapat diprediksi.
Pertama, hal ini dapat mendorong penyempitan sebelum waktunya. Daftar temuan merupakan peta dari area yang telah diperiksa oleh suatu alat. Jika Anda memperlakukannya sebagai titik awal, Anda dapat membiasakan sistem untuk mengerahkan upaya yang tidak proporsional di wilayah yang sama, menggunakan abstraksi yang sama, dan melewatkan kelas-kelas masalah yang tidak sesuai dengan cara pandang alat tersebut.
Kedua, hal ini dapat memperkenalkan penilaian tersirat yang sulit diurai. Banyak temuan SAST mengenkode asumsi tentang sanitasi, validasi, atau batasan kepercayaan. Jika asumsi-asumsi tersebut salah—atau hanya tidak lengkap—memasukkannya ke dalam loop penalaran dapat menggeser agen dari “menyelidiki” menjadi “mengonfirmasi atau menolak,” ini adalah hal yang tidak kita inginkan dilakukan agen.
Ketiga, hal ini dapat membuat evaluasi sistem penalaran menjadi lebih sulit. Jika pipeline dimulai dengan output SAST, akan menjadi sulit untuk memisahkan apa yang ditemukan agen melalui analisisnya sendiri dari apa yang diwarisinya dari alat lain. Pemisahan itu penting jika Anda ingin mengukur kemampuan sistem secara akurat, yang diperlukan agar sistem dapat meningkat dari waktu ke waktu.
Jadi, kami membangun Codex Security untuk memulai dari titik awal penelitian keamanan: dari kode dan maksud sistem, dengan validasi yang digunakan untuk meningkatkan tingkat keyakinan sebelum kami menginterupsi manusia.
Alat SAST dapat sangat unggul dalam hal yang memang dirancang untuk dilakukan: menegakkan standar pengodean aman, menangkap masalah source-to-sink yang sederhana, dan mendeteksi pola yang diketahui dalam skala besar dengan kompromi yang dapat diprediksi. Alat itu dapat menjadi bagian yang kuat dari pertahanan berlapis.
Postingan ini lebih spesifik: ini tentang mengapa agen yang dirancang untuk menganalisis perilaku dan memvalidasi temuan seharusnya tidak memulai pekerjaannya dengan berpatokan pada daftar temuan statis.
Perlu juga dicatat adanya keterbatasan terkait dari cara berpikir source-to-sink murni: tidak semua kerentanan merupakan masalah aliran data. Banyak kegagalan nyata adalah masalah status dan invarian—pengabaian alur kerja, celah otorisasi, dan bug “sistem berada dalam status yang salah”. Untuk jenis bug seperti ini, nilai yang terkontaminasi tidak mencapai satu “sink berbahaya.” Risikonya terletak pada asumsi program tentang hal-hal yang akan selalu benar.
Kami berharap ekosistem alat keamanan akan terus membaik: analisis statis, fuzzing, pengaman runtime, dan alur kerja agentik semuanya akan memiliki peran.
Yang kami ingin Codex Security kuasai adalah bagian yang paling mahal bagi tim keamanan: mengubah “ini terlihat mencurigakan” menjadi “ini nyata, begini cara kegagalannya, dan ini perbaikan yang sesuai dengan maksud sistem.”
Jika Anda ingin mempelajari lebih lanjut tentang cara Codex Security memindai repositori, memvalidasi temuan, dan mengusulkan perbaikan, lihat dokumentasi kami(terbuka di jendela baru).
