Responsible disclosure adalah praktik melaporkan kerentanan keamanan kepada pemilik sistem secara tertutup, lalu memberi mereka waktu yang wajar untuk memperbaikinya sebelum informasinya dibuka ke publik. Tujuannya melindungi pengguna: celah ditutup lebih dulu, baru dibahas. Panduan ini menjelaskan langkah melapor dengan benar, tanggung jawab organisasi penerima laporan, dan risiko hukum yang perlu Anda sadari, sebagai informasi umum dan bukan nasihat hukum.
Apa Itu Responsible Disclosure dan Coordinated Disclosure?
Istilah responsible disclosure sudah lama dipakai, tetapi banyak pihak kini lebih memilih coordinated vulnerability disclosure (CVD). Alasannya, kata "responsible" seolah hanya membebankan tanggung jawab pada pelapor, padahal prosesnya melibatkan pelapor, vendor, dan kadang koordinator pihak ketiga. Intinya sama: temuan disampaikan secara privat, diverifikasi, diperbaiki, lalu diumumkan secara terkoordinasi.
Ada tiga pendekatan yang sering dibandingkan:
- Full disclosure: detail langsung dipublikasikan tanpa menunggu perbaikan. Risikonya, penyerang ikut mendapat informasi sebelum pengguna terlindungi.
- Non-disclosure: temuan tidak pernah dilaporkan atau dibuka. Celah tetap ada dan bisa ditemukan pihak lain.
- Responsible atau coordinated disclosure: jalan tengah yang memberi waktu perbaikan sekaligus menjaga akuntabilitas vendor.
Cara Melakukan Responsible Disclosure dengan Benar
1. Pastikan Anda tidak melampaui batas sejak awal
Prinsip terpenting: hentikan pengujian begitu Anda yakin celah itu ada. Jangan mengunduh data pengguna, mengubah data, mengganggu layanan, atau mencoba masuk lebih jauh hanya untuk menunjukkan dampak. Bukti minimal sudah cukup, dan semakin sedikit data pribadi yang Anda sentuh, semakin kecil risiko bagi Anda dan bagi korban potensial.
2. Cari kanal pelaporan resmi
Periksa halaman keamanan situs, kebijakan pengungkapan kerentanan (VDP), atau program bug bounty. Banyak organisasi memasang berkas security.txt sesuai RFC 9116 di alamat /.well-known/security.txt. Berkas itu wajib memuat kontak dan tanggal kedaluwarsa, sehingga Anda tahu ke mana harus melapor. Untuk instansi pemerintah, cari kanal CSIRT instansi terkait.
3. Susun laporan yang jelas dan aman
Laporan yang baik memuat:
- Aset yang terdampak, misalnya alamat aplikasi atau versi perangkat lunak.
- Jenis kerentanan dan penjelasan dampaknya terhadap kerahasiaan, integritas, atau ketersediaan.
- Langkah yang cukup agar tim teknis dapat mereproduksi masalahnya. Hindari menyertakan kode eksploitasi yang siap pakai.
- Bukti seperti tangkapan layar, dengan data pribadi disamarkan.
- Rekomendasi perbaikan bila Anda punya, serta kontak untuk tanya jawab lanjutan.
Kirim lewat kanal terenkripsi bila organisasi menyediakannya, dan jangan membagikan detail teknis di media sosial atau grup terbuka selama proses berlangsung.
4. Sepakati tenggat pengungkapan
Tidak ada tenggat tunggal yang berlaku universal. CERT/CC, misalnya, menyatakan dalam kebijakannya bahwa kerentanan yang dilaporkan kepadanya akan diungkapkan ke publik 45 hari setelah laporan awal, terlepas dari ketersediaan perbaikan. Peneliti lain, seperti Google Project Zero, memakai tenggat 90 hari. Kebijakan lengkap CERT/CC dapat dibaca di halaman kebijakan CERT/CC. Untuk laporan Anda sendiri, sepakati jadwal bersama vendor, dan bersedia memperpanjang bila mereka menunjukkan kemajuan nyata.
5. Jangan menjadikan temuan sebagai alat tekanan
Melaporkan celah lalu menuntut pembayaran sebagai syarat tidak membukanya mengubah laporan menjadi pemerasan. Imbalan yang sah datang dari program bug bounty atau apresiasi yang ditawarkan organisasi, bukan dari ancaman.
Tanggung Jawab Organisasi Penerima Laporan
Pendekatan ini hanya berhasil bila organisasi juga berperilaku bertanggung jawab. Beberapa praktik dasarnya:
- Publikasikan kebijakan pengungkapan kerentanan dan kontak yang mudah ditemukan, misalnya lewat security.txt.
- Beri konfirmasi penerimaan dengan cepat dan kabari perkembangan secara berkala.
- Verifikasi, nilai tingkat keparahan, dan perbaiki sesuai prioritas. Pelajari cara membaca skornya di artikel tentang level kerentanan dan skor CVSS.
- Nyatakan secara tertulis bahwa pelapor yang beritikad baik dan mengikuti kebijakan tidak akan dituntut.
- Beri kredit kepada pelapor bila mereka bersedia disebut.
Organisasi yang belum siap menjalankan program terbuka dapat memulai dari kebijakan sederhana, lalu berkembang ke bug bounty. Perbedaan dan cara kerjanya dibahas di artikel bug bounty.
Risiko Hukum bagi Pelapor di Indonesia
Ini bagian yang sering diabaikan. Menemukan celah dengan cara mengakses sistem tanpa izin tetap dapat dinilai sebagai akses tanpa hak. Sejak KUHP baru berlaku pada 2 Januari 2026, akses ilegal ke sistem elektronik milik orang lain diatur di Pasal 332 KUHP dengan ancaman penjara 6 sampai 8 tahun atau denda. Pasal 34 ayat (2) UU ITE memang mengecualikan kegiatan penelitian dan pengujian sistem yang sah, tetapi penjelasannya menyempitkan makna "penelitian" pada lembaga penelitian berizin.
Artinya, niat baik dan pelaporan yang rapi tidak otomatis memberi kekebalan. Cara paling aman adalah hanya menguji aset yang jelas mengundang pengujian lewat program resmi, atau yang sudah Anda kantongi izin tertulisnya. Telaah lengkap pasalnya ada di artikel hukum hacking dan UU ITE. Bagi yang ingin menekuni jalur ini secara profesional, baca juga cara menjadi bug hunter.
Baca juga: Cyber Security Researcher: Peran, Tugas, dan Cara Memulainya.
Pertanyaan yang Sering Diajukan
Apa bedanya responsible disclosure dan bug bounty?
Pengungkapan bertanggung jawab adalah proses pelaporan secara tertutup. Bug bounty adalah program yang menawarkan imbalan atas laporan yang valid, lengkap dengan ruang lingkup dan aturan. Bug bounty biasanya mengandalkan prinsip pengungkapan terkoordinasi.
Bagaimana bila organisasi tidak merespons?
Coba kanal lain, ulangi laporan dengan bukti yang rapi, dan dokumentasikan semua upaya. Bila tetap tidak ada respons, pertimbangkan koordinator pihak ketiga seperti CERT atau CSIRT yang relevan, bukan langsung mempublikasikan detailnya.
Apakah pelapor boleh meminta imbalan?
Boleh bertanya apakah ada program apresiasi atau bounty, tetapi jangan menjadikannya syarat dan jangan mengancam akan membuka celah. Itu bisa dianggap pemerasan.
Haruskah saya mengumumkan temuan setelah diperbaiki?
Itu pilihan yang sebaiknya disepakati bersama organisasi. Pengumuman setelah perbaikan membantu komunitas belajar, asalkan tidak membuka data pribadi atau detail yang memudahkan penyalahgunaan pada sistem yang belum diperbarui.
Kesimpulan
Responsible disclosure menggabungkan kemampuan teknis dengan kedewasaan etika: berhenti di batas, melapor secara privat, memberi waktu perbaikan, dan tidak mengambil keuntungan dari celah. Organisasi punya peran yang sama pentingnya dengan menyediakan kanal dan menanggapi laporan secara adil. Jika organisasi Anda ingin menyiapkan kebijakan pengungkapan kerentanan atau pengujian keamanan yang terukur, lihat layanan keamanan Linuxhackingid.
Every article is reviewed by the practice lead who ran the work before it is published.