Setiap proyek serius punya halaman keamanan, dan halaman itu murah. Pertanyaan yang berguna adalah apakah laporan yang dikirim melalui saluran yang didokumentasikan menghasilkan rilis yang diperbaiki dan dapat dipasang oleh pengguna biasa. Itu memerlukan empat bukti, bukan satu klaim, dan semuanya dapat diperiksa dari luar tanpa menyelidiki apa pun. Tidak satu pun memerlukan uji terhadap server orang lain. Semuanya muat dalam satu halaman catatan.

Temukan salurannya dan pastikan saluran itu ada

Mulailah dari jalur yang didokumentasikan: halaman kebijakan keamanan, alamat khusus, atau berkas /.well-known/security.txt yang bidang Contact-nya ditetapkan oleh RFC 9116.

Lalu baca paragraf cakupan, bukan pengantar yang ramah. Produk mana yang tercakup, versi mana, dan penanganan seperti apa yang diminta proyek?

Saluran milik proyek lain, atau milik penyedia hosting dan bukan pemelihara, bukan proses pengungkapan bagi perangkat lunak yang Anda nilai.

Pelacak publik atau saluran pribadi

Cacat biasa tempatnya di pelacak publik dan mendapat manfaat darinya. Laporan yang memuat detail yang dapat dieksploitasi tidak, dan mengajukannya secara publik membahayakan pengguna saat pemelihara masih membacanya.

Proyek yang hanya menyediakan pelacak publik belum menyediakan saluran pengungkapan, apa pun kata dokumentasinya.

Tidak satu pun dari ini membenarkan pengujian sistem yang bukan milik Anda. Alamat pelaporan adalah undangan untuk mengirim informasi, bukan izin menyelidiki server publik yang tidak terkait.

Ikuti satu perbaikan dari awal sampai akhir

Pilih pengumuman lama dan telusuri: apakah ia menyebut versi yang terdampak dan rilis yang memperbaikinya, dan dapatkah pengguna benar-benar memasang rilis itu?

Jejak itulah perbedaan antara pengakuan dan perbaikan. Balasan sopan yang tidak pernah menghasilkan rilis adalah hasil hubungan masyarakat. Pengumuman singkat dengan nomor versi dan tautan unduhan adalah proses yang berjalan. Pengumuman yang baik menjawab empat hal dengan cepat: apa yang terdampak, apa dampaknya, versi mana yang memperbaiki, dan dari mana mendapatkannya.

Riwayat rilis melengkapi sisanya. Rilis teratur dengan catatan jelas menunjukkan proyek yang mampu mengirimkan perbaikan, dan itu lebih penting daripada kebijakan yang fasih.

Pemelihara klien atau operator layanan

Untuk VPN, orang yang menulis klien dan orang yang mengoperasikan gateway sering kali organisasi berbeda. Masalah pada kode klien dan kesalahan penerapan server memerlukan penerima yang berbeda.

Putuskan mana dari keduanya yang terkait dengan temuan Anda sebelum mengirimnya, karena mengarahkannya ke pihak yang salah biasanya berakhir dengan diam, bukan pantulan.

Apa yang dibuktikan ketiadaan, dan apa yang tidak

Daftar pengumuman yang kosong tidak membuktikan bahwa suatu produk bebas cacat. Itu bisa berarti proyek muda, permukaan kecil, atau tidak ada yang melihat.

Sama halnya, halaman kebijakan yang tidak ada bukan bukti itikad buruk. Itu bukti bahwa Anda tidak dapat memverifikasi prosesnya, dan itulah kesimpulan jujur yang perlu dicatat.

Apa yang perlu dicatat

Catat empat fakta: kontak yang dapat Anda verifikasi, cakupan yang mencakup versi Anda, pengumuman yang menyebut rilis yang diperbaiki, dan riwayat rilis yang menunjukkan bahwa perbaikan dikirim.

Lalu catat apa yang tetap tidak diketahui. Tinjauan yang mengatakan hal itu lebih berguna daripada yang mengubah kebijakan yang tidak ada menjadi klaim keamanan.

Artikel terkait