Menerima laporan kerentanan: VDP, bug bounty, dan tindak lanjut

Apa itu vulnerability disclosure policy?

Vulnerability disclosure policy (VDP) adalah kebijakan untuk menerima dan menangani laporan kerentanan. Isinya membantu pelapor mengetahui kanal yang dipakai, informasi yang dibutuhkan, batas kegiatan yang diizinkan, serta bagaimana laporan ditindaklanjuti.

Jangan membuka kanal hanya untuk terlihat siap. Tetapkan petugas yang membacanya, pengganti saat ia tidak tersedia, dan jalur eskalasi untuk laporan yang mungkin menunjukkan insiden aktif.

Apa bedanya dengan bug bounty dan pentest?

Bentuk	Fokus	Yang perlu diperjelas
VDP	Jalur pelaporan dan penanganan kerentanan	Lingkup, izin, komunikasi, dan tindak lanjut
Bug bounty	Program dengan imbalan sesuai ketentuan	Kelayakan temuan, peserta, lingkup dan aturan imbalan
Pentest	Pengujian yang disepakati dalam pekerjaan tertentu	Aset, metode, waktu, pelaksana, laporan dan pengujian ulang

Ketiganya bisa saling melengkapi. Menerima laporan tidak berarti menjanjikan pembayaran; memiliki bug bounty juga tidak membuktikan seluruh sistem telah diuji. Untuk pengadaan pekerjaan terjadwal, gunakan panduan pentest.

Apa yang ditulis sebelum kanal dibuka?

Tuliskan sistem yang termasuk dan tidak termasuk, kontak, data minimum yang dibutuhkan, serta larangan kegiatan yang mengganggu atau mengakses data di luar izin. Pastikan pemilik sistem menyetujui lingkupnya. Sistem pemasok tidak otomatis boleh diuji karena terhubung dengan aplikasi Anda.

Jelaskan bagaimana pelapor mendapat tanda terima dan perkembangan penanganan. Buat janji waktu yang benar-benar dapat dijalankan tim; jangan menyalin tenggat organisasi lain. Kebijakan perlu diperiksa oleh pihak yang memahami kewenangan dan konsekuensi hukumnya. Pernyataan perlindungan pelapor dalam pedoman negara lain bukan jaminan perlindungan hukum di Indonesia.

Contoh alur penanganan laporan

Skenario fiktif: pelapor menyampaikan bahwa dokumen satu akun tampak dapat diakses akun lain. Contoh ini menunjukkan pembagian pekerjaan; bukan izin menguji layanan mana pun.

Tahap	Tindakan tim	Catatan yang disimpan
Terima	Beri nomor laporan dan batasi penerima bukti	Waktu, kanal, petugas dan ringkasan tanpa data berlebih
Nilai	Tentukan sistem, dampak awal, dan kebutuhan eskalasi	Fakta, dugaan, izin pemeriksaan dan pemilik layanan
Periksa	Reproduksi secara terkendali menggunakan data uji	Cara pemeriksaan dan hasil; hindari memperluas akses data
Perbaiki	Tetapkan pemilik dan prioritas perbaikan	Perubahan, tenggat dan risiko sementara
Tutup	Periksa ulang, informasikan hasil yang boleh dibagikan	Bukti penyelesaian, keterbatasan dan koordinasi publikasi

Jika temuan mengarah pada kejadian yang sedang berlangsung, hubungkan dengan respons insiden. Menunggu laporan lengkap tidak boleh menjadi alasan mengabaikan dampak yang sudah terlihat.

Bagaimana melindungi laporan dan bekerja dengan pemasok?

Sediakan cara berbagi bukti yang sesuai tingkat kerahasiaannya. Minta pelapor membatasi data yang dikirim; jangan meminta database pelanggan sebagai syarat laporan diterima. Simpan bukti dengan akses terbatas dan kebijakan penyimpanan yang jelas.

Jika pemasok mengelola komponen terdampak, sepakati siapa menghubunginya, siapa memperbaiki, dan siapa boleh memberi informasi ke pelanggan atau publik. Hak menerima laporan tidak otomatis memberi hak memublikasikan semua detail teknis.

Gunakan panduan vendor IT untuk batas berbagi bukti keamanan. Catat tindak lanjut pada register kerentanan agar laporan tidak berhenti pada balasan “sudah diterima”. Panduan NIST yang dirujuk ditujukan pada konteks federal Amerika Serikat; di sini dipakai untuk proses penanganan, bukan sebagai kewajiban hukum lokal.