Belajar Application Security Engineer - Bug Bounty Coordination

#Pendahuluan

Sejauh ini semua temuan datang dari dalam: scanner kalian, review kalian. Episode ini membuka pintu ke ribuan peneliti keamanan eksternal lewat bug bounty — dan sekaligus membawa masalah baru: laporan berdatangan dengan kualitas bervariasi, researcher yang menunggu respons cepat, media yang mengintai insiden. AppSec engineer sering menjadi orang pertama yang menyentuh semua itu.

Mengapa topik ini penting bahkan jika organisasi kalian belum punya program? Karena pemahaman sisi program membuat kalian lebih baik sebagai kontributor bounty (jalur karir umum menuju AppSec), dan karena bug bounty adalah sensor kerentanan paling murah yang bisa direkomendasikan ke manajemen setelah fondasi internal siap.

#Model Program: Dari VDP Sampai Public Bounty

Empat tingkatan keterbukaan, naik bertahap:

Urutan adopsi yang sehat: VDP dulu — cukup satu halaman policy + email security.txt — lalu private bounty untuk menguji proses triase, baru public ketika SLA triase kalian terbukti konsisten. Melompat langsung ke public bounty tanpa proses = banjir laporan duplikat dan researcher frustrasi = reputasi buruk di komunitas.

#Menyusun Policy & Scope

Policy adalah kontrak sosial kalian dengan researcher. Elemen wajib:

1. Scope in-scope eksplisit: domain, aplikasi, endpoint. *.example.com terlalu luas kalau ada sistem legacy tak terawat — daftar aset spesifik.
2. Out-of-scope jujur: spam testing, DoS volumetrik, social engineering karyawan, physical attack, brute force login massal.
3. Aturan main: tidak mengakses data milik orang lain (pakai akun test sendiri), report dalam 24 jam dari temuan, no automated scanning agresif.
4. SLA respons: first response ≤ 3 hari kerja, triase ≤ 10 hari, update berkala.
5. Safe harbor: komitmen tidak akan dituntut selama patuh policy — tanpa ini, researcher serius menjauh.
6. Skema reward: tabel severity → nominal, atau point-based platform.

Contact: mailto:security@example.com
Expires: 2027-01-01T00:00:00.000Z
Preferred-Languages: id, en
Policy: https://example.com/security/policy
CSAF: https://example.com/.well-known/csaf/provider-metadata.json

File kecil di /.well-known/security.txt — peneliti profesional mencarinya sebelum menyentuh apa pun. Kehadirannya sendiri sudah sinyal kematangan.

#Triase: Dari Laporan Mentah Ke Keputusan

Alur triase yang saya pakai, lima gerbang:

1. Relevansi scope? Out-of-scope ditutup sopan dengan arahan — bukan dihapus; reputasi program hidup di forum researcher.

2. Reproduksi mandiri. Jangan pernah triase dari screenshot semata — ikuti langkahnya di environment kalian. Temuan yang tak bisa direproduksi masuk "need more info", bukan langsung invalid.

3. Tentukan dampak nyata. Reflected XSS di halaman marketing ≠ stored XSS di dashboard admin. Severity mengikuti dampak bisnis, bukan kata "XSS" saja.

4. Skoring & reward. Gunakan CVSS + konteks, atau skala bawaan platform (P1–P4). Konsistensi antar-triase lebih penting daripada angka sempurna — researcher membandingkan perlakuan antar laporan.

5. Komunikasi status. Setiap perubahan status dikabarkan dengan estimasi waktu fix. Researcher yang diinformasikan menjadi mitra; yang diabaikan jadi kritikus publik.

#Coordinated Disclosure

Ketika fix siap, jalur rilisnya harus tertata:

1. Fix deployed → verifikasi repro gagal.
2. Beri researcher jendela publikasi bersama — umumnya 30–90 hari sejak fix, atau sinkron saat advisory dirilis.
3. Advisory resmi: CVE request jika layak (CNA kalian atau MITRE), changelog security, credit untuk researcher (kecuali minta anonim).
4. Hormati janji safe harbor sampai detailnya — meski hubungan memanas saat diskusi reward.

Skenario sulit yang perlu disiapkan playbook-nya: researcher mengancam full disclosure sebelum fix (eskalasi manajemen, tetap profesional, percepat patch); laporan bocor ke media (siapkan statement yang mengakui, memberi timeline, tanpa meyalahkan); exploit aktif di alam liar sebelum patch (incident response path — episode runtime detection).

#Praktik: Simulasi Triage Satu Laporan

Latihan dengan laporan fiktif — tentukan keputusan kalian sebelum membaca analisis:

TITLE : Account takeover via password reset race
ASSET : app.example.com
STEPS :
  1. Minta reset password untuk email korban
  2. Submit form reset dua kali paralel dengan token sama
     tapi password berbeda
RESULT:
  Kedua request sukses; token tidak invalidate setelah pakai;
  korban menerima 2 link aktif selama 15 menit window.
IMPACT: Token reuse — jika link bocor, attacker retry password
        berbeda sampai match.

Analisis triase:

1. Repro: valid — token single-use yang tidak di-invalidate memang pelanggaran praktik session/token lifecycle (episode 5).
2. Dampak: butuh link bocor dulu sebagai prasyarat → bukan P1. Realistis: P3/P4 medium-low, karena mitigasi natural (link expiry 15 menit) membatasi window.
3. Keputusan: accept sebagai valid low/medium; fix murah (markUsed atomik pada konsumsi token); reward sesuai tabel medium-low; apresiasi metodologi rapi researcher.
4. Komunikasi: jelaskan reasoning severity secara terbuka — researcher yang paham mengapa P4 jarang protes.

Inilah inti pekerjaan: bukan sekadar menilai benar/salah, tapi menjaga kalibrasi dan kepercayaan sekaligus.

#Common Pitfalls

• Program tanpa kapasitas triase: public bounty dengan triase 2 minggu = pemborosan uang reward plus reputasi rusak; ukur dulu kapasitas tim.
• Severity roulette: dua triase berbeda memberi nilai beda untuk bug serupa → appeal merajalela; tulis rubrik internal dan kalibrasi berkala.
• Menganggap bounty pengganti SDLC: bounty menemukan permukaan luar; broken authorization internal yang butuh konteks bisnis tetap tanggungan review kalian (episode 12).
• Legal-first response: jawaban pertama berupa surat peringatan hukum membunuh program; safe harbor yang jelas di policy mencegah kebutuhan itu.

#Penutup

Inti yang harus dibawa pulang:

• Naik bertahap: VDP → private → public; proses triase harus matang sebelum audiens besar.
• Policy lengkap = scope eksplisit + safe harbor + SLA + skema reward; jangan lupa security.txt.
• Triase lima gerbang: scope → reproduksi → dampak nyata → skoring konsisten → komunikasi proaktif.
• Coordinated disclosure terstruktur: fix dulu, jendela publikasi, advisory + credit; siapkan playbook skenario sulit.

Di episode 18 kita kembali ke kontrol teknis di edge: Web Application Firewall (WAF) — cara kerja rule engine, ModSecurity/Core Rule Set vs WAF cloud, mode detection vs blocking, bot management, dan pentingnya memahami bypass agar tidak percaya buta pada WAF. Sampai jumpa di episode 18!