Apa Itu Bug Bounty dan Perlukah Bisnis Membukanya?

Bug bounty adalah program di mana sebuah organisasi mengundang peneliti keamanan dari luar untuk mencari celah di sistemnya, lalu memberi imbalan (biasanya uang) untuk setiap laporan yang valid. Jadi alih-alih menunggu peretas jahat menemukan celah lebih dulu, kamu membayar orang yang menemukannya dan melapor dengan baik.

Kenapa ini penting? Karena orang luar sudah memindai website-mu, mau kamu undang atau tidak. Pertanyaannya, ketika salah satu dari mereka menemukan celah, ke mana ia harus melapor, dan apakah kamu siap menanggapinya?

Bagaimana bug bounty bekerja?

Alurnya kurang lebih seperti ini:

• Organisasi menetapkan cakupan (scope). Misalnya toko.example.com dan aplikasi mobile masuk cakupan, tetapi server email dan sistem pihak ketiga tidak.
• Aturan main ditulis jelas. Teknik yang dilarang (misalnya DDoS, social engineering ke karyawan, mengakses data pelanggan lebih dari yang perlu untuk membuktikan celah), cara melapor, dan janji tidak menuntut peneliti yang mengikuti aturan.
• Peneliti mencari dan melapor. Laporan berisi langkah reproduksi dan dampak.
• Tim internal memverifikasi (triase). Laporan duplikat atau di luar cakupan ditolak, yang valid dinilai tingkat keparahannya.
• Celah diperbaiki, imbalan dibayar. Besarnya imbalan biasanya berjenjang sesuai keparahan.

Program bisa dijalankan sendiri atau lewat platform bug bounty pihak ketiga yang menyediakan komunitas peneliti dan bantuan triase. Program juga bisa bersifat privat (hanya peneliti undangan) atau publik (terbuka untuk siapa saja).

Apa bedanya bug bounty, VDP, dan pentest?

Tiga hal ini sering tertukar, padahal tujuannya berbeda.

Pentest memberi gambaran menyeluruh di satu titik waktu. Bug bounty memberi pengujian berkelanjutan dari banyak sudut pandang, tetapi tidak menjamin semua bagian diuji. Bila kamu belum pernah pentest, mulai dari sana. Panduan frekuensinya ada di seberapa sering website bisnis perlu dipentest, dan perbandingan dengan layanan pemantauan ada di beda SOC, vulnerability scan, dan pentest.

Perlukah bisnismu membuka bug bounty?

Jawaban jujurnya: kebanyakan bisnis kecil belum perlu bug bounty berbayar, tetapi hampir semua perlu punya jalur pelaporan celah. Coba cek kesiapanmu dengan daftar berikut.

Tanda kamu belum siap membuka bug bounty:

• Belum pernah ada pentest atau pemindaian kerentanan.
• Update CMS, plugin, dan server masih sering tertunda.
• Tidak ada orang yang bertanggung jawab memperbaiki celah dalam hitungan hari.
• Belum ada anggaran tetap untuk imbalan.

Kalau celah dasar masih banyak, bug bounty akan banjir laporan yang sebenarnya bisa ditemukan sendiri dengan alat gratis. Biayanya membengkak, dan tim kewalahan.

Ada juga biaya yang tidak tertulis di anggaran: waktu. Setiap laporan harus dibaca, direproduksi, dinilai, dan dijawab. Laporan yang ternyata duplikat atau di luar cakupan tetap menyita jam kerja. Tanpa orang yang khusus memegang triase, antrean laporan bisa menumpuk lebih cepat daripada kemampuan tim memperbaikinya.

Tanda kamu mulai siap:

• Pentest rutin sudah berjalan dan temuannya ditutup.
• Ada proses patch yang jelas dan tim yang bisa merespons laporan.
• Sistemmu menyimpan data atau uang yang menarik bagi penyerang, misalnya aplikasi keuangan atau marketplace.
• Kamu siap menulis cakupan dan aturan yang jelas, termasuk perlindungan hukum bagi peneliti yang beritikad baik.

Bila sebagian besar poin itu terpenuhi, pertimbangkan memulai dari program privat dengan cakupan sempit, misalnya satu aplikasi utama dan sejumlah kecil peneliti undangan. Setelah alur triase, perbaikan, dan pembayaran berjalan lancar, cakupan bisa diperluas atau program dibuka untuk publik.

Apa risiko membuka bug bounty?

Program yang terburu-buru bisa menimbulkan masalah baru. Beberapa yang perlu diantisipasi:

• Gangguan layanan. Pengujian dari banyak orang bisa membebani server. Tetapkan batas kecepatan permintaan dan larang pengujian yang merusak.
• Akses ke data pelanggan. Peneliti bisa saja melihat data nyata saat membuktikan celah. Aturan harus meminta mereka berhenti begitu celah terbukti dan tidak menyimpan data, karena data pribadi tetap dilindungi UU PDP.
• Perselisihan imbalan. Peneliti merasa temuannya kritis, kamu menilainya rendah. Tabel keparahan yang jelas mengurangi gesekan ini.
• Pengungkapan publik. Tetapkan kapan dan bagaimana peneliti boleh mempublikasikan temuannya setelah celah diperbaiki.

Langkah awal yang bisa dilakukan sekarang

Tanpa membuka bug bounty pun, kamu bisa menyiapkan jalur pelaporan yang rapi.

Pertama, buat halaman kebijakan pelaporan celah (VDP). Isinya: sistem apa yang boleh diuji, apa yang dilarang, cara melapor, berapa lama kamu akan merespons, dan pernyataan bahwa pelapor beritikad baik tidak akan dituntut. CISA menyediakan templat VDP yang bisa dijadikan acuan.

Kedua, pasang file security.txt di https://domainmu/.well-known/security.txt. Format ini distandarkan dalam RFC 9116. Isi minimalnya kolom Contact dan Expires, misalnya:

Contact: mailto:security@domainmu.co.id
Expires: 2027-11-15T00:00:00.000Z
Policy: https://domainmu.co.id/kebijakan-keamanan
Preferred-Languages: id, en

Ketiga, siapkan alamat email khusus yang benar-benar dibaca, dan tetapkan siapa yang menindaklanjuti. Laporan celah yang diabaikan berminggu-minggu bisa membuat pelapor kehilangan kesabaran, dan celahnya tetap terbuka.

Bila laporan ternyata menunjukkan celah sudah dieksploitasi, perlakukan sebagai insiden. Urutan penanganannya dibahas di panduan respons insiden siber.