Hampir Separuh Software Open Source Kritis Bergantung pada Segelintir Pengelola, Risiko Keamanan Meningkat
Keamanan perangkat lunak open source kembali menjadi perhatian setelah laporan terbaru mengungkap bahwa hampir separuh proyek penting dalam sebuah daftar perangkat lunak kritis hanya dikelola oleh satu atau dua orang. Temuan yang diberitakan pada 20 Oktober 2026 tersebut menunjukkan bagaimana infrastruktur digital modern masih bergantung pada kontribusi pengembang dengan sumber daya terbatas. Dari 23 proyek yang dianalisis, sebanyak 11 proyek memiliki jumlah pengelola sangat sedikit. Kondisi ini menimbulkan kekhawatiran terhadap keberlanjutan pemeliharaan, kecepatan perbaikan kerentanan, dan keamanan rantai pasok perangkat lunak. Dalam perkembangan TEKNOLOGI yang semakin kompleks, dukungan terhadap pengelola open source menjadi kebutuhan strategis bagi perusahaan dan pengguna.
Laporan Ungkap Ketergantungan Software Open Source pada Sedikit Pengelola
Ekosistem perangkat lunak sumber terbuka menjadi fondasi utama dalam pengembangan layanan digital modern. Dalam berbagai bidang seperti layanan komputasi awan, platform pengembangan perangkat lunak, hingga berbagai perangkat terhubung internet. Namun demikian, sejumlah proyek kritis tetap mengandalkan oleh tim pemeliharaan berukuran kecil. Kajian mengenai keberlanjutan open source tersebut mengidentifikasi sebanyak 11 proyek dari total 23 ditangani oleh satu hingga dua pemelihara. Hasil pengamatan ini menggambarkan ketergantungan pada sedikit individu. Perlu diperhatikan bahwa proporsi itu berasal dari sampel yang dikaji, bukan semua repositori kode sumber terbuka.
Ketergantungan pada sedikit pengelola menciptakan tantangan keberlanjutan karena sebuah pustaka dapat menjadi fondasi berbagai produk. Jika perangkat lunak penting bergantung pada dua maintainer aktif, beban pemeliharaan dapat meningkat. Tim kecil tersebut biasanya dituntut untuk meninjau perubahan kode, memastikan kompatibilitas versi, serta mengelola kontribusi pengembang lain. Aktivitas pemeliharaan yang beragam memerlukan kemampuan teknis berkelanjutan. Apabila dukungan pengembangan terbatas, keberlanjutan proyek mungkin terganggu. Dengan mempertimbangkan keadaan tersebut, komunitas perlu membangun dukungan pemeliharaan yang berkelanjutan.
Masalah Pendanaan dan Beban Kerja Maintainer Open Source
Salah satu penyebab utama proyek open source adalah minimnya sumber daya operasional. Banyak perangkat lunak terbuka dipelihara oleh individu tanpa pendanaan tetap. Di sisi penggunaan, organisasi komersial sering menggunakan komponen yang sama untuk mendukung aktivitas operasional yang menghasilkan pendapatan. Ketidakseimbangan tersebut berpotensi menghambat pemeliharaan jangka panjang. Dalam situasi yang mungkin terjadi, sebuah pustaka kecil berpotensi menjadi dependensi berbagai sistem, tetapi belum memperoleh dukungan pendanaan yang stabil. Sebagai konsekuensinya, pengembangan fitur perlu bersaing dengan pekerjaan pemeliharaan.
Di luar keterbatasan finansial, maintainer open source dapat mengalami kelelahan akibat banyaknya permintaan. Perusahaan yang memanfaatkan pustaka dapat meminta penanganan segera ketika terjadi gangguan perangkat lunak. Di sisi lain, pengelola tidak selalu mendapat bayaran untuk pemeliharaan. Situasi kerja seperti ini mungkin mengurangi motivasi pengembangan. Ketika pengelola utama tidak lagi aktif, pengetahuan teknis dapat sulit dialihkan. Untuk menjaga keberlangsungan proyek, pengembangan komunitas harus berjalan bersama peningkatan sumber daya. Pendekatan yang berkelanjutan ini membantu mengurangi ketergantungan pada individu.
Risiko Keamanan Ketika Proyek Open Source Hanya Dikelola Sedikit Orang
Sedikitnya maintainer aktif dapat memperbesar sejumlah risiko keamanan. Salah satu risikonya adalah kurangnya pemeriksaan silang. Jika tersedia beberapa pengelola aktif, kontribusi dapat diperiksa oleh lebih dari satu orang. Sebaliknya, proyek dengan satu maintainer mungkin tidak memiliki pemeriksa independen. Kondisi pengawasan semacam itu membuat perubahan berbahaya lebih sulit dikenali. Namun perlu dipahami, jumlah maintainer kecil tidak otomatis berarti kode tidak aman. Penilaian keamanan tetap harus mempertimbangkan prosedur persetujuan perubahan, serta kemampuan merespons laporan kerentanan.
Persoalan keamanan berikutnya adalah serangan terhadap rantai pasok perangkat lunak. Serangan ini, pelaku menargetkan perangkat lunak yang dipercaya pengembang lain. Ketika perubahan berbahaya mencapai versi rilis, berbagai sistem hilir berpotensi terdampak. Insiden keamanan XZ Utils yang terungkap pada 2024 sering dijadikan pelajaran mengenai penyalahgunaan kepercayaan dalam proyek terbuka. Melalui peristiwa tersebut, upaya memasukkan backdoor ke komponen penting ditemukan sebelum menyebar luas. Aspek yang perlu diperhatikan adalah perlindungan rantai pasok tidak cukup mengandalkan kepercayaan personal. Dengan demikian, komunitas harus memperkuat tata kelola perubahan.
Risiko Bisnis Jika Software Kritis Tidak Mendapat Pembaruan Keamanan
Dalam lingkungan bisnis berbasis perangkat lunak, penggunaan dependensi terbuka sering tidak terhindarkan. Banyak aplikasi mengandalkan framework yang dikembangkan komunitas. Cara pengembangan ini memungkinkan tim berfokus pada fitur utama. Walaupun memberikan efisiensi, ketahanan sistem bergantung pula pada kesehatan dependensi. Ketika komponen perangkat lunak penting mengalami keterlambatan perbaikan kerentanan, tim keamanan berpotensi menghadapi pekerjaan tambahan. Konsekuensi operasionalnya berpotensi menambah biaya pemeliharaan.
Pentingnya tata kelola dependensi juga tercermin dalam laporan industri. Laporan State of Open Source 2026 menyoroti kesulitan penanganan kerentanan bagi organisasi pengguna software terbuka. Survei industri itu, 20 persen organisasi melaporkan tidak adanya prosedur tertentu bagi kerentanan CVE. Sebagai temuan tambahan, 39 persen perusahaan besar mengalami kesulitan memenuhi target internal penanganan kerentanan. Temuan tersebut menunjukkan pentingnya kesiapan operasional. Sebagai langkah pengendalian, perusahaan perlu mengetahui komponen yang digunakan.
Cara Perusahaan Mendukung Maintainer serta Mengurangi Risiko Software
Langkah pertama yang dapat dilakukan adalah membangun daftar pustaka dan framework dalam aplikasi. Organisasi sebaiknya memanfaatkan Software Bill of Materials atau SBOM untuk mencatat komponen yang digunakan. Informasi tersebut membantu menentukan risiko ketika celah ditemukan. Untuk memperoleh pemantauan yang lebih baik, gunakan alat analisis komposisi perangkat lunak yang memberikan informasi tentang pembaruan keamanan. Meski alat tersebut dapat mempercepat pemeriksaan, peringatan tidak boleh diperlakukan sama pentingnya. Sebagai contoh, kerentanan yang dapat dieksploitasi pada sistem produksi membutuhkan tindakan lebih cepat dibandingkan temuan pada fitur yang tidak digunakan.
Tidak hanya mengandalkan pemindaian keamanan, perusahaan dapat membantu meningkatkan kesehatan ekosistem perangkat lunak. Bentuk dukungan tersebut tidak selalu berupa sumbangan uang. Dalam penerapan nyata, organisasi dapat mendanai pengelola, menugaskan pengembang memperbaiki masalah, serta membantu pengujian keamanan. Dukungan tersebut dapat mengurangi tekanan maintainer. Untuk menjaga keberlanjutan jangka panjang, membantu regenerasi kontributor agar pengetahuan penting tidak terkonsentrasi. Dengan pendekatan tersebut, keamanan serta keberlanjutan dapat meningkat.
Masa Depan Keberlanjutan Proyek Open Source dalam Industri TEKNOLOGI
Laporan yang mengidentifikasi 11 proyek dengan pengelola terbatas dari 23 proyek menjadi pengingat serius dalam perlindungan rantai pasok software. Ketergantungan pada satu atau dua pengelola mungkin memperbesar beban penanganan keamanan. Namun demikian, keamanan tidak hanya ditentukan jumlah kontributor. Perusahaan perlu menyusun inventaris komponen, mengawasi kerentanan, serta memberikan dukungan kepada proyek penting. Di tengah meningkatnya ketergantungan pada perangkat lunak, keberlanjutan proyek menjadi kepentingan banyak pihak. Menurut Anda, apakah organisasi sebaiknya menyediakan tenaga pengembang untuk membantu proyek terbuka? Ceritakan pengalaman Anda mengenai keamanan perangkat lunak open source.
