Sebuah pull request menambahkan ekspor CSV. Tombolnya bekerja, berkas berisi baris yang diharapkan, dan pengujian lulus. Sebelum kode digabungkan, masih ada satu pertanyaan yang perlu dijawab: bisakah orang yang tidak berhak mengambil berkas itu?

Di situlah tinjauan keamanan dimulai. Tinjauan keamanan kode buatan AI berarti memeriksa perubahan tertentu terhadap aturan akses, penanganan data, dan lingkungan operasi aplikasi, lalu memverifikasi perbaikannya. Hasilnya perlu menjelaskan apa yang diperiksa, apa yang didukung bukti, dan apa yang masih belum pasti.

Asal kode tidak menjawab pertanyaan tersebut. Alat pemrograman AI dapat menghasilkan implementasi yang masuk akal sambil melewatkan aturan yang tidak pernah diberikan kepadanya. Manusia pun bisa melakukan kesalahan serupa. Untuk memahami alasan di balik pemeriksaan ini, baca mengapa kode buatan AI tetap perlu tinjauan keamanan. Artikel ini berfokus pada pelaksanaannya.

Mulai dari perubahan dan aturannya

“Tinjau keamanan aplikasi ini” memberi peninjau terlalu sedikit pegangan. Diff tertentu, kebutuhan yang diimplementasikannya, dan kode terkait merupakan titik awal yang lebih baik.

Untuk fitur ekspor, cakupannya bisa meliputi siapa yang boleh meminta ekspor, data apa yang harus disertakan, tempat penyimpanan berkas, dan siapa yang boleh mengunduhnya. Keputusan tersebut bisa tersebar di handler permintaan, pekerjaan latar belakang, dan konfigurasi penyimpanan. Meninjau tombol saja akan melewatkan sebagian besar perilaku fitur.

Tuliskan perilaku yang diharapkan sebelum menilai implementasi. Apakah akses dimiliki individu, tim, atau tenant? Bolehkah ekspor dibagikan? Berapa lama berkas boleh tersedia? Ini keputusan produk yang berdampak pada keamanan. Peninjau perlu menunjukkan jawaban yang belum tersedia, bukan mengarang kebijakan yang kebetulan cocok dengan kode.

Sertakan versi dependency dan konfigurasi yang diperlukan untuk memahami perubahan. Hindari kredensial serta data privat pelanggan dalam materi tinjauan; gunakan konteks yang disamarkan dan contoh sintetis jika memungkinkan.

Telusuri fitur melampaui diff

Ikuti satu permintaan normal dari pemanggil sampai keluaran akhir. Ulangi penelusuran untuk pemanggil yang seharusnya ditolak.

Dalam alur ekspor, memeriksa izin saat pengguna mengeklik tombol hanyalah satu langkah. Pekerjaan dalam antrean membutuhkan konteks akun yang tepercaya. Kuerinya harus menerapkan batas tenant atau kepemilikan yang benar. Berkas hasilnya juga membutuhkan aturan akses. Jika unduhan bersifat privat, melindungi handler tetapi menaruh hasilnya di URL publik berarti pekerjaan belum selesai.

Contoh ini bersifat hipotetis. Tujuannya menunjukkan bagaimana tinjauan bergerak dari perubahan kode kecil menuju perilaku yang penting, tanpa mengklaim produk tertentu memiliki kelemahan tersebut.

Periksa juga jalur yang kurang terlihat. Apa yang masuk ke log saat ekspor gagal? Bisakah percobaan ulang memakai berkas dari permintaan lain? Apakah keputusan aplikasi tetap benar jika izin pengguna berubah saat pekerjaan menunggu? Jawaban pertanyaan terakhir bergantung pada kebijakan produk, tetapi implementasinya harus memiliki jawaban eksplisit.

Di bagian ini, kode hasil AI perlu dibaca cermat. Periksa asumsi tentang identitas, perilaku pustaka, pengaturan bawaan, dan penanganan kesalahan. Nama metode yang tampak familier bukan bukti bahwa versi yang terpasang mendukung perilaku yang diandalkan.

Pilih pemeriksaan yang menjawab masalah

Linter dapat menemukan pola yang dilarang. Analisis statis dapat menandai aliran data mencurigakan. Pemindaian dependency dapat mengenali paket dengan kerentanan yang diketahui. Pengujian dapat memeriksa aturan akses atau jalur kegagalan. Masing-masing memberi bukti berguna dengan batasnya sendiri.

Untuk contoh ekspor, pertanyaan utamanya adalah apakah akun tanpa izin bisa mengambil data privat. Laporan dependency yang bersih tidak menjawabnya. Pengujian jalur unduhan nyata menggunakan akun yang salah lebih dekat dengan kebutuhan tersebut.

OWASP ASVS menyediakan persyaratan verifikasi kontrol keamanan aplikasi. Pilih persyaratan yang sesuai dengan perubahan dan catat versi acuannya. Memeriksa beberapa persyaratan tidak membuktikan kepatuhan terhadap seluruh standar.

NIST SSDF 1.1 menempatkan praktik pengembangan aman di sepanjang siklus perangkat lunak. Pendekatan ini membantu mengatur pekerjaan: tinjauan, pengujian, pemeriksaan dependency, dan kontrol operasional saling mendukung dari waktu ke waktu. Satu hasil alat tidak mencakup semuanya.

Peninjau AI dapat membantu menemukan asumsi berisiko atau mengusulkan pengujian. Periksa temuannya terhadap kode dan perilaku sebenarnya. Perlakukan saran perbaikan sebagai perubahan baru yang perlu ditinjau, terutama jika menyentuh izin atau penanganan kegagalan.

Tulis temuan yang bisa ditindaklanjuti

“Perbaiki kontrol akses” membuat penulis harus mencari lagi dari awal. Temuan yang berguna menunjukkan jalur, pemanggil, keputusan yang hilang, dan akibatnya.

Untuk alur ekspor hipotetis tadi, contoh temuannya:

Handler unduhan mencari ekspor berdasarkan ID lalu mengembalikan berkas tanpa memeriksa apakah pemanggil terautentikasi termasuk dalam akun pemilik. Pengguna yang memperoleh ID ekspor akun lain dapat membaca data akun tersebut. Tegakkan aturan akses akun sebelum mengembalikan berkas, lalu verifikasi unduhan yang diizinkan maupun ditolak.

Dalam tinjauan nyata, sertakan berkas dan baris terkait, revisi input, serta pengamatan yang mendukung klaim. Jika hanya memeriksa sumber, nyatakan demikian. Jika berhasil mereproduksi perilaku, catat lingkungan dan hasil yang sudah dibersihkan. Jangan menyebut jalur yang mungkin terjadi sebagai insiden yang telah dibuktikan.

Perbaikan harus sesuai dengan model izin yang berlaku. Pemeriksaan ketat khusus pemilik bisa merusak berbagi data yang sah dalam tim. Tautan bertanda tangan yang dapat diakses publik mungkin memang disengaja, tetapi cakupan, masa berlaku, dan distribusinya tetap harus sesuai kebutuhan. Peninjau membutuhkan konteks produk untuk membedakan kelemahan dari desain yang diterima.

Verifikasi perbaikan melalui jalur sebenarnya

Kepercayaan terhadap perbaikan tumbuh ketika kasus awal yang gagal diuji ulang dan alur sah tetap berfungsi. Untuk perubahan ekspor, pemeriksaan dapat mencakup:

  • Akun berizin dapat meminta dan mengambil ekspor yang dimaksud.
  • Akun lain tidak dapat mengambilnya melalui rute unduhan.
  • Kredensial yang hilang atau kedaluwarsa menghasilkan respons yang tepat tanpa membocorkan isi berkas.
  • Berkas, log, dan respons cache mengikuti aturan akses serta retensi data yang sama.

Daftar ini merupakan saran untuk contoh, bukan laporan hasil uji. Tambahkan kasus berdasarkan desain sebenarnya, termasuk berbagi data, perubahan izin, dan percobaan ulang pekerjaan jika relevan.

Tempatkan verifikasi dekat dengan batas yang diklaim. Uji fungsi bantuan dapat membuktikan perilaku fungsi itu. Uji tersebut tidak menunjukkan bahwa semua rute memanggilnya atau penyimpanan produksi bersifat privat. Kesimpulan itu memerlukan pemeriksaan integrasi dan runtime.

Untuk latihan yang lebih kecil dan dapat dijalankan, tutorial otorisasi Linmas memperagakan pembacaan lintas pengguna dan perbaikan kepemilikan menggunakan data sintetis dalam memori. Batasnya jelas: tutorial tidak menguji sesi nyata, basis data, atau deployment.

Tutup tinjauan dengan keputusan dan rekaman

Tinjauan siap diputuskan ketika tim dapat menunjukkan perubahan yang diperiksa, temuan, perbaikan beserta verifikasinya, dan pekerjaan yang belum selesai. Penanggung jawab perubahan tetap harus memutuskan apakah risiko yang tersisa dapat diterima.

Jangan memperluas kesimpulan yang sempit. “Uji unduhan lintas akun lulus untuk revisi ini” adalah pernyataan berguna. Itu tidak membuktikan seluruh jalur ekspor, kebijakan penyimpanan, atau revisi mendatang aman. Tinjau kembali bukti ketika batas yang relevan berubah.

Linmas mengatur pekerjaan ini melalui penentuan cakupan, pemilihan skill, tinjauan, perbaikan, dan verifikasi. Review Capsule dapat menyimpan identitas input yang dievaluasi, temuan ternormalisasi, keputusan kebijakan, dan metadata eksekusi. Rekaman tersebut membantu peninjau lain memahami pekerjaan yang dilakukan. Rekaman itu tidak menggantikan penilaian mereka atau menyertifikasi aplikasi.

Untuk pull request berikutnya, pilih satu operasi sensitif dan ikuti dari pemanggil hingga hasilnya. Tuliskan aturan yang harus dipatuhi, lalu simpan bukti yang menunjukkan apakah aturan tersebut berlaku.

Sumber dan catatan editorial

Diperbarui 29 September 2026. Skenario ekspor CSV dan contoh temuan merupakan contoh editorial, bukan laporan kerentanan yang telah diuji. Sumber primer yang ditautkan diperiksa pada tanggal pembaruan.