Pertanyaan
SaaS Anda menemukan kerentanan yang telah diperbaiki yang mungkin telah memengaruhi pelanggan. Tim produk harus memutuskan apakah akan menerbitkan security advisory tersendiri daripada hanya menyebutkannya di halaman status atau incident review. Berikan kerangka keputusan, rencana konten, tindakan pelanggan, dan ukuran keberhasilan.
Skenario dan batasan
Kerentanan ini memengaruhi beberapa versi dan perbaikan telah tersedia, tetapi detailnya dapat membantu penyerang. Pelanggan tersebar di berbagai wilayah; beberapa memerlukan catatan kepatuhan (compliance) dan jendela waktu peningkatan (upgrade). Advisory harus dapat diverifikasi dan dilanggan (subscribable), dengan penyelarasan antara tim support, engineering, dan legal.
Hal yang diuji
Membedakan fungsi utama bagi pengguna antara security advisory, incident review layanan, dan pembaruan pemasaran. Advisory membantu pelanggan menilai tingkat keterpaparan dan remediasi; incident review menjelaskan dampak terhadap layanan dan pencegahannya. Atlassian mengaitkan advisory dengan rilis perbaikan, GitHub menggunakan advisory untuk versi yang terpengaruh serta detail kerentanan, dan CISA menekankan penanganan pengungkapan yang dapat ditindaklanjuti.
Pendekatan referensi
Klasifikasikan tingkat eksploitabilitas, pelanggan yang terpengaruh, tindakan pelanggan yang diperlukan, dan mitigasi saat ini. Jika menerbitkan, sertakan pengidentifikasi, versi yang terpengaruh dan yang telah diperbaiki, linimasa, langkah-langkah deteksi dan mitigasi, jalur dukungan, serta riwayat pembaruan. Tahan detail eksploitasi hingga gerbang perbaikan dan pemberitahuan pelanggan terlewati. Pisahkan incident review untuk ketersediaan layanan, deteksi, respons, dan pencegahan agar catatannya tidak saling bertentangan.
Detail penting
Buat matriks tanggung jawab rilis di seluruh tim security, product, engineering, support, dan legal. Sediakan langganan RSS atau email serta bidang yang dapat dibaca mesin (machine-readable), disertai pemberitahuan terarah untuk pelanggan berisiko tinggi. Ukur waktu dari perbaikan hingga pemberitahuan, konfirmasi penerimaan pelanggan, adopsi patch, tingkat positif palsu, dan ketepatan waktu pembaruan.
Jebakan umum
Hanya mempublikasikan skor CVSS tanpa tindakan bagi pelanggan; menyatakan dampak yang belum dikonfirmasi sebagai fakta; membeberkan detail eksploitasi demi transparansi; memperlakukan incident review sebagai basis data kerentanan; atau mengabaikan versi yang sudah tidak didukung serta perbedaan penerapan yang di-host (hosted deployment).
Rubrik evaluasi
Jawaban yang kuat menjelaskan kapan advisory tersendiri diperlukan dan kapan pemberitahuan terarah harus didahulukan. Jawaban tersebut menentukan gerbang pengungkapan, templat, saluran langganan, dan mekanisme koreksi sambil menyeimbangkan risiko keamanan, kepercayaan pelanggan, dan biaya operasional. Alasan "Terbitkan demi transparansi" saja tidaklah cukup.
Pertanyaan lanjutan
Bagaimana Anda menanggapi saat pelanggan meminta detail eksploitasi lengkap?
Verifikasi identitas, kontrak, dan status remediasi, lalu berikan detail yang diperlukan melalui saluran yang terkontrol. Jaga agar halaman publik tetap dapat ditindaklanjuti tanpa meningkatkan risiko eksploitasi, dan catat keputusan pengungkapan tersebut.
Bagaimana jika daftar versi yang terpengaruh salah setelah publikasi?
Tandai waktu koreksi dan dampaknya segera, pertahankan riwayat versi, dan kirimkan koreksi melalui saluran langganan. Berikan sumber kebenaran (source of truth) yang sama kepada tim support; pengeditan diam-diam dapat menyesatkan pelanggan.
Bagaimana Anda membuktikan bahwa advisory tersebut mengurangi risiko pelanggan?
Korelasikan jumlah pembaca, konfirmasi penerimaan, adopsi patch, dan tiket dukungan berdasarkan versi yang terpengaruh. Pantau positif palsu, pertanyaan berulang, dan sinyal serangan untuk menyempurnakan pengungkapan berikutnya.