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.

Sebanyak 11 dari 23 Proyek Open Source Kritis Memiliki Pengelola Terbatas

Perangkat lunak open source menjadi fondasi utama dalam operasional infrastruktur komputasi. Dalam berbagai bidang seperti layanan komputasi awan, aplikasi perusahaan, hingga produk digital yang digunakan masyarakat. Namun demikian, sejumlah proyek kritis tetap mengandalkan oleh jumlah pengelola yang sangat terbatas. Laporan yang dihimpun The Data Drop menemukan 11 proyek dalam daftar berisi 23 perangkat lunak hanya memiliki satu atau dua maintainer. Temuan tersebut menggambarkan ketergantungan pada sedikit individu. Perlu diperhatikan bahwa angka tersebut berlaku pada proyek yang dianalisis, bukan keseluruhan ekosistem perangkat lunak terbuka.

Kondisi tersebut menciptakan tantangan keberlanjutan karena satu komponen dapat mendukung ribuan aplikasi. Ketika sebuah proyek hanya ditangani satu pengembang, beban pemeliharaan dapat meningkat. Maintainer sering perlu menangani keluhan pengguna, merilis pembaruan keamanan, serta menjawab kebutuhan komunitas. Rangkaian tanggung jawab tersebut menuntut ketersediaan tenaga yang memadai. Jika sumber daya tidak mencukupi, proses pembaruan berpotensi melambat. 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. Sejumlah proyek kode sumber terbuka dipelihara oleh individu tanpa pendanaan tetap. Padahal, organisasi komersial sering menggunakan komponen yang sama untuk menjalankan sistem produksi. Ketidakseimbangan tersebut berpotensi menghambat pemeliharaan jangka panjang. Sebagai contoh, sebuah pustaka kecil dapat digunakan oleh banyak aplikasi, tetapi tidak memiliki tim keamanan khusus. Akibatnya, setiap laporan keamanan harus ditangani dengan sumber daya terbatas.

Tidak hanya berkaitan dengan uang, maintainer open source sering menerima beban tanggung jawab tinggi. Komunitas pengguna proyek dapat meminta penanganan segera ketika muncul kerentanan keamanan. Meski permintaan terus berdatangan, pengelola tidak selalu mendapat bayaran untuk pemeliharaan. Kondisi tersebut mungkin mengurangi motivasi pengembangan. Jika kontributor inti meninggalkan proyek, komunitas berpotensi kesulitan mencari pengganti. Dengan demikian, pendanaan perlu disertai pembagian tanggung jawab. Strategi pemeliharaan tersebut memberikan peluang keberlanjutan yang lebih baik.

Ancaman Supply Chain Attack pada Perangkat Lunak Sumber Terbuka

Jumlah pengelola yang terbatas dapat memperbesar sejumlah risiko keamanan. Persoalan pertama yang perlu diperhatikan 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. Situasi tersebut dapat meningkatkan kemungkinan kesalahan tidak terdeteksi. Namun perlu dipahami, jumlah maintainer kecil tidak otomatis berarti kode tidak aman. Faktor seperti prosedur persetujuan perubahan, serta kecepatan perbaikan celah.

Risiko tambahan yang perlu diwaspadai adalah software supply chain attack. Jenis ancaman tersebut, pelaku mencoba memasukkan kode berbahaya ke dalam dependensi. Apabila berhasil, dampaknya dapat meluas ke aplikasi pengguna. Kasus backdoor XZ Utils pada 2024 sering dijadikan pelajaran mengenai penyalahgunaan kepercayaan dalam proyek terbuka. Dalam insiden tersebut, upaya memasukkan backdoor ke komponen penting ditemukan sebelum menyebar luas. Aspek yang perlu diperhatikan adalah perlindungan rantai pasok tidak cukup mengandalkan kepercayaan personal. Untuk mengurangi ancaman serupa, organisasi perlu mengevaluasi dependensi secara rutin.

Risiko Bisnis Jika Software Kritis Tidak Mendapat Pembaruan Keamanan

Untuk organisasi yang menjalankan aplikasi digital, ketergantungan pada open source merupakan hal umum. Berbagai layanan bisnis memanfaatkan komponen perangkat lunak dari proyek lain. Cara pengembangan ini memungkinkan tim berfokus pada fitur utama. Namun demikian, ketahanan sistem bergantung pula pada kesehatan dependensi. Jika suatu pustaka mengalami keterlambatan perbaikan kerentanan, tim keamanan berpotensi menghadapi pekerjaan tambahan. Konsekuensi operasionalnya mungkin meningkatkan paparan serangan siber.

Kebutuhan pemantauan komponen terbuka didukung oleh berbagai kajian keamanan perangkat lunak. Berdasarkan survei industri open source 2026 menyoroti kesulitan penanganan kerentanan bagi berbagai tim teknologi informasi. Dalam penelitian tersebut, 20 persen organisasi melaporkan tidak adanya prosedur tertentu bagi kerentanan CVE. Di sisi perusahaan besar, 39 persen perusahaan besar mengalami kesulitan memenuhi target internal penanganan kerentanan. Hasil survei ini menunjukkan pentingnya kesiapan operasional. Sebagai langkah pengendalian, organisasi sebaiknya memetakan dependensi aplikasinya.

Cara Perusahaan Mendukung Maintainer serta Mengurangi Risiko Software

Strategi dasar untuk memperkuat keamanan adalah membangun daftar pustaka dan framework dalam aplikasi. Perusahaan dapat menggunakan dokumen SBOM untuk mencatat komponen yang digunakan. Data inventaris ini membantu menentukan risiko ketika celah ditemukan. Selain itu, manfaatkan pemindai dependensi yang membantu menemukan komponen berisiko. Namun demikian, peringatan tidak boleh diperlakukan sama pentingnya. Sebagai contoh, kerentanan yang dapat dieksploitasi pada sistem produksi perlu mendapat perhatian lebih besar dibandingkan temuan pada fitur yang tidak digunakan.

Tidak hanya mengandalkan pemindaian keamanan, perusahaan sebaiknya berkontribusi terhadap keberlanjutan maintainer. Pendekatan kolaboratif ini tidak selalu berupa sumbangan uang. Untuk membantu proyek penting, organisasi dapat mendanai pengelola, mengalokasikan waktu karyawan untuk berkontribusi, serta berkontribusi pada sistem otomasi pemeriksaan. Kolaborasi seperti itu mendorong distribusi pengetahuan teknis. Sebagai langkah tata kelola, memperkuat proses transfer tanggung jawab agar proyek tidak bergantung pada satu individu. Melalui strategi yang saling mendukung, risiko ketergantungan berlebihan berpotensi menurun.

Kesimpulan Risiko Keamanan Software Open Source Kritis

Hasil kajian terhadap 23 proyek penting yang menemukan 11 proyek bergantung pada sedikit maintainer menjadi pengingat serius dalam pengelolaan perangkat lunak sumber terbuka. Ketergantungan pada satu atau dua pengelola berpotensi melemahkan ketahanan pemeliharaan. Namun demikian, kualitas tata kelola tetap menjadi faktor penting. Perusahaan perlu memetakan dependensi, menilai risiko penggunaan, serta berkontribusi dalam pemeliharaan open source. Dalam ekosistem digital yang semakin terhubung, perlindungan komponen kritis membutuhkan kolaborasi. Dari sudut pandang Anda, apakah organisasi sebaiknya menyediakan tenaga pengembang untuk membantu proyek terbuka? Ceritakan pengalaman Anda mengenai masa depan keberlanjutan infrastruktur digital.