Pernah Lapor Celah tapi Vendor Diam Saja? Ini Kronologi Patch Tertunda yang Tak Ada di Changelog

⚡ Jawaban Singkat / Key Takeaways: Tidak semua vendor merespons laporan celah keamanan dengan benar. Riset menunjukkan banyak plugin team melakukan silent fix tanpa CVE, menunda patch berminggu-minggu, atau bahkan menutup thread laporan tanpa solusi. Praktik ini mengikis kepercayaan komunitas open source dan meninggalkan pengguna dalam posisi rentan tanpa informasi mitigasi. Artikel ini mengupas kronologi nyata, pola komunikasi yang gagal, dan framework responsible disclosure yang bisa kamu terapkan sebagai maintainer proyek open source.

Awal yang Selalu Sama: Researcher Menemukan Celah, Vendor Justru Bungkam

Bayangkan skenario ini. Kamu seorang security researcher yang menemukan celah pre-auth SQL injection di plugin WordPress dengan 80.000+ instalasi aktif. Kamu kirim laporan detail lengkap dengan PoC, skenario eksploitasi, dan rekomendasi perbaikan ke tim vendor. Lalu… tidak ada balasan selama tujuh hari. Kamu follow-up lagi. Akhirnya mereka menjawab: “terima kasih, kami sedang review.”

Dua minggu kemudian, plugin tersebut merilis update baru. Kamu cek changelog. Tidak ada satu pun kata tentang celah yang kamu laporkan. Kamu diff kode sumbernya. Ternyata mereka sudah perbaiki silently. Tanpa CVE. Tanpa advisory. Tanpa kredit.

Ini bukan cerita fiksi. Pola ini berulang di lusinan ekosistem plugin open source. Dan dampaknya jauh lebih besar dari sekadar ego researcher yang tidak dikreditkan. Karena ketika vendor melakukan silent fix, pengguna tidak tahu bahwa mereka perlu segera update. Mereka tidak tahu bahwa versi sebelumnya mengandung celah kritis. Mereka tidak bisa melakukan retrospective assessment terhadap insiden yang mungkin sudah terjadi.

Anatomi Vendor Response Timeline: Tiga Pola yang Merusak Kepercayaan

Setelah menganalisis puluhan kasus disclosure di ekosistem open source, ada tiga pola kronologi cacat yang muncul berulang kali. Masing-masing memiliki titik kegagalan yang bisa dipelajari.

Pola 1: The Silent Fixer

• Hari 0: Researcher mengirim laporan via kanal resmi (email, HackerOne, atau GitHub Security Advisory)
• Hari 1-14: Tidak ada respons atau hanya balasan otomatis
• Hari 15: Vendor merilis update plugin dengan perbaikan tersembunyi di changelog (“Bug fixes and improvements”)
• Hari 16+: Researcher menyadari silent fix, mencoba mengonfirmasi, vendor tetap tidak merespons

Masalah utamanya: Pengguna tidak mendapat informasi urgensi update. Situs yang tidak mengaktifkan auto-update tetap rentan selama berbulan-bulan. Maintainer proyek turunan (forks) tidak tahu harus mem-backport patch ke versi mereka.

Baca juga: Plugin Favoritmu Sudah Dipatch? Cek Dulu Plugin Lain yang Pakai Library Rentan yang Sama

Pola 2: The Infinite Delayer

• Hari 0-7: Researcher mengirim laporan, vendor merespons cepat: “Sedang kami pelajari”
• Hari 8-30: Update status berkala tapi tidak ada patch: “Masih dalam review internal”, “Tim engineering sedang sibuk sprint lain”
• Hari 31-90: Researcher mengingatkan tentang batas waktu disclosure policy (biasanya 90 hari). Vendor meminta perpanjangan
• Hari 90+: Researcher memutuskan untuk go public sesuai kebijakan responsible disclosure. Vendor panik dan merilis patch setengah matang

Masalah utamanya: Patch yang dirilis dalam tekanan tenggat waktu seringkali tidak menyeluruh. Vendor hanya memperbaiki symptom (efek yang terlihat), bukan root cause (penyebab mendasar). Enam bulan kemudian, celah serupa muncul lagi di fitur sebelah.

Terkait: CVE-2026-12345: Kenapa Satu Baris unserialize() di admin-ajax Bisa Berubah Jadi Pre-Auth RCE dalam 3 Detik

Pola 3: The Gaslighter

• Hari 0-7: Researcher melaporkan celah, vendor merespons: “Ini bukan vulnerability, ini expected behavior”
• Hari 8-20: Researcher memberikan bukti eksploitasi nyata. Vendor tetap menyanggah
• Hari 21-30: Researcher mem-publish temuan secara publik. Komunitas mulai bertanya-tanya
• Hari 31: Vendor diam-diam merilis patch, tetap tanpa acknowledgment, dan menutup thread diskusi publik

Masalah utamanya: Pola ini tidak hanya mengikis kepercayaan terhadap satu vendor. Pola ini menciptakan efek chilling di seluruh ekosistem. Researcher baru berpikir dua kali sebelum melaporkan celah ke vendor lain. Mereka takut gaslighting. Mereka takut laporannya diabaikan. Akhirnya, beberapa peneliti memilih untuk langsung full disclosure tanpa memberi waktu vendor.

Framework “Radar Respons”: Cara Menilai Kualitas Respons Vendor dalam 4 Dimensi

Bagaimana kamu bisa membedakan vendor yang punya kultur keamanan matang dari yang sekadar pasang muka? Gunakan framework empat dimensi yang saya sebut Radar Respons. Framework ini membantu kamu mengevaluasi vendor sebelum mengadopsi plugin atau library mereka ke dalam proyekmu.

Dimensi	Skor 1 (Buruk)	Skor 3 (Cukup)	Skor 5 (Matang)
Kecepatan Acknowledgment	Tidak ada respons dalam 14 hari	Respons dalam 5-7 hari kerja	Respons dalam 24-48 jam, termasuk hari libur
Kualitas Patch	Silent fix tanpa CVE/changelog	Patch dengan changelog minim, CVE belakangan	Patch + CVE + advisory + credit dalam satu rilis
Transparansi Timeline	Tidak ada komunikasi progres	Update berkala tapi tanpa tanggal pasti	Timeline publik dengan milestone jelas, diperbarui real-time
Post-Mortem	Tidak ada analisis pasca-insiden	Blog post internal tanpa detail teknis	Root cause analysis publik, mencakup perbaikan proses jangka panjang

Skor total minimum yang bisa kamu toleransi adalah 12 dari 20. Jika vendor yang kamu evaluasi mendapat skor di bawah 8, saatnya mempertimbangkan alternatif. Ini bukan soal satu celah keamanan. Ini soal apakah vendor tersebut bisa dipercaya ketika celah berikutnya muncul.

Kenapa Silent Fix Lebih Berbahaya dari yang Kamu Kira

Banyak developer berpikir: “Yang penting celah diperbaiki, ngapain ribut soal proses?” Ini kesalahan cara berpikir yang berbahaya. Silent fix menciptakan tiga lapis risiko yang tidak terlihat di permukaan.

Pertama, patch gap exploitation. Ketika vendor tidak mengumumkan celah, penyerang yang sudah mengetahui kerentanan tersebut (baik dari source code diff, reverse engineering, atau informasi internal) memiliki jendela eksploitasi tanpa batas. Tidak ada yang memberi tahu pengguna untuk segera update. Patch ada, tapi tidak ada urgensi.

Kedua, downstream blindness. Proyek open source tidak hidup dalam ruang hampa. Plugin A mungkin menggunakan library B yang juga dipakai oleh plugin C, D, dan E. Tanpa CVE yang terpublikasi, maintainer plugin C tidak tahu bahwa mereka perlu mem-backport patch ke versi mereka. Inilah yang disebut transitive dependency vulnerability. Satu celah, puluhan plugin, dan hanya satu yang diam-diam diperbaiki.

Ketiga, researcher attrition. Setiap kali researcher diperlakukan buruk oleh vendor, kemungkinan mereka melaporkan celah berikutnya ke vendor yang sama menurun drastis. Ekosistem keamanan open source bergantung pada kontribusi sukarela para peneliti. Jika mereka berhenti melapor, semua orang rugi.

Membangun Responsible Disclosure Policy yang Tidak Cuma Pajangan

Sekarang bagian penting buat kamu yang jadi maintainer proyek open source. Punya halaman “Security Policy” di GitHub itu langkah pertama yang bagus. Tapi kebanyakan policy hanya copy-paste template tanpa mekanisme eksekusi yang nyata.

Ini komponen minimum yang harus ada di disclosure policy-mu, langsung bisa kamu terapkan hari ini:

1. Kanal pelaporan yang terenkripsi. Gunakan GPG key publik untuk email, atau platform seperti GitHub Security Advisory yang mendukung enkripsi end-to-end. Jangan arahkan researcher ke forum publik.
2. SLA respons yang spesifik. Bukan “kami akan merespons secepatnya.” Tapi: “Kami akan mengakui laporanmu dalam 48 jam dan memberikan update status setiap 5 hari kerja.”
3. Batas waktu disclosure yang jelas. Industri standar saat ini adalah 90 hari dari acknowledgment. Jika melampaui batas, researcher berhak mempublikasikan temuan secara publik. Cantumkan ini secara eksplisit.
4. Prosedur kredit dan bounty. Researcher yang laporannya valid harus dikreditkan di changelog, advisory, dan/atau halaman Hall of Fame. Jika kamu punya budget, sediakan bounty moneter. Jika tidak, tawarkan lisensi premium gratis atau swag.
5. Template post-mortem publik. Siapkan template yang mencakup: kronologi laporan, root cause analysis, cakupan dampak, langkah mitigasi, dan perbaikan proses ke depan. Setiap kali ada celah serius, isi template ini dan publikasikan.

Baca juga: Patch Sekarang: Daftar Plugin WordPress Rentan yang Wajib Kamu Update Mei 2026

Ketika Researcher dan Vendor Berselisih: Pelajaran dari Kasus Nyata

Salah satu dinamika paling kompleks dalam ekosistem open source adalah ketika researcher dan vendor tidak sepakat soal severity sebuah celah. Researcher mengklaim “critical, CVSS 9.8.” Vendor membalas: “medium, perlu kondisi spesifik yang jarang terjadi.”

Alih-alih berdebat soal skor, gunakan pendekatan impact-first disclosure. Jelaskan dampak nyata dalam bahasa yang bisa dipahami oleh pengguna non-teknis. Contoh: “Dengan satu HTTP request tanpa autentikasi, penyerang bisa membaca seluruh isi database pelanggan, termasuk password hash, alamat email, dan riwayat transaksi.” Kalimat ini jauh lebih kuat daripada “SQL injection di parameter ‘order_id' dengan CVSS 9.1.”

Pendekatan ini juga menghindari perdebatan semantik tentang definisi “authenticated” vs “unauthenticated.” Fokus pada dampak. Biarkan komunitas menilai sendiri urgency-nya.

Referensi lebih lanjut: baca panduan Google Project Zero Vulnerability Disclosure FAQ dan CISA Coordinated Vulnerability Disclosure Process. Untuk perspektif dari sisi maintainer, lihat juga OWASP Vulnerability Disclosure Cheat Sheet.

FAQ: Pertanyaan yang Sering Muncul Soal Vendor Response dan Responsible Disclosure

Berapa lama waktu yang wajar untuk vendor merespons laporan celah?

Standar industri saat ini menetapkan 90 hari sebagai batas maksimum dari acknowledgment awal hingga patch dirilis. Google Project Zero, salah satu tim paling berpengaruh di dunia vulnerability research, menggunakan kebijakan ini. Namun, untuk celah dengan severity critical yang sedang dieksploitasi secara aktif (in the wild), batas wajar adalah 7 hari. Beberapa regulasi seperti EU Cyber Resilience Act bahkan mengusulkan deadline 24 jam untuk kasus eksploitasi aktif.

Apa yang harus dilakukan jika vendor tidak merespons laporan celah?

Pertama, eskalasi melalui kanal alternatif: coba hubungi individu spesifik di tim engineering via LinkedIn atau Twitter/X. Kedua, laporkan ke koordinator pihak ketiga seperti CERT/CC atau CISA (untuk infrastruktur kritis). Ketiga, setelah batas waktu disclosure policy-mu habis, publikasikan temuan secara publik dengan format yang bertanggung jawab: lampirkan PoC, mitigasi sementara, dan timeline komunikasi lengkap. Jangan pernah mempublikasikan eksploit yang langsung bisa digunakan (weaponized exploit) tanpa memberi waktu kepada pengguna untuk melakukan mitigasi.

Apakah silent fix itu ilegal atau melanggar aturan tertentu?

Tidak ada undang-undang yang secara spesifik melarang silent fix. Namun, praktik ini bisa melanggar ketentuan program seperti CVE Numbering Authority (CNA) jika vendor tersebut adalah CNA. Selain itu, di bawah regulasi seperti NIS2 Directive (Uni Eropa) dan EU Cyber Resilience Act yang mulai berlaku bertahap, vendor perangkat lunak diwajibkan untuk melaporkan kerentanan yang dieksploitasi secara aktif dalam waktu 24 jam ke otoritas terkait. Silent fix pada celah yang sudah dieksploitasi di alam liar berpotensi menjadi pelanggaran regulasi ini.

Kesimpulan: Kepercayaan Tidak Dibangun dari Satu Patch Sempurna

Setiap celah keamanan adalah ujian. Bukan ujian teknis soal seberapa cepat tim engineering bisa menulis patch. Tapi ujian integritas: seberapa jujur vendor berkomunikasi dengan penggunanya. Silent fix dan patch tertunda bukan cuma masalah proses. Mereka adalah sinyal bahwa vendor memprioritaskan reputasi di atas keselamatan pengguna.

Kamu sebagai maintainer open source punya kekuatan untuk mengubah standar ini. Mulai dari tim sendiri. Tulis security policy yang jujur. Hormati researcher yang melaporkan celah. Dan ketika timmu membuat kesalahan (karena semua tim pasti pernah), akui secara terbuka, perbaiki dengan transparan, dan bagikan pelajarannya ke komunitas.

Karena di ekosistem open source, trust adalah dependency yang tidak bisa kamu install lewat composer atau npm. Trust harus dibangun. Satu timeline disclosure yang jujur setiap kalinya.