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 pembangunan berbagai aplikasi teknologi. Dalam berbagai bidang seperti layanan komputasi awan, sistem pengolahan data, hingga produk digital yang digunakan masyarakat. Di balik pemanfaatannya yang luas, sejumlah proyek kritis tetap mengandalkan oleh sedikit kontributor aktif. Kajian mengenai keberlanjutan open source tersebut mengidentifikasi sebanyak 11 proyek dari total 23 hanya memiliki satu atau dua maintainer. Informasi tersebut menggambarkan ketergantungan pada sedikit individu. Perlu diperhatikan bahwa temuan ini merujuk pada daftar penelitian tersebut, bukan semua repositori kode sumber terbuka.

Kondisi tersebut menjadi persoalan penting karena satu komponen dapat mendukung ribuan aplikasi. Jika perangkat lunak penting memiliki jumlah pemelihara yang sangat kecil, beban pemeliharaan dapat meningkat. Tim kecil tersebut biasanya dituntut untuk memeriksa laporan kesalahan, merilis pembaruan keamanan, serta menjawab kebutuhan komunitas. Aktivitas pemeliharaan yang beragam membutuhkan waktu dan perhatian. Jika sumber daya tidak mencukupi, proses pembaruan berpotensi melambat. Oleh karena itu, komunitas perlu membangun dukungan pemeliharaan yang berkelanjutan.

Masalah Pendanaan dan Beban Kerja Maintainer Open Source

Tantangan mendasar dalam keberlanjutan proyek open source adalah keterbatasan pendanaan. Banyak perangkat lunak terbuka bergantung pada waktu luang pengembang. Sementara itu, perusahaan besar dapat memanfaatkan perangkat tersebut untuk mengembangkan layanan kepada pelanggan. Ketidakseimbangan tersebut menimbulkan persoalan keberlanjutan. Dalam situasi yang mungkin terjadi, sebuah pustaka kecil berpotensi menjadi dependensi berbagai sistem, 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. Pengguna perangkat lunak mungkin mengharapkan perbaikan cepat ketika terjadi gangguan perangkat lunak. Namun, pengelola belum tentu bekerja penuh waktu. Tekanan yang berlangsung terus-menerus mungkin mengurangi motivasi pengembangan. Jika kontributor inti meninggalkan proyek, proses pemeliharaan mungkin kehilangan kesinambungan. Oleh sebab itu, pendanaan perlu disertai pembagian tanggung jawab. Strategi pemeliharaan tersebut memberikan peluang keberlanjutan yang lebih baik.

Risiko Keamanan Ketika Proyek Open Source Hanya Dikelola Sedikit Orang

Sedikitnya maintainer aktif menciptakan tantangan dalam pengawasan perubahan kode. Persoalan pertama yang perlu diperhatikan adalah terbatasnya peninjauan kode. Pada pengembangan dengan tata kelola kuat, kontribusi berpeluang mendapat evaluasi teknis tambahan. Di sisi lain, proyek dengan satu maintainer berpotensi melewatkan masalah karena keterbatasan waktu. Situasi tersebut membuat perubahan berbahaya lebih sulit dikenali. Walaupun risiko meningkat, jumlah maintainer kecil tidak otomatis berarti kode tidak aman. Penilaian keamanan tetap harus mempertimbangkan kualitas pengujian otomatis, serta kemampuan merespons laporan kerentanan.

Ancaman lainnya adalah software supply chain attack. Serangan ini, pelaku mencoba memasukkan kode berbahaya ke dalam dependensi. Ketika perubahan berbahaya mencapai versi rilis, kode berbahaya mungkin menyebar melalui pembaruan dependensi. Insiden keamanan XZ Utils yang terungkap pada 2024 memperlihatkan potensi bahaya mengenai penyalahgunaan kepercayaan dalam proyek terbuka. Pada kasus keamanan tersebut, upaya memasukkan backdoor ke komponen penting ditemukan sebelum menyebar luas. Pelajaran utamanya 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, penggunaan dependensi terbuka sering tidak terhindarkan. Banyak aplikasi mengandalkan framework yang dikembangkan komunitas. Cara pengembangan ini membantu mempercepat pembangunan aplikasi. Namun demikian, ketahanan sistem bergantung pula pada kesehatan dependensi. Jika suatu pustaka tidak lagi menerima pembaruan keamanan, perusahaan mungkin kesulitan memperbarui sistem. Dampaknya mungkin meningkatkan paparan serangan siber.

Pentingnya tata kelola dependensi juga tercermin dalam laporan industri. Dalam penelitian State of Open Source tahun 2026 menemukan bahwa patching masih menjadi persoalan penting bagi berbagai tim teknologi informasi. Kajian penggunaan open source tersebut, 20 persen organisasi belum menerapkan alur penanganan kerentanan yang teridentifikasi melalui CVE. Sebagai temuan tambahan, 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.

Strategi Memperkuat Keamanan dan Keberlanjutan Proyek Open Source

Langkah pertama yang dapat dilakukan adalah menyusun inventaris dependensi perangkat lunak. Perusahaan dapat menerapkan inventaris perangkat lunak berbentuk SBOM untuk mencatat komponen yang digunakan. Catatan komponen tersebut membantu menentukan risiko ketika celah ditemukan. Selain itu, gunakan alat analisis komposisi perangkat lunak yang membantu menemukan komponen berisiko. Namun demikian, hasilnya perlu dievaluasi berdasarkan konteks. Untuk menentukan prioritas, kerentanan yang dapat dieksploitasi pada sistem produksi sebaiknya diprioritaskan untuk diperbaiki dibandingkan temuan pada fitur yang tidak digunakan.

Selain memperkuat sistem internal, perusahaan dapat membantu meningkatkan kesehatan ekosistem perangkat lunak. Kontribusi yang dapat diberikan mencakup dukungan finansial maupun teknis. Dalam penerapan nyata, organisasi dapat mendanai pengelola, menugaskan pengembang memperbaiki masalah, serta berkontribusi pada sistem otomasi pemeriksaan. Kolaborasi seperti itu dapat mengurangi tekanan maintainer. Sebagai langkah tata kelola, memperkuat proses transfer tanggung jawab agar proyek tidak bergantung pada satu individu. Melalui strategi yang saling mendukung, ekosistem open source dapat menjadi lebih tangguh.

Pentingnya Dukungan Maintainer bagi Keamanan Infrastruktur Digital

Laporan yang mengidentifikasi 11 proyek dengan pengelola terbatas dari 23 proyek menunjukkan tantangan penting dalam perlindungan rantai pasok software. Ketergantungan pada satu atau dua pengelola dapat meningkatkan risiko keterlambatan pembaruan. Meski kondisi tersebut perlu diperhatikan, tidak semua proyek kecil otomatis tidak aman. Pengguna perangkat lunak dianjurkan menyusun inventaris komponen, menerapkan pembaruan keamanan, serta memberikan dukungan kepada proyek penting. Seiring perkembangan TEKNOLOGI, perlindungan komponen kritis membutuhkan kolaborasi. Bagaimana pendapat Anda, apakah organisasi sebaiknya menyediakan tenaga pengembang untuk membantu proyek terbuka? Ceritakan pengalaman Anda mengenai keamanan perangkat lunak open source.