Satuan 7 / 11

Tinjauan Kode Aman dan Analisis Statis: Menemukan Kerentanan dengan Kecerdasan Buatan

Keuntungan:

  • Kemampuan untuk menggunakan kecerdasan buatan sebagai mata kedua dan menandai kerentanan kelas OWASP (injeksi, rahasia keras, kontrol akses) dalam kode dengan memberikan konteks
  • Kemampuan untuk menghilangkan kesalahan positif yang dihasilkan oleh kecerdasan buatan dengan konteks dan mencegah memperlakukan setiap temuan sebagai kerentanan nyata tanpa memvalidasinya
  • Kemampuan untuk mengenali bahwa perbaikan yang disarankan oleh kecerdasan buatan dapat menimbulkan kerentanan/bug baru dan meneruskan setiap patch melalui gerbang peninjauan dan pengujian

Kerentanan dalam perangkat lunak adalah salah satu kerentanan yang paling mahal karena sudah tertanam dalam produk sejak awal dan didistribusikan ke jutaan pengguna. Peninjauan kode aman adalah proses membaca kode sumber baris demi baris dan menangkap kerentanan — injeksi SQL, kerentanan autentikasi, kata sandi hardcode, otorisasi yang salah — sebelum dimasukkan ke dalam produksi. Jika dilakukan dengan tangan, lambat dan melelahkan; Sangat mudah untuk melewatkan kerentanan dalam basis kode yang besar.

AI sangat hebat dalam peninjauan kode karena dua alasan: kode juga merupakan bahasa, dan AI bagus dalam pengenalan pola. AI dapat dengan cepat menandai pola berbahaya dalam sebuah kode (memasukkan masukan pengguna langsung ke dalam kueri, penyimpanan data tidak terenkripsi, validasi masukan hilang), menjelaskan mengapa setiap pola tersebut berisiko, dan menyarankan perbaikan. Namun AI tidak melihat keseluruhan konteks pengoperasian kode (input mungkin dibersihkan di lapisan lain), AI mungkin menciptakan kerentanan yang tidak ada (positif palsu) atau melewatkan kerentanan nyata (negatif palsu), dan yang paling penting, "perbaikan" yang diusulkannya dapat menimbulkan kerentanan atau bug baru. AI adalah mata kedua dan penunjuk dalam tinjauan kode; Pengembang dan pakar keamanan memutuskan apakah suatu temuan merupakan kerentanan nyata dan apakah perbaikannya benar dan aman.

Langkah-langkah peninjauan kode

  1. Berikan ruang lingkup dan konteks. Bahasa apa, kerangka apa, di mana kode ini menerima masukan, di mana memberikan keluaran, di lapisan mana ia bekerja? Peninjauan kode tanpa konteks menghasilkan positif palsu.
  2. Pindai pola berbahaya. Cari kelas kerentanan AI yang diketahui (seperti OWASP Top 10): injeksi, autentikasi, pengungkapan data sensitif, kontrol akses.
  3. Apakah setiap temuan dapat dibenarkan. Untuk setiap flag: garis yang mana, kelas kerentanan yang mana, bagaimana cara mengeksploitasinya, apa buktinya. Temuan yang tidak beralasan tidak ditanggapi dengan serius.
  4. Hilangkan positif palsu. Apakah masukan benar-benar dihapus, apakah jalur tersebut benar-benar dapat diakses — periksa konteksnya.
  5. Verifikasi perbaikannya. Konfirmasikan bahwa patch yang direkomendasikan oleh AI benar-benar menutup kerentanan, tidak menimbulkan kerentanan/bug baru, dan telah lulus pengujian.
  6. Persetujuan manusia. Pengembang + pakar keamanan meninjau temuan dan perbaikan; Begitulah caranya memasuki repositori kode.

Ketentuan: SAST (Pengujian Keamanan Aplikasi Statis - pengujian keamanan statis yang menganalisis kode sumber tanpa menjalankannya). DAST (Dinamis — pengujian dinamis yang menguji aplikasi yang berjalan secara eksternal). OWASP Top 10 adalah daftar standar kerentanan aplikasi web yang paling umum. Injeksi adalah kerentanan yang disebabkan oleh penafsiran masukan pengguna sebagai perintah/kueri (misalnya injeksi SQL). Kueri berparameter adalah metode yang tepat untuk mencegah injeksi dengan memisahkan input dari kode.

Tabel kelas kerentanan umum

Kelas kerentanan

Gejala (dalam kode)

solusi yang tepat

jebakan AI

injeksi SQL

Menggabungkan input ke dalam kueri

Kueri berparameter

Dapat mengabaikan sanitasi

rahasia kode keras

Kata sandi/kunci kode

Brankas rahasia (lemari besi), env

Positif palsu (sampel/tes)

Otentikasi lemah

Kontrol hilang/salah

Kontrol yang kuat dan terpusat

meleset dari konteks

Kontrol akses salah

Tidak ada pemeriksaan otorisasi

Otorisasi sisi server

Tidak memahami aliran yang rumit

Pengungkapan data sensitif

Penyimpanan/pencatatan bebas kata sandi

Enkripsi, penyamaran

Tidak dapat mengetahui kekritisan

Serialisasi tidak aman

Deserialisasi data yang tidak dapat diandalkan

Penguraian yang aman

Melewatkan pola langka

tiga kasus mini

Kasus 1 — Menangkap suntikan sebenarnya. Pengembang meminta AI memeriksa fungsi akses data. AI menandai baris di mana nilai userId dari pengguna digabungkan langsung ke dalam teks SQL dan mengatakan "ini adalah injeksi SQL klasik, ubah menjadi kueri berparameter"; Memberikan koreksi sampel. Pengembang mengonfirmasi bahwa masukan belum dibersihkan di tempat lain, memverifikasi bahwa masukan tersebut benar-benar merupakan kerentanan, mengimplementasikan kueri parameterisasi yang disarankan, dan menulis pengujian. AI menyoroti kerentanannya; verifikasi dan pengujian koreksi berasal dari pengembang.

Kasus 2 — Rahasia tetap positif palsu. AI melihat baris kata sandi = "test1234" dalam file dan mengatakan "penting: kata sandi hardcoded". Pengembang memeriksa konteksnya: ini adalah file pengujian unit, data pengujian tiruan, tidak dirilis ke produksi dan tidak di-porting ke sistem nyata. Temuan ini merupakan hasil positif palsu. Pengembang mendokumentasikan hal ini tetapi tidak mengambil tindakan karena ini bukan rahasia sebenarnya. Pelajaran: Tanda "rahasia" AI harus dihilangkan berdasarkan konteks; Tidak setiap string adalah rahasia.

Kasus 3 — Perbaikan kerentanan baru. AI mengusulkan perbaikan untuk kerentanan XSS (skrip lintas situs); tetapi kode yang dia sarankan menghapus masukan di tempat yang salah dan melewatkan pengkodean keluaran di area lain; Akibatnya, kesenjangan tersebut tidak dapat ditutup sepenuhnya. Pakar keamanan meninjau perbaikan, memperhatikan pengkodean yang hilang, dan memperbaikinya pada lapisan yang benar. Pelajaran: Patch yang direkomendasikan AI tidak aman secara otomatis; Setiap perbaikan ditinjau dan diuji.

Perintah lemah / Perintah kuat

Perintah yang lemah:

Apakah ada celah dalam kode ini, perbaiki: [kode]

Perintah ini tidak memberikan konteks (bahasa, kerangka kerja, sumber masukan), tidak meminta pembenaran, tidak mempertanyakan kesalahan positif, dan terbuka untuk menerima begitu saja koreksi yang dihasilkan oleh AI. AI memadukan tanda-tanda kerentanan nyata dan tidak ada.

Perintah yang kuat:

Peran Anda: asisten yang merupakan MATA KEDUA bagi pengembang dalam peninjauan kode aman. Pengambilan keputusan; pertimbangkan perbaikan yang diterapkan secara langsung. Kode: [tentukan bahasa/kerangka kerja]. Konteks: fungsi ini [sumber input: mis. menerima [permintaan HTTP eksternal], menulis ke [tujuan keluaran]. Tugas Anda: (1) tandai kemungkinan kerentanan dengan kelas OWASP, berikan nomor baris + mengapa berisiko + cara mengeksploitasi + bukti untuk setiap kerentanan, (2) tulis setidaknya 1 skenario positif palsu untuk setiap temuan (misalnya jika masukan dibersihkan di lapisan lain), (3) menyarankan perbaikan tetapi dengan tanda "[tinjauan + tes tulis]"; Evaluasi juga apakah perbaikan tersebut menimbulkan kerentanan/bug baru. Menambahkan kerentanan palsu.[kode]

Perintah yang kuat memberikan konteks, meminta kelas OWASP dan bukti, mempertanyakan positif palsu dan risiko remediasi, memaksa peninjauan manusia.

Templat cepat yang dapat disalin

TEMPLATE PEMINDAIAN KERENTANAN Periksa kode [bahasa/kerangka kerja] untuk OWASP Top 10. Untuk setiap temuan yang mungkin: nomor baris, kelas kerentanan, mengapa berisiko, contoh eksploitasi, kekuatan bukti (tertentu/mungkin/lemah). Konteks: masukan [sumber], keluaran [target]. Menambahkan temuan palsu; Jika Anda tidak yakin, ketik "[harus diverifikasi]". Kode: [tempel]

POLA PENGHAPUSAN POSITIF YANG SALAH Untuk penemuan kode berikut, buatlah daftar skenario yang TIDAK memiliki kerentanan nyata: dapatkah masukan dihapus pada lapisan lain, apakah jalur ini dapat diakses, apakah nilai ini merupakan pengujian/sampel, apakah kerangka kerja dilindungi secara otomatis. Tulis cara mengonfirmasi untuk masing-masingnya. Temuan: [tempel]

PERBAIKI TEMPLATE EVALUASI Merekomendasikan perbaikan untuk kerentanan berikut; lalu kritik perbaikan Anda sendiri: (1) apakah ini benar-benar menutup kerentanan, (2) apakah ini menimbulkan kerentanan/bug baru, (3) pengujian apa yang harus saya tulis (kasus positif dan negatif), (4) dampak kinerja/fungsi. Saya akan meninjau dan menguji perbaikannya. Kerentanan + kode: [tempel]

TEMPLATE PENGAJARAN POLA AMAN untuk kelas kerentanan [mis. Injeksi SQL] secara komparatif menunjukkan pola pengetikan yang aman dan pola kesalahan umum dalam bahasa/kerangka ini. Aturan umum + berikan contoh kode; tapi saya ingin Anda menanyakan konteksnya sebelum menerapkannya dalam kode saya. Bahasa/kerangka: [tulis]

Kesalahan umum

  • Tinjau tanpa konteks. Tanpa bahasa, kerangka kerja, dan konteks input/output, AI mengacaukan temuan nyata dan palsu; Pastikan untuk memberikan konteks.
  • Salah mengira setiap tanda sebagai kelemahan nyata. AI menghasilkan positif palsu (data pengujian, masukan dibersihkan di lapisan lain); Saring setiap temuan dengan konteksnya.
  • Menerapkan koreksi AI secara membabi buta. Patch yang direkomendasikan mungkin menimbulkan kerentanan/bug baru; meninjau dan menulis tes.
  • Mempercayai hal negatif palsu. Bahkan jika AI mengatakan "tidak ada kerentanan", periksa sendiri jalur kritisnya; Pemindaian statis tidak mendeteksi setiap kerentanan.
  • Memberikan kode/rahasia pada alat luar. Kode pribadi dan rahasia sebenarnya (kunci, kata sandi) adalah kekayaan intelektual dan kerentanan; menganonimkan atau menggunakan alat perusahaan yang terisolasi.
Tip: Saat memiliki kode review AI, filter yang paling efisien adalah dengan menanyakan “kekuatan bukti” (tertentu/mungkin/lemah) untuk setiap temuan. Sebagian besar temuan yang ditandai “lemah” adalah hasil positif palsu; Anda mengalokasikan energi Anda pada orang-orang yang "pasti".
Perhatian: Perbaikan keamanan yang diusulkan AI tidak boleh masuk ke gudang tanpa diuji. Sebuah "perbaikan" yang salah dapat membiarkan kerentanan tetap terbuka dan menyebabkan kesalahan fungsional dalam produksi; Setiap patch melewati gerbang peninjauan dan pengujian.

Singkatnya

Peninjauan kode yang aman adalah cara termurah untuk mengetahui kerentanan sebelum masuk ke tahap produksi, dan karena kode adalah sebuah bahasa, AI menjadi mata kedua yang ampuh dalam hal ini: menandai pola berbahaya, menjelaskan risiko, dan menyarankan perbaikan. Namun AI tidak melihat keseluruhan konteks operasi, menghasilkan positif palsu dan negatif palsu, dan patch yang direkomendasikannya dapat menimbulkan kerentanan baru. Jadi peninjauan memiliki enam langkah (konteks, penyaringan, pembenaran, penghapusan positif palsu, verifikasi perbaikan, persetujuan manusia) dan keputusan ada di tangan pengembang dan pakar keamanan. Tiga prinsip: tidak ada temuan yang ditafsirkan tanpa konteks, setiap tanda dihilangkan sesuai konteks, tidak ada perbaikan yang disimpan tanpa diuji. Dan kode/rahasia tersebut tidak pernah diberikan kepada alat luar tanpa anonimisasi.

Tugas aplikasi

Ambil contoh cuplikan kode (baik menghapus bagian sensitif dari kode Anda sendiri atau kode contoh yang memiliki kerentanan). Minta AI memeriksanya dengan templat “Pemindaian Kerentanan”; Terapkan template "Eliminasi Positif Palsu" untuk setiap temuan dan hilangkan temuan yang sebenarnya. Ambil koreksi terhadap temuan paling serius dengan templat "Evaluasi Remediasi", tinjau sendiri dan tulis satu kasus uji positif + satu kasus uji negatif. Catat berapa banyak temuan yang merupakan hasil positif palsu.

daftar periksa

  • [ ] Saya memberikan konteks bahasa, kerangka kerja, dan input/output sebelum meninjau kode.
  • [ ] Saya menanyakan nomor baris, kelas kerentanan, jalur eksploitasi, dan bukti untuk setiap temuan.
  • [ ] Saya menyaring setiap temuan untuk mencari positif palsu dengan konteks.
  • [ ] Saya tidak menerapkan koreksi AI secara membabi buta; Saya meninjau dan menulis tes.
  • [ ] Meskipun ada keluaran "Tidak ada kerentanan", saya memeriksa sendiri jalur kritisnya.
  • [ ] Saya menganonimkan kode/rahasia atau menggunakan peralatan perusahaan yang terisolasi.
  • [ ] Saya telah melewati penemuan dan perbaikan melalui persetujuan pengembang + keamanan.