Cara Mengetahui Apakah Aplikasi Pendamping Memiliki Saluran Pelaporan Kerentanan yang Efektif
Alamat email keamanan adalah bukti adanya tujuan penerimaan, bukan bukti adanya proses pengungkapan kerentanan yang berfungsi. Saluran publik yang efektif memberi tahu pelapor dari mana harus memulai, domain dan versi aplikasi mana saja yang masuk dalam cakupan, pengujian apa yang diizinkan dan tidak diizinkan, bukti apa yang harus disertakan, bagaimana materi sensitif dapat dikirim, dan komunikasi apa yang menyusul setelah pengiriman. Saluran ini juga memisahkan kerentanan produk dari masalah akun biasa, konten berbahaya, sengketa penagihan, dan insiden perangkat hilang. Anda dapat mengevaluasi sinyal-sinyal ini secara pasif dari situs web resmi penyedia, tautan pengembang di toko aplikasi, halaman kebijakan, dan berkas security.txt. Jangan membuat akun tambahan, mengakses data orang lain, mengganggu layanan, melewati pembayaran, atau menguji sistem langsung hanya untuk menilai salurannya. Hasilnya bukanlah jaminan bahwa aplikasi tersebut bebas dari kerentanan. Ini adalah penilaian yang lebih spesifik: apakah penyedia menyediakan jalur yang kredibel untuk menerima, melakukan triase, mengoordinasikan, dan menutup laporan.
Pastikan bahwa titik masuk tersebut milik penyedia
Mulailah dari situs web pengembang yang ditautkan dari daftar resmi di toko aplikasi, lalu cari halaman Keamanan, Kepercayaan, Pengungkapan Kerentanan, Bug Bounty, atau Pengungkapan yang Bertanggung Jawab. Periksa lokasi standar /.well-known/security.txt pada domain resmi yang sama. RFC 9116 menetapkan berkas tersebut agar kontak keamanan lebih mudah ditemukan dan memungkinkannya mengarahkan ke informasi kebijakan, enkripsi, konfirmasi/kreditasi, bahasa, dan kedaluwarsa. Anggap pesan langsung di media sosial, moderator komunitas, atau alamat yang disalin dari postingan forum lama sebagai data yang belum diverifikasi sampai domain resmi mengonfirmasinya. Catat URL halaman beserta tanggal pembaruan atau kedaluwarsa yang terlihat. Berkas security.txt yang telah kedaluwarsa bertahun-tahun lalu, mengalihkan ke perusahaan induk yang tidak terkait, atau mencantumkan kotak surat yang tidak aktif adalah peringatan untuk mencari konfirmasi—bukan izin untuk memublikasikan detail kerentanan di tempat lain.
Baca cakupan dan batas-batas safe-conduct sebelum menilai saluran
Kebijakan yang berguna mencantumkan produk, properti web, aplikasi seluler, API, dan versi yang dicakupnya, ditambah pengecualian umum seperti layanan pihak ketiga atau rekayasa sosial. Kebijakan tersebut juga harus menyatakan aktivitas yang dilarang: gangguan, penolakan layanan (DoS), otomatisasi massal, intrusi fisik, mengubah data, mengakses konten pengguna lain, atau menyimpan informasi pribadi. Beberapa kebijakan mencantumkan ketentuan perlindungan (safe harbor) untuk riset beritikad baik yang mematuhi aturan tersebut, tetapi rumusan kata dan yurisdiksinya bervariasi; jangan mengasumsikan adanya izin di luar teks yang tertulis. Bug bounty tidak diwajibkan untuk sebuah jalur pelaporan yang efektif. Imbalan, kelayakan, dan koordinasi pengungkapan adalah hal yang berbeda. Bagi pengguna yang sedang mengevaluasi aplikasi, tanda utamanya adalah apakah seorang pelapor dapat memahami batas yang diizinkan sebelum bertindak, bukan apakah nilai imbalan tertingginya terdengar mengesankan.
Periksa seperti apa format laporan yang dapat digunakan dan pengiriman yang aman
Saluran tersebut harus meminta struktur data yang memadai untuk mereproduksi masalah tanpa meminta pelapor mengumpulkan data pengguna yang tidak perlu. Bidang yang berguna mencakup produk dan versi yang terpengaruh, lingkungan, langkah-langkah ringkas, perilaku yang diharapkan versus yang diamati, potensi dampak, dan detail kontak. Saluran ini dapat menyediakan formulir web, email khusus, portal platform, atau kunci enkripsi untuk lampiran sensitif. Jangan pernah menyertakan kata sandi, token akses, riwayat obrolan lengkap, dokumen identitas, atau data pengguna lain kecuali jika pihak penanggap resmi secara eksplisit menetapkan metode yang aman dan diperlukan—dan bahkan dalam kondisi tersebut, minimalkan materinya. Tangkapan layar harus disensor sehingga hanya menampilkan antarmuka yang relevan. Jika satu-satunya pilihan adalah chatbot bantuan umum yang menolak lampiran teknis dan tidak memberikan pengenal kasus, penyedia mungkin masih menerima pesan tersebut, tetapi bukti publik untuk penanganan yang terkoordinasi tergolong lemah.
Carilah tanda konfirmasi penerimaan, status, dan penutupan—bukan perbaikan instan
Kebijakan yang efektif menjelaskan apa yang terjadi setelah pengiriman: konfirmasi penerimaan otomatis atau manual oleh manusia, rujukan pelacakan, cara untuk menjawab pertanyaan, triase, dan estimasi kepastian untuk pembaruan status. Tenggat waktu remediasi yang pasti tidak selalu realistis karena tingkat keparahan dan ketergantungan sistem berbeda-beda, sehingga ketiadaan waktu perbaikan yang seragam bukanlah suatu kegagalan tersendiri. Yang lebih bermakna adalah apakah saluran tersebut membedakan antara penerimaan dan validasi, serta antara validasi dan remediasi. Aturan Google Bug Hunters, misalnya, memublikasikan cakupan produk, ekspektasi laporan, perilaku yang dilarang, dan kelayakan imbalan sebagai konsep yang terpisah. Penyedia yang matang juga dapat menjelaskan laporan duplikat, temuan yang tidak dapat direproduksi, dan kapan suatu kasus ditutup. Ketiadaan kabar setelah tiket umum dibuat, tanpa adanya penanggung jawab keamanan atau jalur eskalasi, merupakan celah proses yang nyata.
Verifikasi pengungkapan terkoordinasi dan ketentuan privasi pelapor
Bacalah bagaimana penyedia meminta pelapor untuk menangani pengungkapan publik saat perbaikan sedang dievaluasi, dan apakah penyedia berkomitmen untuk mengoordinasikan publikasi atau pengakuan/kreditasi. Jangan berasumsi bahwa suatu kebijakan mengizinkan siapa pun untuk merilis data pengguna atau instruksi eksploitasi. Periksa bagaimana informasi kontak pengiriman dan lampiran dapat disimpan atau dibagikan kepada vendor. Daftar pengakuan publik bisa menjadi hal yang positif, tetapi partisipasi harus bersifat opsional dan tidak boleh mengungkap identitas tanpa izin. Kebijakan GSA menunjukkan bagaimana dokumen publik dapat menggabungkan cakupan yang diizinkan, perilaku yang dilarang, instruksi pelaporan, dan ekspektasi pengungkapan. Untuk aplikasi pendamping, verifikasi juga apakah penyedia aplikasi atau vendor infrastruktur yang ditunjuk memegang kendali atas jalur tersebut. Jika kebijakan mengarahkan pengguna untuk melapor ke pihak ketiga, pengalihan tersebut harus eksplisit dan dapat dilacak dari kedua domain resmi.
Arahkan masalah dengan benar dan catat hasil dari tujuh bukti
Gunakan dukungan biasa untuk masalah akses akun, pelecehan, laporan konten, pertanyaan langganan, atau dugaan peretasan pada akun Anda sendiri. Gunakan saluran kerentanan untuk kelemahan produk yang dapat direproduksi yang berpotensi memengaruhi kerahasiaan, integritas, autentikasi, otorisasi, atau perilaku layanan. Jika ragu, kirimkan deskripsi minimal untuk menanyakan jalur mana yang sesuai; jangan lampirkan kode eksploitasi atau rekaman pribadi pada kontak pertama. Nilai hanya bukti yang dapat diamati: kemudahan penemuan resmi, cakupan saat ini, aturan perilaku yang diizinkan, pengiriman yang aman, konfirmasi penerimaan, komunikasi status, serta ketentuan penutupan atau pengungkapan. Tandai masing-masing sebagai ada, tidak jelas, atau tidak ada, lalu simpan URL resmi dan tanggal pemeriksaan. Tujuh item yang terpenuhi tidak menjamin keamanan aplikasi, sementara item yang hilang tidak membuktikan adanya kelalaian. Keduanya menunjukkan seberapa besar tingkat kepercayaan yang dapat diberikan pengguna terhadap proses pelaporan itu sendiri.
Pertanyaan umum
Apakah setiap aplikasi pendamping memerlukan program bug bounty?
Tidak. Program imbalan bersifat opsional. Saluran yang berguna dapat tetap berjalan tanpa pembayaran jika secara jelas mencakup ruang lingkup, perilaku aman, pengiriman, konfirmasi penerimaan, komunikasi, dan pengungkapan.
Haruskah saya menguji aplikasi untuk melihat apakah kebijakan kerentanannya berfungsi?
Tidak. Evaluasi dokumen publik dan jalur kontak resmi secara pasif. Jangan mengakses akun lain, menyimpan data pengguna, mengganggu layanan, melewati kontrol keamanan, atau berasumsi memiliki izin.
Apakah berkas security.txt sudah cukup?
Tidak. Berkas tersebut membuat kontak mudah ditemukan, tetapi Anda tetap memerlukan tautan cakupan, aturan, metode pelaporan yang aman, proses respons, dan informasi kepemilikan terkini.
