Mengapa Codex Security Tidak Menyertakan Laporan SAST

Selama beberapa dekad, ujian keselamatan aplikasi statik (SAST) telah menjadi salah satu cara yang paling berkesan untuk pasukan keselamatan menskalakan semakan kod. 

Tetapi apabila kami membina Codex Security, kami membuat pilihan reka bentuk yang disengajakan: kami tidak bermula dengan mengimport laporan analisis statik dan meminta ejen untuk menapisinya. Kami mereka bentuk sistem untuk bermula dengan repositori itu sendiri—seni binanya, sempadan kepercayaannya dan tingkah laku yang dimaksudkan—dan untuk mengesahkan apa yang ditemuinya sebelum meminta manusia meluangkan masa untuknya. 

Sebabnya mudah: kerantanan yang paling sukar biasanya bukan masalah aliran data. Ia berlaku apabila kod kelihatan menguatkuasakan pemeriksaan keselamatan, tetapi pemeriksaan itu sebenarnya tidak menjamin sifat yang bergantung pada sistem. Dengan kata lain, cabarannya bukan sekadar menjejaki cara data bergerak melalui program—tetapi menentukan sama ada pertahanan dalam kod benar-benar berfungsi.

SAST sering kali digambarkan sebagai saluran paip yang bersih: kenal pasti sumber input yang tidak dipercayai, jejak data melalui program dan tandakan kes apabila data itu mencapai penenggelaman sensitif tanpa sanitasi. Ia adalah model yang elegan dan ia merangkumi banyak pepijat sebenar.

Dalam amalan, SAST perlu membuat anggaran untuk kekal mudah dilaksanakan pada skala—terutamanya dalam kod asas sebenar dengan tidak langsung, penghantaran dinamik, panggil balik, refkelsi dan aliran kawalan kerangka kerja yang berat. Anggaran tersebut bukanlah kritikan terhadap SAST; ia adalah realiti apabila cuba menaakul tentang kod tanpa melaksanakannya.

Dengan sendirinya, itu bukan sebab Codex Security tidak bermula dengan laporan SAST.

Isu yang lebih mendalam ialah apa yang berlaku selepas anda berjaya menjejak sumber penenggelaman.

Walaupun analisis statik menjejak input dengan betul merentasi berbilang fungsi dan lapisan, ia masih perlu menjawab soalan yang benar-benar menentukan sama ada wujudnya kerentanan:

Ambil satu corak biasa: kod memanggil sesuatu seperti sanitize_html() sebelum memaparkan kandungan yang tidak dipercayai. Penganalisis statik boleh melihat bahawa penyahjangkit telah dijalankan. Apa yang biasanya ia tidak dapat ditentukan ialah sama ada penyahjangkit itu sebenarnya memadai untuk konteks pemaparan khusus, enjin templat, tingkah laku pengekodan dan transformasi hiliran yang terlibat.

Di situlah keadaan menjadi sukar. Masalahnya bukan hanya sama ada data mencapai penenggelaman. Ia adalah sama ada semakan dalam kod benar-benar mengehadkan nilai dengan cara yang sistem mengandaikannya.

Dengan kata lain: terdapat perbezaan besar antara “kod memanggil penyahjangkit” dan “sistem itu selamat.”

Ini ialah satu corak yang sering muncul dalam sistem sebenar.

Sebuah aplikasi web menerima muatan beban JSON, mengekstrak redirect_url, mengesahkannya terhadap regex senarai yang dibenarkan, menyahkod URLnya dan menghantar hasilnya kepada pengendali ubah hala.

Laporan sumber-ke-penenggelaman klasik boleh menerangkan aliran:

input yang tidak dipercayai → semakan regex → penyahkodan URL → pengubah hala

Tetapi persoalan sebenar bukanlah sama ada semakan itu wujud. Ini sama ada semakan itu masih mengekang nilai selepas transformasi yang menyusul.

Jika regex dijalankan sebelum penyahkodan, adakah ia benar-benar mengekang URL yang dinyahkod seperti yang ditafsirkan oleh pengendali penghalaan?

Menjawab itu bermaksud melakukan penaakulan tentang keseluruhan rantaian transformasi: apa yang dibenarkan oleh regex, cara penyahkodan dan penormalan berfungsi, cara penghuraian URL menangani kes tepi dan cara logik lencongan penghalaan skim dan autoriti.

Banyak kerentanan yang penting dalam amalan kelihatan seperti ini: kesilapan susunan operasi, penormalan separa, kekaburan penghuraian dan ketidakpadanan antara pengesahan dan tafsiran. Aliran data itu kelihatan. Kelemahannya terletak pada cara kekangan tersebar—atau gagal tersebar—melalui rantaian transformasi.

Ini bukan sekadar corak teori. Dalam CVE-2024-29041⁠(dibuka dalam tetingkap baru), Express terjejas oleh isu penghalaan terbuka di mana URL yang cacat boleh memintas pelaksanaan senarai dibenarkan yang lazim kerana cara sasaran penghalaan dikodkan dan kemudian ditafsirkan. Aliran data adalah mudah. Soalan yang lebih sukar—dan yang menentukan sama ada pepijat itu wujud—ialah sama ada pengesahan itu masih sah selepas rantaian transformasi.

Codex Security dibina berasaskan satu matlamat yang mudah: mengurangkan proses triage dengan menunjukkan isu yang disertakan bukti yang lebih kukuh. Dalam produk, ini bermaksud menggunakan konteks khusus repo (termasuk model ancaman) serta mengesahkan isu berisyarat tinggi dalam persekitaran terasing sebelum menunjukkannya. 

Apabila Codex Security menemui sempadan yang kelihatan seperti “pengesahan” atau “pensanitasi,” ia tidak menganggapnya sebagai kotak semak. Ia cuba memahami jaminan kod tersebut cuba jamin—dan kemudian ia cuba memalsukan jaminan itu.

Dalam amalan, itu cenderung kelihatan seperti campuran:

• Membaca laluan kod yang berkaitan dengan konteks repositori penuh, seperti yang dilakukan oleh penyelidik keselamatan dan mencari salah padanan antara niat dan pelaksanaan. Ini termasuk komen, tetapi model tidak semestinya mempercayai komen, jadi menambah //Halvar says: ini bukan pepijat di atas kod anda tidak mengelirukannya, jika memang benar-benar terdapat pepijat.
• Mengurangkan masalah kepada cebisan terkecil yang boleh diuji (sebagai contoh, saluran paip transformasi di sekitar satu input), supaya anda boleh membuat penaakulan mengenainya tanpa halangan daripada seluruh sistem. Dalam erti kata ini, Codex Security mengeluarkan cebisan kecil kod dan kemudian menulis mikro-fuzzer untuknya.
• Penaakulan tentang kekangan merentas transformasi, bukannya menganggap setiap semakan secara bebas. Di mana sesuai, ini boleh termasuk pemformalan sebagai soalan kebolehpenuhan. Dengan kata lain, kami memberikan model akses kepada persekitaran Python dengan penyelesai-z3 dan ia mahir menggunakannya apabila diperlukan, sama seperti yang manusia perlu berbuat demikian apabila menjawab masalah kekangan input yang sangat rumit. Ini amat berguna untuk melihat limpahan integer atau pepijat serupa pada seni bina bukan standard.
• Melaksanakan hipotesis dalam persekitaran validasi medan ujian apabila mungkin, untuk membezakan “ini mungkin satu masalah” daripada “ini adalah masalah”. Tiada bukti yang lebih baik daripada PoC penuh dari hujung ke hujung dengan kod yang disusun dalam mod nyahpepijat. 

Ini ialah peralihan utama: dan bukannya berhenti pada “semakan wujud”, sistem mendorong ke arah “tak varian dipenuhi (atau tidak) dan inilah buktinya.” Dan model memilih alat terbaik untuk tugas itu.

Reaksi yang munasabah ialah: mengapa tidak buat kedua-duanya? Mulakan dengan laporan SAST, kemudian gunakan ejen untuk membuat penaakulan yang lebih mendalam.

Terdapat kes di mana dapatan yang telah diprakira adalah berguna—terutamanya untuk kelas pepijat yang sempit dan sudah diketahui. Tetapi bagi ejen yang direka untuk menemui dan mengesahkan kerentanan dalam konteks, bermula daripada laporan SAST menghasilkan tiga mod kegagalan yang boleh dijangka.

Pertama, ia boleh menggalakkan penyempitan pramatang. Senarai penemuan ialah peta tempat yang sudah dilihat oleh alat. Jika anda menganggapnya sebagai titik permulaan, anda boleh membiaskan sistem ke arah mengeluarkan usaha berkadar yang tidak seimbang di rantau yang sama, menggunakan pengabstrakan yang sama dan terlepas kelas isu yang tidak sesuai dengan pandangan hidup alat tersebut.

Kedua, ia boleh memperkenalkan pertimbangan tersirat yang sukar untuk dirungkai. Banyak penemuan SAST mengekod tanggapan tentang pensanitasi, pengesahan atau sempadan kepercayaan. Jika andaian tersebut salah—atau sekadar tidak lengkap—memasukkannya ke dalam gelung penaakulan boleh mengalihkan ejen daripada “menyiasat” kepada “mengesahkan atau menolak,” yang bukan apa yang kami mahu ejen lakukan.

Ketiga, ia boleh menjadikannya lebih sukar untuk menilai sistem penaakulan. Jika talian paip bermula dengan output SAST, ia menjadi sukar untuk memisahkan apa yang ejen temui melalui analisisnya sendiri daripada apa yang diwarisi daripada alat lain. Pengasingan itu penting jika anda ingin mengukur keupayaan sistem dengan tepat, yang diperlukan agar sistem dapat menambah baik dari semasa ke semasa.

Jadi kami membina Codex Security untuk bermula di tempat penyelidikan keselamatan bermula: daripada kod dan niat sistem, dengan pengesahan yang digunakan untuk meningkatkan tahap keyakinan sebelum kami mengganggu manusia.

Alat SAST boleh menjadi sangat cemerlang dalam apa yang direka: menguatkuasakan standard pengekodan selamat, menangkap isu sumber-ke-penenggelaman yang mudah dan mengesan corak yang diketahui pada skala dengan tukar ganti yang boleh dijangka. Ia boleh menjadi bahagian yang kukuh bagi pertahanan mendalam.

Siaran ini lebih sempit: ia tentang mengapa ejen yang direka untuk membuat penaakulan tentang tingkah laku dan mengesahkan penemuan tidak seharusnya memulakan kerjanya dengan berpandukan senarai penemuan statik.

Perlu juga menegaskan satu batasan berkaitan pemikiran sumber-ke-penenggelaman yang tulen: tidak semua kelemahan ialah masalah aliran data. Banyak kegagalan sebenar ialah masalah keadaan dan tak berubah—pemintasan aliran kerja, jurang kebenaran dan pepijat “sistem berada dalam keadaan yang salah”. Untuk jenis pepijat ini, nilai tercemar tidak mencapai satu “penenggelaman berbahaya”. Risikonya terletak pada tanggapan program anggap akan sentiasa benar. 

Kami menjangkakan ekosistem alatan keselamatan akan terus bertambah baik: analisis statik, kabur, pengawal waktu jalan dan aliran kerja agentic semuanya akan memainkan peranan.

Apa yang kami mahu Codex Security mahir ialah bahagian yang paling mahal untuk pasukan keselamatan: menukar “ini kelihatan mencurigakan” kepada “ini memang benar, inilah cara ia gagal dan inilah pembaikan yang sepadan dengan niat sistem.” 

Jika anda ingin mengetahui lebih lanjut tentang cara Codex Security mengimbas repositori, mengesahkan penemuan dan mencadangkan pembaikan, lihat dokumentasi kami⁠(dibuka dalam tetingkap baru).