Bisakah pengujian keamanan AI menggantikan SAST, DAST, dan pentest?

Pertanyaan yang berguna adalah di mana agen layak dipercaya. Saya percaya agen dapat memperluas cakupan peninjauan, menghubungkan petunjuk antarfile, membuat pengujian yang terarah, dan mengubah jejak scanner yang rumit menjadi perbaikan yang dipahami developer. Saya tidak percaya agen dapat menyimpulkan aturan otorisasi perusahaan dari nama rute, membuktikan bahwa setiap batas tenant bertahan, atau memutuskan bahwa alur keuangan yang aneh adalah penyalahgunaan tanpa manusia yang menyatakan aturannya. Perlakukan agen sebagai peninjau aktif dalam program pengujian berlapis, bukan sebagai program itu sendiri.

Peninjauan agen adalah penafsir, bukan kelas pengujian baru

Agen AI mengubah cara bukti dikumpulkan dan dipahami, bukan menciptakan jenis bukti baru. Jika ia membaca source tanpa menjalankan aplikasi, ia melakukan bentuk peninjauan statis yang fleksibel. Jika ia mengirim permintaan ke target yang berjalan, ia melakukan pengujian dinamis. Jika ia mengeksplorasi tujuan, mengubah taktik, dan mengikuti perilaku tak terduga, ia menyerupai penetration tester, tetapi kemiripan itu tidak memberinya otoritas atau konteks bisnis seorang penguji.

Perbedaan ini penting saat vendor mengatakan agennya «menggantikan scanner». Tanyakan apa yang benar-benar dapat diamati sistem. Apakah sistem menerima seluruh repository, kode yang dihasilkan, build flag, kebijakan infrastruktur, dan lockfile dependensi? Bisakah ia melakukan autentikasi sebagai beberapa pengguna dan memverifikasi status database setelah setiap permintaan? Apakah ia tahu tindakan mana yang dilarang oleh kebijakan, bukan sekadar tidak ada di antarmuka? Penjelasan yang rapi tidak dapat memperbaiki input yang hilang.

Agen memang sangat baik dalam menggabungkan sinyal lemah. Aturan konvensional mungkin menandai parameter permintaan yang mencapai query builder. Agen dapat memeriksa wrapper, melihat bahwa satu call site tidak menyertakan predikat tenant, menyusun permintaan uji, dan menjelaskan mengapa helper yang dianggap aman ternyata tidak aman di jalur itu. Ia juga dapat menolak kandidat saat nilainya melewati API berparameter yang benar-benar aman. Ini triage yang lebih baik, bukan bukti bahwa analisis statis atau dinamis sudah usang.

Batas yang tegas ada di antara peninjauan dan verifikasi. Peninjauan bertanya, «Apakah implementasi ini terlihat tidak aman berdasarkan materi yang dapat saya lihat?» Verifikasi bertanya, «Dalam kondisi yang dinyatakan, dapatkah pelaku ini menyebabkan hasil yang dilarang?» AI membantu keduanya, tetapi security gate harus mencatat klaim mana yang dibuat. Tim dirugikan ketika pengamatan peninjauan yang fasih dinaikkan menjadi exploit terverifikasi, atau ketika satu upaya exploit yang gagal dianggap sebagai bukti keamanan.

Perilaku model menambahkan perbedaan lain: kemampuan bukan keterulangan. Agen mungkin menemukan jalur yang halus dalam satu kali proses dan melewatkannya setelah model, prompt, indeks retrieval, atau kebijakan alat berubah. Simpan prompt, izin alat, file yang diambil, permintaan yang dibuat, dan identitas model saat hasilnya penting. Lalu ubah temuan yang terkonfirmasi menjadi pengujian dengan kondisi lulus yang tidak bergantung pada model untuk menemukan kembali idenya sendiri.

SAST tetap menguasai cakupan source yang dapat diulang

SAST tetap menjadi cara termurah untuk menerapkan pemeriksaan stabil pada setiap perubahan di codebase besar. SAST dapat membuat daftar source dan sink, menerapkan API terlarang, memeriksa aliran data, serta melaporkan revisi tepat yang dianalisis. Aturan deterministik menghasilkan hasil yang sama besok, penting ketika gate rilis membutuhkan alasan yang dapat diaudit untuk lulus atau gagal.

Agen menambahkan konteks yang sering tidak dimiliki rule engine. Ia dapat mengikuti wrapper khusus proyek, membaca komentar dengan skeptis, membandingkan handler dengan handler di sekitarnya, dan mengusulkan query untuk pola baru. Ia dapat melihat kelalaian yang mencurigakan, misalnya sembilan endpoint memanggil authorizeProject() sementara endpoint kesepuluh langsung memuat record. Ia juga berguna saat kode yang dihasilkan atau framework yang asing mengalahkan rule pack standar.

Namun, cakupan source agen biasanya lebih sulit dibuktikan. Context window, peringkat retrieval, file yang diabaikan, artefak yang dihasilkan, dan timeout alat dapat membuat kode tidak terbaca. Meminta «tinjau repository ini untuk injection» tidak membuktikan bahwa setiap sink telah dicapai. Laporan SAST setidaknya dapat menyatakan file, aturan, dan revisi mana yang dianalisis. Agen memerlukan catatan cakupan yang setara sebelum dapat mengambil alih gate wajib.

NIST SP 800-218 memberi rekomendasi yang masuk akal di sini: gunakan analisis kode sejak awal dan verifikasi fitur keamanan serta mitigasi secara manual. Nilainya ada pada kombinasinya. Aturan stabil menangkap bentuk cacat yang sudah dikenal pada setiap commit, agen menyelidiki pengecualian, menulis pengujian regresi terfokus, dan membantu menyempurnakan aturan saat pola yang sama berulang. Menghapus SAST karena agen menemukan beberapa bug cerdas menukar keluasan yang terukur dengan anekdot yang mengesankan.

SAST juga melihat kode yang mungkin tidak pernah dijangkau pengujian yang berjalan: jalur error, feature flag, utilitas migrasi, endpoint admin yang tidak aktif, dan cabang khusus platform. SAST tidak dapat memberi tahu apakah lingkungan yang di-deploy mengaktifkan jalur itu. Ketidakpastian ini alasan untuk menambahkan bukti runtime, bukan alasan membuang cakupan statis.

Ada batas untuk apa yang layak menjadi aturan SAST pemblokir. Pola yang tepat untuk primitive kriptografi terlarang dapat langsung memblokir. Heuristik luas yang menanyakan apakah pemeriksaan otorisasi «terlihat cukup dekat» biasanya sebaiknya membuat tugas peninjauan sampai tim mengukur presisinya. Agen dapat membantu menaikkan heuristik menjadi aturan dengan mengumpulkan contoh benar, contoh tandingan, dan fungsi wrapper yang umum dalam codebase itu. Ini menjaga gate tetap ketat tanpa mengajari developer untuk mengabaikannya.

Perbaikan yang dihasilkan memerlukan pemeriksaan yang sama seperti temuan. Model mungkin membungkam taint trace dengan menambahkan validasi di lapisan yang salah, menangkap exception lalu gagal terbuka, atau mengganti panggilan berbahaya sambil mengubah perilaku. Jalankan bukti awal terhadap patch, jalankan pengujian fungsional biasa, dan tinjau kontrol baru di tempat kepercayaan ditetapkan. Pemindaian ulang yang bersih hanya membuktikan bahwa aturan awal tidak lagi cocok.

DAST membuktikan perilaku yang tidak dapat diungkap repository

DAST mengamati aplikasi yang benar-benar berjalan, termasuk aturan proxy, header, serialisasi, middleware autentikasi, default framework, dan kesalahan deployment. Peninjauan source dapat mengatakan endpoint tampak terlindungi. Pengujian dinamis dapat menunjukkan rute produksi melewati middleware karena gateway menulis ulang jalurnya.

Di sinilah agen dapat membuat pengujian dinamis jauh lebih terarah. Beri agen deskripsi API, identitas uji, scope yang diizinkan, dan lingkungan sementara, lalu ia dapat membangun urutan permintaan alih-alih menyemprotkan payload generik. Ia dapat membawa pengenal sumber daya dari satu respons ke respons berikutnya, memperbarui sesi, membandingkan dua peran, dan memeriksa apakah sebuah penulisan mengubah pembacaan berikutnya. DAST konvensional sering kesulitan dengan alur stateful tersebut.

Agen tetap memerlukan batas operasi yang ketat. Crawler tidak tahu apakah mengirim email, membuat pengiriman, atau memanggil integrasi berbayar itu aman. Lingkungan uji mungkin masih terhubung ke layanan nyata. Tentukan host, akun, laju permintaan, tindakan destruktif, dan kondisi berhenti yang diizinkan di luar prompt model, lalu terapkan dalam runner. Kalimat yang berbunyi «hindari tindakan berbahaya» bukanlah kontrol.

Pertahankan baseline dinamis konvensional untuk pemeriksaan yang telah dipahami dengan baik, seperti header keamanan, file terekspos, input terpantul, probe injection umum, dan konfigurasi TLS. Pemeriksaan ini murah, dapat dibandingkan antar-rilis, dan mudah dilacak trennya. Biarkan agen menggunakan anggarannya untuk jalur terautentikasi dan perilaku berantai. Jika kedua sistem mencakup probe sederhana yang sama, pilih yang memiliki bukti lebih jelas dan variasi lebih rendah.

DAST juga dapat menciptakan rasa kelengkapan yang keliru karena hanya melaporkan apa yang berhasil dijangkaunya. Catat cakupan rute, identitas yang digunakan, feature flag, dan data awal bersama hasilnya. Pemindaian bersih terhadap akun yang hampir kosong sangat sedikit membuktikan tentang aplikasi yang cabang berbahayanya baru muncul setelah persetujuan, undangan, penagihan, atau impor data.

Pengaturan autentikasi layak memiliki buktinya sendiri. Catat bagaimana pengujian mendapatkan setiap sesi, faktor kedua atau pemeriksaan perangkat mana yang dilewati di lingkungan uji, dan apakah token memiliki klaim serta masa berlaku yang sama dengan token produksi. Token administrator yang dibuat secara manual dapat membuka cakupan yang berguna sambil melewati transisi sesi dan hak istimewa yang justru perlu diuji. Buat jalan pintas tersebut terlihat jelas dalam laporan.

Pengujian ulang dinamis harus dimulai dari urutan permintaan yang tersimpan, bukan crawl otonom baru. Putar ulang bukti yang terkonfirmasi terhadap build yang telah ditambal, verifikasi bahwa efek terlarang telah berhenti, lalu variasikan input yang berdekatan untuk mendeteksi filter yang terlalu sempit. Setelah itu, biarkan agen mengeksplorasi. Urutan ini memisahkan klaim «perbaikan memblokir exploit yang diketahui» dari klaim lebih luas bahwa kelas cacat telah dihilangkan.

Pengujian otorisasi memerlukan identitas dan hasil terlarang

Otorisasi bukan «endpoint pernah mengembalikan 403». Pengujian yang berguna menyatakan siapa yang bertindak, objek mana yang dituju, operasi apa yang dicoba, dan hasil apa yang harus tetap mustahil. Agen dapat membuat kombinasi tersebut, tetapi pemilik produk dan peninjau keamanan harus menyediakan kebijakannya.

OWASP ASVS menyatakan aplikasi perlu menegakkan kontrol akses di lapisan layanan tepercaya dan menerapkan hak istimewa minimum pada fungsi serta data. Saya setuju dengan persyaratan lapisan layanan, tetapi tim sering memverifikasinya terlalu sempit. Mereka menguji handler HTTP yang terlihat lalu melupakan background job, ekspor, indeks pencarian, subscription websocket, dan URL object storage langsung. Kebijakan yang sama harus bertahan di setiap jalur menuju objek.

Matriks eksekusi kecil mengungkap lebih banyak daripada instruksi samar untuk «menguji IDOR». Fragmen shell berikut mengasumsikan lingkungan sementara, dua bearer token, dan dokumen milik pengguna A. Fragmen ini memeriksa status serta ketiadaan penanda rahasia A dalam respons B:

base_url="https://test.example.invalid"
doc_id="d_1042"

curl -sS -D /tmp/headers.txt \
  -H "Authorization: Bearer $TOKEN_B" \
  "$base_url/api/documents/$doc_id" \
  -o /tmp/body.json

status="$(awk 'NR==1 {print $2}' /tmp/headers.txt)"
test "$status" = "403" || test "$status" = "404"
! grep -q "A_ONLY_MARKER" /tmp/body.json

Output yang diharapkan adalah tanpa output dan status keluar nol. Kegagalan CI harus menyimpan status, isi yang telah disanitasi, identitas pelaku, pemilik target, rute, dan revisi build. Jangan menyimpan kredensial aktif atau data respons yang tidak terkait.

Sekarang variasikan satu dimensi dalam satu waktu: baca versus perbarui, ID langsung versus pencarian, keanggotaan aktif versus dicabut, rute biasa versus ekspor, dan token pengguna versus token layanan. Agen dapat membuat serta menjalankan kasus-kasus itu dengan efisien. Manusia harus meninjau apakah matriks sesuai kebijakan dan apakah 404, 403, hasil kosong, atau objek yang disunting adalah hasil yang dimaksud. Jika tidak, agen mungkin merayakan perilaku yang dianggap bisnis sebagai pelanggaran.

Bukti negatif perlu ditangani dengan hati-hati. Pembaruan yang ditolak masih dapat mengungkap apakah objek ada melalui waktu respons, teks error, atau penghitung versi. Pembacaan yang ditolak dapat menaikkan jumlah tampilan atau menulis catatan audit yang berisi metadata rahasia. Putuskan efek samping mana yang diizinkan, lalu lakukan assertion terhadapnya. Pengujian keamanan yang hanya memeriksa respons dapat melewatkan saluran enumerasi yang berguna atau penulisan yang merusak.

Uji juga perubahan kebijakan selama sesi. Hapus pengguna dari proyek, pindahkan kepemilikan, nonaktifkan akun, atau persempit peran layanan, lalu gunakan kembali token lama dan koneksi yang terbuka. Waktu pencabutan yang diharapkan harus berasal dari kebijakan produk. «Pada akhirnya» tidak dapat diuji, dan pencabutan langsung mungkin tidak perlu, tetapi tim harus memilih batas waktu dan memverifikasinya pada permintaan API, pekerjaan antrean, unduhan, dan subscription langsung.

Isolasi tenant gagal di luar jalur permintaan yang jelas

Isolasi tenant memerlukan pengujian pada batas penyimpanan, cache, antrean, pencarian, file, analitik, dan administratif. Kegagalan yang umum bukan tenant_id yang hilang pada endpoint daftar utama. Kegagalan umumnya adalah jalur sekunder yang menyalin, mengindeks, menyimpan di cache, atau mengekspor data tanpa membawa konteks tenant.

Mulailah dengan dua tenant yang memuat record sengaja mirip dan masing-masing memiliki satu penanda yang jelas. Gunakan pengguna terpisah, sesi terpisah, serta, jika arsitektur memungkinkan, kredensial layanan terpisah. Uji pembuatan, pembacaan, pembaruan, penghapusan, daftar, pencarian, ekspor, impor, akses lampiran, pengiriman notifikasi, dan pemrosesan latar belakang. Setelah setiap tindakan, periksa respons yang terlihat pengguna dan status yang bertahan. Permintaan yang ditolak tetapi tetap memasukkan pekerjaan lintas tenant ke antrean adalah kegagalan.

Agen membantu karena dapat melacak pengenal melewati berbagai lapisan dan membuat permutasi yang terasa membosankan bagi manusia. Ia dapat melihat bahwa cache key menggunakan document_id sementara query database menggunakan tenant_id dan document_id. Ia dapat membandingkan worker ekspor dengan handler interaktif dan menanyakan mengapa hanya satu yang menetapkan konteks tingkat baris. Ini langkah peninjauan yang bernilai tinggi.

Agen juga dapat membuat asumsi berbahaya: nama mengisyaratkan batas. Fungsi bernama getTenantDocument mungkin menerima argumen tenant arbitrer dari permintaan. Kebijakan database mungkin ada di migrasi, tetapi tidak ada pada tabel baru. Filter pencarian mungkin diterapkan setelah hasil dihitung, sehingga membocorkan aktivitas tenant lain. Verifikasi harus memeriksa predikat yang diterapkan lalu mencoba pembacaan dan penulisan lintas tenant.

Jangan biarkan agen membuat oracle sendiri dengan membaca kode yang sama dengan yang diuji. Turunkan akses yang diharapkan dari tabel kebijakan independen yang dipelihara bersama persyaratan produk. Jika implementasi dan pengujian sama-sama salah memahami aturan yang sama, keduanya akan sepakat sempurna sambil membocorkan data.

Jalur asinkron memerlukan assertion tertunda. Picu pekerjaan ekspor, notifikasi, thumbnail, atau pengindeksan sebagai tenant A, ubah kepemilikan atau keanggotaan sebelum worker berjalan, lalu periksa ke mana hasilnya dikirim. Tentukan apakah worker harus menggunakan otoritas yang direkam saat permintaan dibuat atau memeriksa kembali otoritas saat eksekusi. Keduanya dapat benar untuk operasi tertentu, tetapi campuran yang tidak disengaja menciptakan kebocoran dan jejak audit yang rusak.

Alat administratif memerlukan identitas terpisah dan assertion pencatatan log. Akses dukungan sering melintasi batas tenant secara sengaja, sehingga aturan sederhana «tenant berbeda harus gagal» tidak tepat. Uji bahwa operator memiliki peran dan konteks kasus yang diperlukan, kebijakan yang terlihat pelanggan dipatuhi, akses berakhir, dan peristiwa audit mengidentifikasi operator alih-alih menyamar sebagai pelanggan.

Logika bisnis memerlukan cerita tentang penyalahgunaan

Pengujian logika bisnis dimulai dari cerita terlarang: pengguna mendapatkan nilai, otoritas, atau status yang seharusnya tidak mereka dapatkan dengan melakukan tindakan valid dalam urutan atau kombinasi yang tidak valid. Label kerentanan generik terlalu lemah. Penguji perlu tahu bagaimana undangan, persetujuan, kuota, pengembalian dana, kredit, transfer kepemilikan, dan pembatalan seharusnya berinteraksi.

OWASP Web Security Testing Guide meminta penguji mencoba langkah alur kerja yang dilewati, fungsi berulang, permintaan palsu, perubahan waktu, dan penyalahgunaan fitur valid. Pengantar logika bisnisnya yang lebih lama menyatakan secara tegas bahwa otomatisasi scanner tidak dapat menyediakan pengetahuan atau kreativitas khusus aplikasi. Agen modern meningkatkan otomatisasinya, tetapi tidak menghapus kesenjangan pengetahuan. Model dapat menyarankan bahwa kupon mungkin dapat digunakan kembali, tetapi tidak dapat tahu apakah penggunaan ulang itu promosi atau penipuan sampai seseorang menyatakan aturannya.

Berikan agen model status dengan transisi dan invarian yang diizinkan. Untuk alur persetujuan, invarian dapat berbunyi, «Pemohon tidak dapat menyetujui pembayarannya sendiri, termasuk setelah transfer kepemilikan.» Kemudian minta agen membuat urutan yang melibatkan perubahan peran, permintaan duplikat, pembatalan, percobaan ulang, konkurensi, dan sesi usang. Agen dapat mengeksplorasi jauh lebih banyak urutan daripada yang akan dijalankan seseorang secara manual.

Kasus sulit melibatkan konsekuensi di luar respons HTTP. Dua permintaan penukaran yang terjadi bersamaan mungkin sama-sama mengembalikan sukses, sementara rekonsiliasi berikutnya menghapus salah satunya. Pembatalan mungkin menghentikan pekerjaan yang terlihat tetapi gagal mencabut unduhan bertanda tangan. Undangan yang diterima setelah pengundang kehilangan akses dapat membuat keanggotaan yatim. Pengujian harus mengamati ledger, antrean, izin objek, dan status setelahnya, bukan hanya kode status.

Penguji manusia membuktikan nilai mereka dengan menantang model yang dinyatakan. Mereka bertanya apakah staf dukungan dapat menggabungkan fungsi yang tampaknya tidak berbahaya, apakah operator dapat memengaruhi jejak auditnya sendiri, atau apakah objek «kedaluwarsa» tetap dapat digunakan melalui saluran lain. Agen bekerja dalam tujuan dan alat yang diterimanya. Seseorang dapat melihat bahwa tujuan tersebut melewatkan bagian bisnis yang berbahaya.

Risiko dependensi lebih dari sekadar versi rentan

Pengujian dependensi memiliki empat pertanyaan terpisah: paket apa yang ada, apakah versi yang diketahui memiliki kerentanan yang dilaporkan, apakah build memperoleh artefak yang dimaksud, dan apakah aplikasi benar-benar mengekspos perilaku rentan. Software composition analysis (SCA) dan kontrol provenance menjawab tiga pertanyaan pertama lebih andal daripada peninjauan percakapan saja.

Agen berguna setelah inventaris tersedia. Ia dapat memeriksa bagaimana dependensi dipanggil, menentukan apakah fungsi yang terpengaruh dapat dijangkau, menemukan kontrol kompensasi, dan menyusun patch upgrade beserta pengujian regresi. Ia juga dapat menandai perilaku paket yang berisiko tanpa pengenal kerentanan, misalnya skrip instalasi yang mendapatkan akses jaringan atau library baru yang menerima secret di lingkungannya.

Jangan meminta model mengingat data kerentanan terkini. Berikan sumber advisori yang bertanggal, lockfile yang telah di-resolve, dan inventaris artefak yang dibangun. Memori model bukan basis data kerentanan, dan manifest paket bukan bukti tentang apa yang dikirim. SLSA provenance membuat perbedaan terkait: provenance menjelaskan dari mana, kapan, dan bagaimana artefak dibuat. Itu tidak menyatakan artefak aman.

Keterjangkauan dapat menurunkan prioritas triage, tetapi tidak boleh menghapus kepemilikan. Feature flag berubah, kode mati kembali, dan dependensi tidak langsung dipanggil dengan cara tak terduga. Catat mengapa temuan ditunda, versi serta jalur panggilan yang dinilai, dan peristiwa apa yang harus membukanya kembali. Agen dapat memelihara penalaran itu, sementara inventaris deterministik memantau peristiwanya.

Nama paket juga menciptakan jebakan identitas. Dependensi dengan nama yang diharapkan mungkin berasal dari registry yang salah, lockfile mungkin menunjuk ke lokasi yang dapat diubah, atau langkah build dapat mengunduh kode yang tidak ada dalam manifest. Periksa source yang telah di-resolve, hash, signature jika ekosistem mendukungnya, dan akses jaringan build. Agen dapat menjelaskan ketidaksesuaian, tetapi sistem build harus menerapkan source mana yang diterimanya.

Upgrade bukan otomatis perubahan yang aman. Rilis keamanan dapat mengubah parsing, default otorisasi, atau serialisasi sehingga merusak aplikasi. Buat reproduksi minimal untuk advisori, terapkan upgrade di branch terisolasi, lalu jalankan bukti keamanan dan pengujian fungsional. Bukti yang dihasilkan mendukung keputusan, sedangkan pernyataan model bahwa versi baru «seharusnya kompatibel» tidak cukup.

Positif palsu adalah masalah desain bukti

Temuan layak menghabiskan waktu developer hanya jika membawa klaim, bukti, dampak, dan jalur yang dapat direproduksi. Laporan yang dibuat AI sering terdengar lengkap sambil kehilangan salah satu bagian itu. Teks remediasi yang fasih membuat bukti lemah lebih sulit terlihat.

Wajibkan setiap temuan agen mengidentifikasi revisi dan lingkungan yang dianalisis, komponen terdampak, prasyarat penyerang, batas keamanan yang dilintasi, hasil yang diamati atau disimpulkan, langkah reproduksi, dan ketidakpastian. Tandai temuan source yang disimpulkan secara berbeda dari exploit yang dijalankan. Jika agen tidak dapat menjalankan aplikasi, ia harus menyatakannya dalam temuan, bukan menyembunyikan keterbatasan dalam catatan tingkat pemindaian.

Kemudian gunakan kosakata disposisi sederhana: terkonfirmasi, mungkin, perlu konteks, tidak dapat direproduksi, risiko diterima, atau diperbaiki. «Positif palsu» harus berarti klaim keamanan salah, bukan bahwa tim tidak menyukai tingkat keparahan atau memilih menunda pekerjaan. Mencampur keputusan-keputusan itu merusak umpan balik. Agen tidak dapat belajar aturan mana yang gagal jika setiap tiket yang tidak diinginkan menerima label yang sama.

AI dapat mengurangi noise dengan mengelompokkan trace duplikat, memeriksa sanitizer, dan menguji ulang setelah perbaikan. AI juga dapat memperbanyak noise dengan menghasilkan sepuluh variasi meyakinkan dari satu kecurigaan lemah. Hilangkan duplikasi berdasarkan akar masalah dan batas, bukan URL. Satu pemeriksaan kepemilikan yang hilang dan digunakan oleh delapan endpoint adalah satu cacat engineering dengan delapan titik paparan.

Lacak presisi berdasarkan kategori dan source pengujian. Jika laporan cross-site scripting buatan agen biasanya valid tetapi klaim race condition-nya jarang dapat direproduksi, arahkan keduanya secara berbeda. Jangan merangkum kinerja menjadi satu skor untuk jenis cacat yang tidak berkaitan. Gate harus gagal berdasarkan bukti dan kebijakan, bukan kata sifat tingkat keyakinan model.

Kepemilikan menutup lingkaran. Setiap temuan yang diterima memerlukan orang atau tim yang bertanggung jawab atas remediasi, metode pengujian ulang yang diharapkan, dan bukti tersimpan yang dapat dijalankan penguji lain. Jika laporan hanya hidup di dalam percakapan agen, laporan itu akan hilang saat percakapan, model, atau vendor berubah. Pekerjaan keamanan menjadi tahan lama saat bukti bertahan melampaui alat yang menghasilkannya.

Privasi juga penting saat triage. Source, isi permintaan, log, dan sampel database dapat memuat kredensial atau data pelanggan. Minimalkan materi yang diterima agen, samarkan transkrip yang disimpan, pisahkan data uji dari data produksi, dan terapkan aturan penanganan data organisasi yang disetujui pada penyedia model serta alatnya. Deteksi yang lebih baik tidak membenarkan menyalin seluruh insiden produksi ke prompt yang tidak terkendali.

Pentest manusia menguji asumsi di sekitar pengujian

Penetration tester yang terampil mengubah rencana saat aplikasi bertentangan dengan brief. Itulah bagian yang belum digantikan agen. Orang tersebut mewawancarai pemilik, menyelesaikan aturan yang ambigu, melihat jalan pintas operasional, meminta identitas lain, dan memutuskan kapan perilaku aneh layak mendapat rangkaian eksperimen yang lebih panjang.

Manusia juga bertanggung jawab atas penilaian dengan bukti yang tidak lengkap. Mereka dapat membedakan tindakan yang mungkin secara teknis dari jalur serangan yang kredibel, menjelaskan kegagalan gabungan kepada eksekutif dan engineer, serta merundingkan bukti yang aman saat eksploitasi dapat merusak data. Agen otonom harus berhenti di batas yang ditetapkan operatornya. Jika ia diam-diam memperluas batas itu, ia menjadi risiko keamanan lain.

Ini tidak berarti setiap rilis memerlukan engagement eksternal selama seminggu. Gunakan pengujian manusia di tempat perubahan bertemu konsekuensi: model otorisasi baru, arsitektur tenant, alur pembayaran atau kredit, bidang administratif, integrasi sensitif, migrasi besar, atau peluncuran publik. Jadwalkan pekerjaan periodik yang lebih luas berdasarkan risiko, dan uji ulang perbaikan serius. Rilis rutin tetap memerlukan cakupan otomatis.

Berikan output agen, trace SAST, cakupan DAST, catatan arsitektur, akun uji, dan asumsi yang belum terselesaikan kepada penguji. Agen dapat menangani reconnaissance dan variasi berulang sementara penguji mengejar perilaku mengejutkan. Ini membuat waktu manusia lebih produktif tanpa berpura-pura bahwa perannya tidak diperlukan.

Waspadai klaim «pentest otonom» yang diukur dari jumlah temuan. Sepuluh temuan injection yang sudah dikenal tidak setara dengan satu jalur yang didemonstrasikan melintasi penetapan peran, otorisasi usang, dan penyimpanan ekspor. Nilai pekerjaan berdasarkan batas yang diuji, kualitas bukti, dan asumsi penting yang ditantang.

Tanyakan siapa yang bertanggung jawab atas pembersihan sebelum engagement dimulai. Akun uji, file yang diunggah, pesan dalam antrean, peran sementara, dan feature flag yang diubah dapat bertahan setelah pemindaian. Pemimpin manusia harus menyetujui bukti destruktif, menjaga kontak dengan operasi, dan memverifikasi pemulihan. Agen dapat mengikuti skrip pembersihan, tetapi tidak dapat memutuskan bahwa status produksi yang tidak dapat dijelaskan aman untuk dihapus.

Penguji yang baik juga melaporkan apa yang tidak dapat diuji. Build mobile yang tidak tersedia, peran yang tidak tersedia, batas laju, callback pihak ketiga, dan lingkungan yang tidak stabil mengurangi tingkat kepastian. Agen cenderung terus mengatasi hambatan dan menyajikan jalur yang berhasil diselesaikannya. Laporan akhir harus menonjolkan pengecualian agar hasil bersih tidak dianggap sebagai cakupan lengkap.

Bangun satu gate dari beberapa jenis bukti

Program yang tepat memberi setiap metode tugas dan membuat outputnya bertemu pada persyaratan keamanan yang sama. Gunakan SAST untuk pola source deterministik dan cakupan perubahan yang luas. Gunakan SCA dan provenance untuk fakta dependensi serta build. Gunakan DAST untuk perilaku yang di-deploy dan pemeriksaan runtime dasar. Gunakan agen untuk menghubungkan bukti, mengeksplorasi alur terautentikasi, membuat pengujian, dan meningkatkan triage. Gunakan manusia untuk menetapkan kebijakan, menantang asumsi bisnis, dan menyelidiki perubahan dengan konsekuensi besar.

Kebijakan rilis kemudian dapat menjadi spesifik. Blokir build saat aturan deterministik berkeparahan tinggi cocok dengan jalur yang belum disetujui, saat invarian otorisasi wajib gagal, saat penanda lintas tenant muncul, atau saat exploit terkonfirmasi masih terbuka. Kirim temuan agen yang belum pasti ke peninjauan dengan tenggat berdasarkan paparan. Jangan biarkan keyakinan yang dilaporkan sendiri oleh model memutuskan apakah produksi dirilis.

Jaga agar bukti dapat dipindahkan. Ekspor temuan, pengujian yang dihasilkan, transkrip permintaan, versi alat, revisi, identitas, cakupan, dan disposisi dalam format yang dapat diperiksa tim tanpa agen. Ini penting untuk audit, peninjauan insiden, perubahan vendor, dan hari biasa ketika pembaruan model mengubah perilaku.

Untuk aplikasi yang dibuat melalui chat, pemisahan yang sama berlaku. Koder.ai dapat membuat aplikasi web, server, dan mobile serta mengekspor source-nya, tetapi perangkat lunak yang dihasilkan tetap memerlukan persyaratan keamanan eksplisit dan pengujian independen terhadap hasil yang di-deploy. Pembuatan yang cepat membuat gate yang jelas semakin berguna karena arsitektur dan kode dapat berubah cepat.

Jalankan agen secara berkelanjutan, tetapi naikkan temuan terbaiknya menjadi pengujian regresi deterministik. Setiap bypass otorisasi yang terkonfirmasi harus menjadi kasus kebijakan. Setiap kebocoran tenant harus menambahkan invarian pada batas yang gagal. Setiap aturan yang bising harus mendapat disposisi yang dicatat. Seiring waktu, agen harus membuat sistem pengujian lebih presisi daripada saat menemukannya.

Jangan tanyakan alat tunggal mana yang menang. Tanyakan apakah setiap klaim penting memiliki bukti independen: jalur kode telah ditinjau, perilaku yang di-deploy telah diuji, aturan bisnis berasal dari pemilik, dan seseorang menantang asumsi di tempat kegagalan akan merugikan. Jika salah satu baris itu kosong, pernyataan «semua aman» yang dihasilkan AI tidak mengisinya.