Nilai, dinamika, dan cara memaksimalkan kolaborasi antara peneliti dan vendor
“Hadiah” adalah kata paling dangkal ketika orang bicara tentang bug bounty. Di balik nominal dollar/euro/IDR ada jaringan kepercayaan, proses, dan konsekuensi jangka panjang – untuk produk, untuk peneliti, dan untuk ekosistem.
— Van Lyubov / Tegalsec
Pembuka : Dari Hadiah ke Kontrak Sosial
Banyak orang memandang bug bounty hanya dari satu sisi: hadiah.
Padahal di balik setiap angka dolar ada sesuatu yang jauh lebih kompleks, kepercayaan, tanggung jawab, dan proses. Program bug bounty bukan sekadar “siapa cepat dia dapat”, tapi sistem kolaborasi intelijen antara dua pihak: peneliti keamanan dan organisasi.
Di satu sisi, peneliti menyerahkan informasi sensitif tentang celah keamanan yang bisa menghancurkan sistem. Di sisi lain, organisasi mempercayai bahwa peneliti akan bersikap etis, tidak menyalahgunakan, dan memberi ruang waktu untuk memperbaiki sebelum publikasi.
Hubungan inilah yang sebenarnya menjadi inti bug bounty, sebuah kontrak sosial, bukan sekadar transaksi finansial.
1. Apa yang Sebenarnya Dibeli Organisasi Saat Membayar Bounty
Bayaran dalam program bounty bukanlah “hadiah acak”, tapi biaya intelijen keamanan. Perusahaan membeli situational awareness dari luar perimeter mereka sendiri, real feedback dari orang yang berpikir seperti attacker.
Beberapa nilai riil dari bug bounty yang sering terlewat:
- Real-world coverage. Bug ditemukan dalam konteks nyata : chain, token reuse, forgotten endpoint yang tidak akan muncul dalam testing internal.
- Proof of diligence. Bug bounty adalah bukti kepatuhan bagi audit dan regulasi: bahwa organisasi aktif memitigasi ancaman.
- Cost efficiency. Lebih murah membayar $$$ untuk laporan kritikal daripada membayar puluhan juta untuk insiden forensik.
- Network effect. Program yang sehat menarik peneliti berkualitas, membangun reputasi keamanan perusahaan, sekaligus peluang rekrutmen.
Organisasi yang memandang bounty hanya sebagai “budget promosi” biasanya berakhir dengan program penuh spam. Organisasi yang memandangnya sebagai investasi keamanan akan menuai insight, bukan sekadar laporan.
2. Kenapa “Reward Saja” Tidak Cukup
Di lapangan, masalah utama bukan soal apakah program membayar atau tidak, melainkan bagaimana organisasi menyikapi laporan. penulis sering melihat pola yang sama berulang: organisasi bikin program, promosi, lalu muncul masalah yang lebih dalam.
Pertama: inbox yang penuh, proses nol. Program yang memancing banyak hunter tapi tidak menyiapkan proses triage nyata sama dengan membuka keran tanpa ember: laporan datang, menumpuk, tidak ada tanggapan. Peneliti yang mengirimkan laporan berkualitas lalu menunggu tidak jelas akan kehilangan trust dan apabila peneliti publikasi karena frustasi, vendor akan panik dan merusak reputasi.
Kedua: ketidaktepatan penilaian severity. Banyak triager memutuskan severity berdasar satu angka atau rulebook kaku (mis. “CVSS-based auto label”), tanpa mempertimbangkan konteks operasional, bagaimana bug itu akan dimanfaatkan di dunia nyata, apakah ada kredensial yang beredar di wild, atau apakah chaining with other flows memungkinkan ATO. Ini mengakibatkan under-prioritization terhadap temuan yang sebenarnya berbahaya.
Ketiga: ambiguity hukum & safe-harbor. Tanpa pedoman legal yang jelas, peneliti takut melakukan pengujian yang perlu untuk membuktikan exploitability (mis. mencoba forgot-password flow) sehingga banyak temuan tidak tervalidasi dengan baik. Sebaliknya, vendor yang tidak menegaskan batas legal kadang bereaksi agresif terhadap peneliti.
Keempat: incentive misalignment. Jika reward skema hanya untuk “data exfiltration” atau hanya untuk kategori tertentu, peneliti bisa terdorong berperilaku agresif untuk meraih nominal besar. Jika reward kecil untuk bug chaining tapi chaining itu berpotensi ATO, vendor sering melewatkan hal paling kritikal.
Kesimpulan: reward hanyalah alat; proses (triage, legal clarity, komunikasi) adalah fondasinya.
3. Masalah Umum: Triager yang Terlalu Percaya Angka
Salah satu pengalaman paling sering penulis alami adalah debat dengan triager soal severity.
Triager sering menilai laporan hanya dengan kalkulator CVSS, angka yang dibuat seolah objektif, padahal tanpa konteks bisa salah arah.
CVSS memang membantu memberi baseline teknis, tapi tidak cukup untuk menggambarkan how real exploit-nya di lapangan.
Masalah muncul ketika triager mengabaikan faktor seperti:
- Kredensial bocor di darkweb.
- Bug yang tampak kecil tapi bisa chaining dengan flow lain.
- Endpoint yang tampak internal tapi sebenarnya diekspos lewat API publik.
- Dampak bisnis (misalnya perubahan data finansial atau manipulasi OTP).
Inilah sebabnya banyak laporan dikategorikan “Medium” padahal secara operasional sudah high ataupun critical.
4. Studi Kasus Nyata: Bank [Redacted] dan Debat Severity
Salah satu contoh paling jelas adalah kasusku di bank yang tidak penulis sebut namanya, yang sempat masuk bug bounty resmi mereka.
penulis menemukan bug pada dashboard (authenticated), di mana seorang attacker bisa mengakses data merchant lain.
Yang menarik akun yang dipakai bukan hasil brute-force, bukan hasil recon panjang, tapi akun yang bocor dari logstealer.
Dalam konteks dunia nyata, ini artinya:
- Attack vector bukan internal.
- Attacker tidak membutuhkan privilege di sistem target.
- Kredensial sudah tersedia di wild.
Namun triager menilai metrik Privilege Required (PR) sebagai High, bukan None, dengan alasan bug terjadi di area authenticated.
Di sinilah letak masalahnya.
CVSS tidak semudah itu pemahamanya.
Jika kredensial tersedia di wild, maka exploitasi tidak membutuhkan privilege khusus dari sistem target – PR = None.
Menilai PR = High dalam kasus seperti ini mengabaikan realitas lapangan bahwa attacker tidak perlu melakukan privilege escalation apa pun.
Selain itu, dampak bug tidak berhenti pada “melihat data”. Dari dashboard tersebut, chaining dengan flow lain bisa mengarah ke ATO, bahkan potensi perubahan data finansial merchant.
Penulis menyampaikan argumen ini ke triager dengan CVSS mapping yang logis:
- AV: Network
- AC: Low
- PR: None (karena akun berasal dari leak publik)
- UI: None
- S: Changed
- C: High
- I: High
- A: None
Dengan mapping ini, skor CVSS jauh lebih tinggi dan lebih mencerminkan risiko riil.
5. Kenapa Kesalahan Penilaian Severity Berbahaya
Ketika severity salah diklasifikasikan, bukan cuma soal nominal bounty yang terpotong.
Efeknya bisa jauh lebih dalam:
- Perusahaan salah prioritas. Bug yang seharusnya segera diperbaiki malah diabaikan karena label “Medium”.
- Reporter kehilangan kepercayaan. Ketika laporan valid ditolak atau dianggap remeh, peneliti enggan berpartisipasi lagi.
- Ekosistem jadi dangkal. Triager hanya fokus pada angka, peneliti hanya fokus pada bounty. Riset keamanan kehilangan makna.
Sementara di sisi penyerang sungguhan, mereka tidak peduli CVSS.
Mereka hanya peduli: bisa exploit atau tidak?
Dan di situ, setiap salah klasifikasi bisa berarti celah terbuka lebih lama.
6. Cara Menyusun Severity yang Efektif
Ketika berhadapan dengan triager yang hanya berpatokan pada angka, pendekatannya harus sistematis. Bukan emosional, tapi berbasis data dan konteks.
Langkah yang penulis pakai biasanya seperti ini:
- Tulis ulang deskripsi singkat bug-nya.
“Bug ini memungkinkan attacker dengan credential yang sudah beredar di wild untuk mengakses dashboard merchant dan melakukan perubahan data tanpa perlu privilege tambahan.” - Lampirkan bukti kredensial (redacted).
Cukup tangkapan layar login berhasil atau request HTTP 200 yang menunjukkan akses berhasil. - Berikan CVSS mapping lengkap beserta alasan.
Jelaskan satu per satu:- AV: Network — karena via web.
- AC: Low — tidak butuh kondisi kompleks.
- PR: None — credential tersedia di luar.
- UI: None — tanpa interaksi user.
- C/I/A: nilai sesuai dampak.
- Tulis dampak bisnis secara nyata.
Jelaskan potensi chaining atau abuse scenario (misal pengubahan email payout). - Sertakan rekomendasi mitigasi cepat.
Misalnya: force logout semua session aktif, enable 2FA, reset token. - Minta re-evaluasi dengan sopan dan teknis.
Jangan menyerang personal triager. Fokus pada konteks exploit.
Dengan format seperti ini, biasanya diskusi bisa kembali ke arah teknis, bukan debat opini.
7. Ketika CVSS Saja Tidak Cukup
CVSS hanya mengukur vektor teknis, bukan konteks bisnis.
Penilaian “PR: High” vs “PR: None” bisa mengubah score dari 6.4 menjadi 9.1 tapi angka itu masih tidak bicara apa-apa kalau tidak diikat pada konteks operasional.
Karena itu, penulis lebih setuju model kombinasi: CVSS + Threat Context.
- CVSS untuk baseline teknis.
- Threat Context sebagai multiplier yang mempertimbangkan case yang ada sesuai real case.
Dengan model ini, severity bisa disesuaikan tanpa kehilangan objektivitas teknis.
8. Rekomendasi untuk Vendor dan Triager
Organisasi yang ingin program bug bounty-nya berumur panjang harus berhenti melihat laporan sebagai gangguan.
Laporan adalah data intelijen gratis yang menambah visibilitas ke risiko yang tidak bisa mereka lihat dari dalam.
Beberapa langkah praktis yang bisa dilakukan:
- Tetapkan proses triage yang jelas.
Setiap laporan harus punya status, pemilik, dan waktu respon maksimal.
SLA ideal: acknowledge < 72 jam, assessment < 7 hari. - Latih triager untuk melihat konteks.
Jangan hanya isi form CVSS. Triager harus paham threat modeling dasar: apakah exploit butuh user? apakah data sudah bocor? dan berbagai case yang lain - Buat severity rubric yang terbuka.
Publikasikan panduan penilaian severity dengan contoh chaining case.
Transparansi mengurangi debat. - Sediakan jalur eskalasi.
Kalau reporter dan triager tidak sepakat, harus ada security manager yang jadi penengah.
Jangan biarkan laporan valid mengendap karena ego. - Berikan apresiasi non-finansial.
Nama di Hall of Fame, badge, atau follow-up invitation jauh lebih bernilai daripada hadiah kecil yang terlambat. - Integrasikan dengan dev cycle.
Pastikan laporan yang valid langsung masuk backlog dev dengan label jelas.
Tidak ada gunanya reward tinggi kalau bug-nya tidak pernah diperbaiki.
9. Rekomendasi untuk Peneliti dan Bug Hunter
Di sisi lain, peneliti juga punya tanggung jawab.
Tujuan kita bukan hanya menemukan bug, tapi memastikan sistem jadi lebih aman setelah kita temukan.
Beberapa prinsip yang selalu penulis pegang:
- Jangan hanya cari impact, cari value.
Laporan kecil tapi punya insight proses lebih dihargai daripada PoC besar tanpa konteks. - Tulislah laporan yang bisa dibaca developer.
Gunakan langkah jelas, struktur rapi, dan rekomendasi fix yang bisa diimplementasikan. - Hindari data nyata.
Kalau bug memungkinkan lihat data user, ambil satu contoh yang aman (redacted). Jangan dump ribuan record demi “pembuktian”. - Bangun reputasi, bukan ketenaran.
Konsistensi dalam laporan jauh lebih berharga dari satu bug sensational.
10. Kesimpulan: Dari “Hunter” ke “Partner”
Program bug bounty yang sukses tidak diukur dari jumlah uang yang keluar, tapi dari kepercayaan yang tumbuh.
Ketika peneliti diperlakukan sebagai partner, bukan musuh, mereka akan memberikan lebih dari sekadar laporan, mereka memberikan pemahaman, insight, bahkan loyalitas.
Sebaliknya, ketika triager memandang peneliti sebagai kompetitor, laporan berubah jadi arena debat yang tidak produktif.
Keamanan akhirnya tidak meningkat; hanya angka CVSS yang berpindah.
Bug bounty yang sehat adalah simbiosis.
Organisasi belajar memahami perspektif attacker, peneliti belajar memahami dampak bisnis.
Di titik itu, “hadiah” berubah menjadi “investasi keamanan”.
Penutup
Bug bounty memang memberi hadiah, tapi nilai sejatinya bukan di sana.
Nilainya ada pada pembelajaran bersama antara pembuat sistem dan mereka yang berusaha membobolnya, bukan untuk merusak, tapi untuk memperkuat.
Ketika laporan dianggap sebagai gangguan, sistem akan terus berulang dengan celah yang sama.
Ketika laporan dianggap sebagai intelijen, sistem tumbuh jadi lebih tangguh.
“Security isn’t about fear, it’s about understanding.”
