Tinjauan Kode Keamanan Dijelaskan: Apa yang Dicari Peninjau dalam Diff, dan Mengapa

Tinjauan kode keamanan adalah pembacaan kode sumber secara sengaja untuk tujuan khusus menemukan cara-cara kode tersebut dapat dibuat melakukan sesuatu yang tidak dimaksudkan oleh penulisnya. Definisi itu terdengar jelas sampai Anda membandingkannya dengan apa yang sebenarnya dijalankan oleh sebagian besar tim, yaitu tinjauan fungsional dengan daftar periksa keamanan di dekatnya. OWASP Secure Code Review Cheat Sheet menarik batasnya dengan tepat: tinjauan keamanan berbeda dari tinjauan fungsional karena menyasar validasi input, autentikasi, otorisasi, implementasi kriptografi, dan vektor serangan, bukan kebenaran. Sebuah diff yang berfungsi sempurna tetap dapat memberi penyerang jalan masuk ke sistem, dan hanya satu dari dua tinjauan itu yang mencarinya.

Yang membuat topik ini layak dijadikan artikel sekarang, bukan pada 2020, adalah bahwa sebuah model bahasa dapat membaca diff secara kompeten, murah, dan terus-menerus — yang mengubah ekonomi peninjauan tanpa mengubah satu pun dimensi yang ditinjau. Daftar periksa itu lebih tua daripada model-model tersebut dan tidak bergeser. Yang bergeser adalah seberapa sering Anda mampu menjalankannya.

Apa yang sebenarnya dicari seorang reviewer saat membaca

Lembar contekan OWASP mengorganisasi pekerjaan ke dalam enam area, dan hal yang berguna dari daftar itu adalah setiap area merupakan sebuah pertanyaan, bukan kategori. Kategori mengundang pemenuhan formalitas; pertanyaan menghasilkan temuan.

Input dan injeksi. Pertanyaannya bukan apakah kode memiliki sanitizer; melainkan apakah ada yang mencapai interpreter — shell, SQL, mesin templat, evaluator ekspresi — dan di lapisan mana persyaratan itu seharusnya ditegakkan. Diff yang menambahkan kueri terparameterisasi itu baik; diff yang menambahkan kueri terparameterisasi ke dalam fungsi yang pemanggil lainnya mengirimkan string mentah adalah diff yang memindahkan masalahnya.

Autentikasi dan sesi. Siapa pemanggilnya, dan bagaimana kode membuktikannya? Bug yang berulang bukanlah pemeriksaan kata sandi yang rusak, melainkan sesi yang bertahan melewati perubahan hak istimewa — elevasi terjadi, token tetap memegang klaim lamanya, dan satu jam kemudian hak istimewa itu masih ada.

Authorization. Pemeriksaan tingkat objek, setiap kali, pada setiap rute. Hal spesifik yang perlu dicari dalam sebuah diff adalah rute baru yang tidak mewarisi guard yang dimiliki oleh rute-rute serumpunnya, karena middleware didaftarkan per-router dan rute yang ditambahkan di bawah router yang berbeda tidak akan ikut tercakup.

Kriptografi. Primitif, mode, panjang kunci, dan di mana kunci itu berada. Dua pertanyaan menangkap sebagian besar temuan nyata: dapatkah siapa pun yang dapat membaca basis kode ini juga membaca kuncinya, dan apakah perbandingan ini merupakan perbandingan yang tidak boleh membocorkan timing.

Logika bisnis.Apakah urutan dapat diubah susunannya, diputar ulang, atau dikendalikan oleh nilai yang dipilih klien. Harga, kuantitas, peran, atau transisi status yang datang dari klien dan tidak diturunkan kembali di sisi server merupakan temuan terlepas dari bagaimana validasinya.

Konfigurasi dan rahasia. Apa yang dikirim oleh diff yang seharusnya tidak pernah ada di repositori, dan apakah nilai default-nya aman di tempat kode itu benar-benar dijalankan. Flag debug yang default-nya true adalah temuan tentang produksi, bukan tentang flag itu.

Tinjauan baseline versus tinjauan diff

OWASP memisahkan dua mode, dan mencampuradukkan keduanya adalah sumber umum dari usaha yang terbuang sekaligus keyakinan palsu. Sebuah tinjauan baseline memeriksa basis kode secara menyeluruh, dan itu adalah alat yang tepat untuk aplikasi baru atau rilis utama, onboarding sistem legacy, memenuhi persyaratan kepatuhan, atau melakukan analisis pasca-insiden setelah terjadi masalah. Sebuah tinjauan berbasis diff hanya melihat apa yang berubah, dan itu adalah alat yang tepat untuk pull request, commit, penyelesaian fitur, dan validasi berkelanjutan.

Perbedaan ini penting karena keduanya menghasilkan pekerjaan yang berbeda. Tinjauan baseline berakhir dengan backlog; tinjauan diff berakhir dengan keputusan merge. Menjalankan yang pertama secara terus-menerus tidak terjangkau, dan menjalankan yang kedua pada basis kode yang belum pernah menjalani yang pertama adalah cara tim menumbuhkan kesan cakupan yang palsu: setiap perubahan lolos tinjauan, sementara penggabungan SQL yang sudah ada sebelumnya dibiarkan tanpa tersentuh.

Teknik, dan apa yang ditangkap masing-masing

OWASP mencantumkan empat teknik tinjauan, dan teknik-teknik tersebut dibedakan berdasarkan bukti apa yang diikuti oleh peninjau, bukan berdasarkan seberapa menyeluruh teknik itu. Analisis pola kode mengikuti bentuk-bentuk yang sudah dikenal: pemanggilan fungsi berbahaya, deserialisasi input yang tidak tepercaya, pemeriksaan panjang yang hilang. Teknik ini cepat dan persis seperti yang dikerjakan dengan baik oleh alat deterministik. Analisis aliran data mengikuti suatu nilai dari tempat ia masuk hingga tempat ia digunakan, yang merupakan satu-satunya cara untuk menjawab apakah sanitizer yang diterapkan tiga fungsi sebelumnya masih berlaku di sini. Tinjauan berbasis ancaman dimulai dari kemampuan penyerang lalu bekerja ke depan, yang merupakan cara Anda menangkap celah antara dua komponen yang masing-masing benar. Tinjauan logika bisnis membaca alur kerja alih-alih baris kode, menanyakan urutan operasi sah apa yang menghasilkan keadaan tidak sah.

Hanya yang pertama dari keempatnya yang dapat ditangani dengan baik oleh pemindai, dan hanya yang pertama dan kedua yang dapat ditangani dengan baik oleh proses model tanpa panduan. Itu bukan argumen menentang model; itu argumen untuk memberi tahu peninjau teknik mana yang Anda inginkan, karena prompt yang meminta "masalah keamanan" akan secara andal menghasilkan analisis pola lalu berhenti.

Apa yang diubah AI, dan apa yang tidak

Riset tentang kode yang ditulis AI justru mempertajam kemacetan tinjauan, bukan menciptakannya. Studi NYU terhadap saran GitHub Copilot, yang diterbitkan di IEEE S&P pada 2022, menemukan sekitar 40% cuplikan yang dihasilkan mengandung pola yang dapat dieksploitasi di 18 kategori CWE. Kajian Stanford tentang perilaku pengembang, yang diterbitkan di ACM CCS pada 2023, menemukan efek yang lebih besar dampaknya: pengembang yang menggunakan asisten lebih yakin kode mereka aman, padahal kode yang dihasilkan terukur lebih tidak aman. Keluaran yang lebih banyak ditambah kepercayaan diri yang lebih besar adalah masalah bagi proses tinjauan.

Model bahasa sebagai peninjau mengubah satu variabel dalam persamaan itu — throughput. Model ini dapat membaca setiap pull request, dengan biaya per token alih-alih per pengguna, dan dapat diminta secara eksplisit untuk menjawab enam pertanyaan di atas. Model ini tidak mengubah pertanyaannya, dan tidak memperoleh dua sifat yang membuat tinjauan dapat dipercaya: determinisme dan kemampuan mengeksekusi kode. Diff yang sama yang ditinjau dua kali dapat menghasilkan temuan yang berbeda, tingkat keparahan bergeser antar-proses, dan peninjau tidak dapat membuktikan bahwa jalur yang ditandai dapat dijangkau.

OrcaCode Review adalah bentuk produk dari gagasan itu, dan layak dicermati dengan saksama karena pilihan desainnya mengungkap mode kegagalan. Ulasan yang mengisolasi kasus gagal sebagai komentar spesifik dan dapat direproduksi — kunci ini masih berubah seiring waktu, sehingga tagihan yang dicoba ulang menghasilkan kunci baru dan dapat menagih dua kali, inilah perubahan satu baris — melakukan tugas yang dilakukan seorang reviewer. Ulasan yang melaporkan "potensi masalah keamanan" tanpa reproduksi melakukan analisis pola dengan presisi yang lebih buruk daripada pencocok pola. Dan mesin aturan-dan-gerbang yang diterbitkan di bawah lisensi terbuka membuat klaim implisit yang layak diperiksa: bahwa pertimbangan reviewer juga harus dapat ditinjau.

Susunan dua lapis yang berfungsi

Dengan scanner yang deterministik dan reviewer yang probabilistik, susunan yang bertahan dalam praktik adalah memberikan kepada masing-masing pekerjaan yang memang menjadi keunggulannya. Scanner berjalan pada setiap push: dalam hitungan detik, tanpa model, tanpa variasi, menangkap secret, panggilan API berbahaya, deserialisasi yang tidak aman, dan impor halusinatif. Reviewer berjalan pada setiap pull request: dalam hitungan menit, didukung model, menangkap logika yang tersirat di sela-sela baris — apakah pemeriksaan otorisasi berjalan sebelum fetch, apakah kunci idempotensi terikat pada nilai yang stabil, apakah rute baru mewarisi guard.

Lalu lapisan yang orang lewatkan: gate. Temuan yang tidak memblokir merge hanyalah notifikasi, dan notifikasi dibaca pada hari Jumat. Gate harus sempit dan harus absolut — temuan kritis memblokir, sisanya hanya komentar — dan pengecualiannya harus dituliskan, karena nilai sebuah gate bukanlah bahwa ia menghentikan temuan pertama, melainkan bahwa ia membuat setiap jalan pintas terlihat.

Meninjau perubahan, bukan basis kode.

Disiplin praktis untuk tinjauan diff adalah rangkaian singkat, dan nilainya adalah bahwa hal itu dapat diajarkan dalam satu sore. Baca diff untuk melihat apa yang ditambahkan ke permukaan serangan, bukan untuk melihat apa yang diubahnya. Untuk setiap titik masuk baru, ikuti input satu langkah melewati tempat diff berakhir — kerentanan biasanya ada di fungsi yang dipanggilnya, yang tidak dibaca oleh penulis. Untuk setiap rute baru, periksa pendaftaran guard. Untuk setiap dependensi baru, periksa apakah dependensi itu ada dan apakah orang lain telah menerbitkan nama tersebut. Untuk setiap nilai konfigurasi baru, tanyakan apa nilai bawaannya di tempat ia benar-benar akan diterapkan.

Semua itu tidak memerlukan penguasaan bahasa yang mendalam, itulah sebabnya metode ini dapat diterapkan pada peninjau yang bukan spesialis keamanan. Yang diperlukan adalah peninjau melihat diff, bukan berkasnya, karena seluruh metode bergantung pada mengetahui apa yang baru.

Dan batas yang jujur: tinjauan diff tidak dapat menemukan cacat yang sudah ada sebelum diff. Jika aplikasi belum pernah memiliki tinjauan baseline, pekerjaan keamanan dengan nilai tertinggi yang tersedia bukanlah reviewer yang lebih baik — melainkan satu tinjauan menyeluruh yang sengaja dilakukan atas basis kode, di area-area yang bersinggungan dengan uang, identitas, dan akses file, dengan enam pertanyaan di atas. Setelah itu, setiap tinjauan diff berikutnya melindungi sesuatu yang telah diperiksa sekali. Sebelum itu, setiap tinjauan diff melindungi sesuatu yang tidak diketahui.