AI security scanner yang cuma modal prompt panjang itu kelihatan keren di demo, tapi gampang banget rapuh di kerja nyata.
Kalau lu minta model “cari vulnerability di repo ini”, model bisa kasih daftar temuan yang terdengar meyakinkan. Masalahnya, temuan security yang nggak bisa direproduksi itu belum bug. Itu baru dugaan yang bisa buang waktu tim.
Inti artikel ini sederhana: AI bisa bantu security review, tapi scanner yang serius butuh harness. Harness di sini maksudnya sistem kerja yang memaksa agent melewati langkah jelas: cari kandidat bug, compile atau jalankan bagian relevan, uji di sandbox, validasi ulang, lalu keluarkan bukti yang bisa dicek manusia. Jadi fokusnya bukan “model mana paling pintar”, tapi bagaimana workflow-nya bikin temuan lebih bisa dipercaya.
Apa itu vulnerability harness?
Vulnerability harness adalah rangkaian alat, aturan, sandbox, dan proses validasi untuk mencari serta membuktikan celah keamanan secara berulang. Dalam konteks AI agent, harness bukan cuma prompt. Dia mencakup cara agent membaca kode, memilih target, menjalankan test, membangun proof-of-concept yang aman, membatasi environment, dan membuat laporan yang bisa diaudit.
Cloudflare memakai istilah ini saat membahas pendekatan multi-stage untuk vulnerability discovery. Poin yang menurut gua penting: mereka nggak memosisikan model sebagai “detektor bug ajaib”. Model diperlakukan sebagai salah satu komponen dalam pipeline yang lebih besar.
Ini beda jauh dari pola yang sering kita lihat:
- Upload repo ke AI.
- Minta “audit security”.
- Terima 20 daftar kemungkinan bug.
- Bingung mana yang valid, mana yang halusinasi.
Workflow kayak gitu mungkin cukup buat brainstorming awal. Tapi buat security engineering, itu belum cukup.
Kenapa prompt panjang nggak cukup?
Prompt panjang bisa membantu ngasih konteks. Tapi prompt tetap punya batas: dia nggak otomatis bikin model menjalankan kode, mengecek dependency, membandingkan behavior runtime, atau memastikan exploit path benar-benar bisa terjadi.
Masalah security sering muncul dari detail kecil:
- fungsi yang kelihatan aman, tapi dipanggil dari path yang nggak terduga;
- validasi input yang ada di satu layer, tapi bolong di layer lain;
- asumsi permission yang benar di local, tapi salah saat masuk CI/CD;
- dependency atau konfigurasi runtime yang mengubah threat model.
Model bisa menebak pola itu dari kode. Tapi tanpa tahap reproduksi dan validasi, lu tetap belum tahu apakah temuannya real.
Di sinilah harness jadi penting. Harness memaksa AI untuk bergerak dari “kayaknya ada bug” ke “ini langkah minimal buat membuktikan bug-nya”.
Pola kerja yang lebih masuk akal: find, test, validate
Kalau gua sederhanakan, vulnerability harness yang sehat punya tiga fase besar.
1. Find: cari kandidat bug, bukan langsung vonis
Di fase awal, AI agent boleh agresif. Tugasnya memperluas area pencarian: baca kode, cari input boundary, cek fungsi parsing, lihat authentication flow, atau cari penggunaan API yang rawan.
Tapi output fase ini sebaiknya disebut kandidat, bukan temuan final. Ini penting secara mental model. Kalau dari awal udah disebut “vulnerability”, tim bisa terdorong percaya terlalu cepat.
2. Test: jalankan kode di environment yang dibatasi
Cloudflare menekankan bahwa hunter agent nggak cukup cuma membaca source code. Agent bisa compile fragment, membangun versi kecil, dan menyerang binary di sandbox.
Ini bagian yang sering hilang dari demo AI security scanner. Padahal banyak bug baru kelihatan saat kode benar-benar jalan. Behavior runtime bisa beda dari tebakan statis, terutama kalau ada parsing, concurrency, filesystem, network boundary, atau permission.
Sandbox wajib jadi default. Bukan karena kita paranoid, tapi karena security testing memang sengaja menyentuh behavior berisiko. Jangan jalankan payload, exploit, atau kode asing di laptop utama tanpa isolasi.
3. Validate: pakai lensa berbeda buat lawan false positive
Satu poin menarik dari Cloudflare: model sebaiknya diperlakukan sebagai komponen yang bisa diganti-ganti. Initial discovery dan validation bisa memakai model berbeda supaya temuan nggak dicek dengan bias yang sama.
Menurut gua ini masuk akal. Kalau model A salah paham konteks, lalu model A juga yang diminta memvalidasi temuannya sendiri, hasilnya bisa tetap percaya diri walaupun salah. Cross-check dengan model lain, aturan deterministic, test case, atau reviewer manusia bikin kualitasnya lebih aman.
Checklist praktis buat developer yang mau coba
Kalau lu tertarik membangun audit kecil buat repo internal, jangan mulai dari “bikin AI bug hunter paling canggih”. Mulai dari harness kecil yang bisa diulang.
- Tentukan scope. Misalnya hanya endpoint auth, parser file upload, atau workflow GitHub Actions tertentu.
- Pisahkan kandidat dan temuan valid. Jangan campur dugaan AI dengan bug yang sudah direproduksi.
- Wajib ada langkah reproduksi. Minimal command, input, expected behavior, actual behavior, dan alasan dampaknya.
- Jalankan di sandbox. Pakai container, VM, atau environment throwaway. Jangan pakai data produksi.
- Log semua keputusan. Simpan prompt, command, output, file yang disentuh, dan alasan kenapa temuan diterima/ditolak.
- Batasi permission agent. Agent security scanner nggak otomatis butuh akses secret, deploy key, atau production database.
- Review manusia tetap wajib. AI boleh bantu coverage, tapi keputusan security tetap perlu manusia yang paham konteks sistem.
Hubungannya dengan GitHub Actions dan supply chain
Topik ini makin relevan karena supply chain software sekarang sering lewat workflow otomatis. GitHub sendiri baru menyorot risiko pull_request_target di GitHub Actions. Event ini powerful, tapi kalau salah dipakai bisa membuat kode dari fork yang belum dipercaya berjalan dengan token, secrets, atau akses cache dari base repository.
Dengan makin banyak AI agent yang bisa bikin PR, trigger CI, dan mengubah konfigurasi, security review nggak bisa cuma fokus ke source code aplikasi. Lu juga harus lihat pipeline: workflow YAML, permission token, event trigger, dependency install, dan script yang jalan otomatis.
Di area ini, harness bisa membantu banget. Bukan untuk “menggantikan security engineer”, tapi buat membuat daftar cek yang konsisten: event apa yang trigger workflow, permission apa yang aktif, secret mana yang bisa kebaca, dan skenario PR eksternal mana yang berbahaya.
Jangan jual AI security sebagai autopilot
Gua suka arah ini karena lebih jujur. AI security bukan autopilot yang otomatis bikin sistem aman. Lebih tepat disebut amplifier: dia bisa memperluas coverage, bantu triage, dan mempercepat eksplorasi. Tapi kalau workflow-nya nggak punya sandbox, validation loop, dan audit trail, AI cuma mempercepat produksi dugaan.
Ini juga pelajaran bagus buat builder di luar security. Banyak workflow AI gagal bukan karena modelnya kurang pintar, tapi karena sistem di sekitarnya terlalu lemah. Agent butuh alat, batas, memory, log, environment, dan definisi sukses yang jelas.
Kalau lu pakai AI agent buat ngoding, prinsipnya mirip:
- jangan cuma minta dia “fix bug”;
- minta dia tulis test;
- jalankan test;
- tunjukkan diff;
- jelaskan risiko;
- dan verifikasi hasilnya.
Prompt bagus membantu. Tapi workflow yang bisa diverifikasi jauh lebih penting.
Takeaway buat rafli.dev builder workflow
Pelajaran paling besar buat gua: masa depan AI tooling bukan soal siapa yang punya prompt paling panjang. Yang menang adalah orang atau tim yang punya sistem kerja paling bisa diulang.
Untuk security scanner, bentuknya vulnerability harness. Untuk coding agent, bentuknya test harness, CI, review checklist, dan skill/runbook yang jelas. Untuk content workflow, bentuknya backlog, quality gate, source validation, dan draft archive.
Semua punya pola yang sama: AI jangan cuma disuruh mikir. AI harus dipaksa membuktikan hasil kerja.
FAQ singkat
Apakah AI bisa menggantikan security engineer?
Menurut gua belum. AI bisa bantu coverage dan triage, tapi konteks bisnis, prioritas risiko, dan keputusan mitigasi tetap butuh manusia.
Apakah developer biasa perlu bikin vulnerability harness?
Nggak harus kompleks. Tapi lu bisa mulai dari harness kecil: script test security untuk area rawan, checklist permission CI, dan template laporan bug yang wajib punya reproduksi.
Apakah semua temuan AI harus dipercaya?
Jangan. Anggap temuan AI sebagai kandidat sampai ada bukti: langkah reproduksi, test case, log, atau validasi manual.
Bagaimana cara aman mencoba AI security testing?
Pakai repo milik sendiri atau scope yang memang diizinkan, jalankan di sandbox, jangan sentuh data produksi, dan jangan menjalankan exploit ke sistem orang lain.
