SecureBuild , sebuah layanan yang membuat build aman dari proyek open source sambil berbagi pendapatan dengan maintainer, telah menarik perhatian dari komunitas teknologi - namun tidak selalu karena alasan yang mereka harapkan. Janji mereka untuk service level agreement (SLA) 6 hari dalam memperbaiki kerentanan kritis telah memicu diskusi sengit tentang apa yang merupakan waktu respons keamanan yang tepat dalam lanskap ancaman saat ini.
Kontroversi SLA 6 Hari
Komitmen 6 hari perusahaan untuk perbaikan CVE kritis telah menjadi sasaran kritik yang tajam. Para profesional keamanan di komunitas mempertanyakan apakah timeline ini memenuhi standar keamanan modern. Beberapa organisasi dilaporkan mendorong batas 48 jam untuk patch kerentanan kritis, membuat janji SecureBuild terlihat lambat sebagai perbandingan.
Namun, realitanya tampak lebih kompleks. Meskipun SecureBuild bertujuan untuk memberikan perbaikan jauh lebih cepat dari janji 6 hari mereka, mereka mengakui bahwa pohon dependensi yang dalam terkadang dapat memperumit proses patching. Perusahaan memiliki rencana ambisius untuk akhirnya mengurangi waktu respons mereka menjadi hanya 6 jam, meskipun mereka belum memberikan timeline untuk mencapai tujuan ini.
Perbandingan Timeline SLA SecureBuild
- CVE Kritis: SLA 6 hari (target: 6 jam)
- CVE Tinggi/Sedang/Rendah: SLA 13 hari
- Ekspektasi industri: 48 jam untuk kerentanan kritis
- Standar audit: Seringkali mewajibkan 30 hari untuk kerentanan kritis
Memikirkan Ulang Strategi Respons CVE
Kritik yang sangat tajam muncul dari diskusi komunitas, menantang seluruh pendekatan berlomba memperbaiki setiap CVE. Para ahli keamanan berargumen bahwa organisasi seharusnya tidak melacak kerentanan dalam hitungan hari, tetapi seharusnya fokus pada patching sebelum eksploitasi aktif dimulai di dunia nyata.
Anda perlu mengeluarkan patch sebelum eksploitasi aktif di dunia nyata dimulai, itulah satu-satunya metrik yang penting.
Perspektif ini menunjukkan bahwa SecureBuild dan layanan serupa mungkin menyelesaikan masalah yang salah. Daripada menjanjikan waktu respons menyeluruh untuk semua CVE, fokus seharusnya pada mengidentifikasi kerentanan mana yang benar-benar sedang dieksploitasi dan memprioritaskannya sesuai dengan itu.
Pemeriksaan Realitas Model Bisnis
Di luar perdebatan teknis, anggota komunitas mempertanyakan premis bisnis fundamental. Seorang pengamat mencatat bahwa mungkin ada tumpang tindih minimal antara organisasi yang mendasarkan keamanan mereka pada respons CVE yang cepat dan mereka yang benar-benar tertarik mendukung proyek open source secara finansial.
Kepemimpinan SecureBuild menolak skeptisisme ini, menunjuk pada basis pelanggan mereka yang terdiri dari independent software vendor (ISV) yang mendistribusikan perangkat lunak komersial ke lingkungan enterprise seperti bank dan lembaga pemerintah. Mereka mengklaim hampir setengah dari pelanggan mereka adalah perusahaan open-core sendiri, menunjukkan bahwa memang ada pasar untuk organisasi yang sadar keamanan yang ingin mendukung keberlanjutan open source.
Model Pembagian Pendapatan
- Pengelola open source: 70% dari pendapatan berlangganan
- SecureBuild : 30% dari pendapatan berlangganan
- Tidak memerlukan kontrak dukungan
- Tidak diperlukan perubahan kode dari proyek-proyek
Melihat ke Depan
Diskusi ini mengungkapkan ketegangan yang lebih luas dalam industri keamanan antara manajemen kerentanan yang komprehensif dan respons ancaman yang tertarget. Meskipun model pembagian pendapatan 70-30 SecureBuild dengan maintainer open source mengatasi tantangan keberlanjutan yang nyata, pendekatan keamanan mereka mungkin perlu penyempurnaan untuk memenuhi ekspektasi industri yang berkembang.
Seiring organisasi semakin menuntut waktu respons yang lebih cepat dan prioritisasi ancaman yang lebih canggih, layanan seperti SecureBuild perlu menyeimbangkan timeline ambisius mereka dengan realitas praktis dari dependensi perangkat lunak yang kompleks dan sifat sebenarnya dari ancaman keamanan.
Referensi: Secure, Sustainable Open Source