10 risiko keamanan dan operasional sumber terbuka teratas tahun 2023

Endor Labs, sebuah perusahaan perangkat lunak yang memfasilitasi keamanan dan pemeliharaan perangkat lunak sumber terbuka, telah merilis sebuah laporan yang mengidentifikasi 10 risiko keamanan dan operasional teratas dalam perangkat lunak sumber terbuka pada tahun 2023.

Dilakukan oleh tim Station 9 Endor Labs, laporan tersebut menampilkan kontribusi dari lebih dari 20 petugas keamanan informasi kepala industri dari perusahaan terkenal termasuk Adobe, HashiCorp, Discord dan Palo Alto Networks.

Menurut Endor Labs, ketergantungan yang berlebihan pada perangkat lunak sumber terbuka telah mencatat beberapa kerentanan yang diketahui, ditangkap sebagai Kerentanan Umum dan Eksposur; kerentanan ini sering diabaikan dan dapat dimanfaatkan oleh penyerang jika tidak diperbaiki.

“Perangkat lunak sumber terbuka mewakili tambang emas bagi pengembang aplikasi, tetapi membutuhkan kemampuan keamanan yang sama efektifnya,” kata Henrik Plate, peneliti keamanan utama di Endor Labs. “Di lingkungan di mana lebih dari 80% kode dalam aplikasi baru berasal dari repositori yang ada, jelas ada risiko serius yang terlibat.”

Risiko sumber terbuka teratas tahun 2023

Sorotan di bawah ini adalah kesimpulan utama dari laporan Endor Labs tentang 10 risiko sumber terbuka teratas di tahun 2023.

Baca Juga : Mengenal Lebih Dalam Tentang Metaverse: Konsep dan Implikasi untuk Masa Depan

1. Kerentanan yang diketahui

Laporan tersebut mengungkapkan bahwa versi komponen sumber terbuka mungkin berisi kode rentan yang secara tidak sengaja diperkenalkan oleh pengembangnya. Kerentanan dapat dieksploitasi dalam perangkat lunak hilir, berpotensi membahayakan kerahasiaan, integritas, atau ketersediaan sistem dan datanya.

2. Kompromi paket yang sah

Menurut laporan Endor, penyerang dapat menargetkan sumber daya yang sah dari proyek yang ada atau infrastruktur distribusi untuk menyuntikkan kode berbahaya ke dalam komponen. Misalnya, mereka dapat membajak akun pengelola proyek yang sah atau mengeksploitasi kerentanan dalam repositori paket. Jenis serangan ini bisa berbahaya karena kode jahat dapat didistribusikan sebagai bagian dari paket yang sah dan sulit dideteksi.

3. Beri nama serangan kebingungan

Penyerang dapat membuat komponen dengan nama yang mirip dengan komponen sumber terbuka atau sistem yang sah. Laporan Endor Labs mengungkapkan bahwa ini dapat dilakukan melalui:

• Salah ketik: Penyerang membuat nama yang salah mengeja nama komponen asli.
• Pembajakan merek: Penyerang menyarankan penulis yang dapat dipercaya.
• Combo-jongkok: Penyerang bermain dengan pola penamaan umum dalam berbagai bahasa atau ekosistem.

Serangan ini dapat digunakan untuk mengelabui pengguna agar mengunduh dan menggunakan komponen berbahaya yang mereka yakini sah.

4. Perangkat lunak tidak terawat

Perangkat lunak yang tidak terpelihara adalah masalah operasional, menurut laporan Endor Labs. Sebuah komponen atau versi dari sebuah komponen mungkin tidak lagi dikembangkan secara aktif, yang berarti tambalan untuk bug fungsional dan non-fungsional mungkin tidak segera disediakan atau tidak disediakan sama sekali oleh proyek sumber terbuka asli. Ini dapat membuat perangkat lunak rentan terhadap eksploitasi oleh penyerang yang menargetkan kerentanan yang diketahui.

5. Perangkat lunak usang

Untuk kenyamanan, beberapa pengembang menggunakan basis kode versi lama ketika ada versi terbaru. Hal ini dapat mengakibatkan proyek kehilangan perbaikan bug penting dan tambalan keamanan, membuatnya rentan terhadap eksploitasi.

6. Ketergantungan yang tidak terlacak

Pengembang proyek mungkin tidak menyadari ketergantungan pada komponen karena beberapa alasan:

• Ini bukan bagian dari daftar bahan perangkat lunak komponen hulu.
• Alat analisis komposisi perangkat lunak tidak berjalan atau tidak mendeteksinya.
• Ketergantungan tidak dibuat menggunakan manajer paket, yang dapat menyebabkan masalah keamanan, karena kerentanan dalam ketergantungan yang tidak terlacak mungkin tidak diketahui.

7. Risiko lisensi dan regulasi

Sebuah komponen atau proyek mungkin tidak memiliki lisensi atau mungkin memiliki lisensi yang tidak sesuai dengan penggunaan yang dimaksudkan atau yang persyaratannya tidak atau tidak dapat dipenuhi.

Menggunakan komponen sesuai dengan ketentuan lisensinya sangatlah penting. Gagal melakukannya, seperti menggunakan komponen tanpa lisensi atau tidak mematuhi ketentuannya, dapat mengakibatkan pelanggaran hak cipta atau lisensi. Dalam hal demikian, pemegang hak cipta berhak mengambil tindakan hukum.

Selain itu, melanggar persyaratan hukum dan peraturan dapat membatasi atau menghalangi kemampuan untuk menangani industri atau pasar tertentu.

8. Perangkat lunak yang belum matang

Proyek sumber terbuka mungkin tidak mengikuti praktik terbaik pengembangan, seperti menggunakan skema pembuatan versi standar, memiliki rangkaian uji regresi, atau memiliki pedoman atau dokumentasi tinjauan. Hal ini dapat mengakibatkan komponen sumber terbuka tidak berfungsi dengan andal atau aman, membuatnya rentan terhadap eksploitasi.

Mengandalkan komponen atau proyek yang belum matang dapat menimbulkan risiko operasional yang signifikan. Misalnya, perangkat lunak yang bergantung padanya mungkin tidak berfungsi sebagaimana mestinya, menyebabkan masalah keandalan runtime.

9. Perubahan yang tidak disetujui (dapat diubah)

Saat menggunakan komponen yang tidak dijamin identik saat diunduh pada waktu yang berbeda, terdapat risiko keamanan yang signifikan. Ini ditunjukkan oleh serangan seperti Codecov Bash Uploader, di mana skrip yang diunduh disalurkan langsung ke bash tanpa memverifikasi integritasnya sebelumnya. Penggunaan komponen yang dapat berubah juga menimbulkan ancaman terhadap stabilitas dan reproduktifitas pembuatan perangkat lunak.

10. Ketergantungan terlalu kecil/besar

Laporan Endor menunjukkan bahwa kelebihan/ketergantungan pada komponen dapat menjadi risiko operasional. Misalnya, komponen kecil, seperti yang hanya berisi beberapa baris kode, rentan terhadap risiko yang sama dengan komponen yang lebih besar. Risiko ini termasuk pengambilalihan akun, permintaan penarikan berbahaya, dan integrasi berkelanjutan dan pengembangan berkelanjutan kerentanan pipa.

Di sisi lain, komponen besar mungkin telah mengumpulkan banyak fitur yang tidak diperlukan untuk kasus penggunaan standar. Fitur-fitur ini meningkatkan permukaan serangan komponen dan dapat memperkenalkan dependensi yang tidak terpakai, yang mengakibatkan kembung.

Langkah-langkah yang harus diambil untuk mengurangi risiko sumber terbuka ini

Berikut tips dari Endor Labs tentang bagaimana pengembang perangkat lunak dan manajer TI dapat memitigasi risiko sumber terbuka ini.

Pindai kode secara teratur untuk menemukan paket yang disusupi

Mencegah paket yang dikompromikan adalah masalah yang rumit karena tidak ada solusi yang cocok untuk semua. Untuk mengatasinya, organisasi dapat mengacu pada standar dan kerangka kerja yang muncul seperti OpenSSF Secure Supply Chain Consumption Framework (S2C2F).

Mereka dapat memilih dan memprioritaskan pengamanan yang paling sesuai dengan kebutuhan mereka berdasarkan kebutuhan keamanan khusus dan toleransi risiko mereka.

Periksa apakah proyek mengikuti praktik terbaik pengembangan

Untuk menilai kualitas dan mata uang proyek, periksa dokumentasi dan catatan rilisnya untuk kelengkapan dan ketepatan waktu. Cari badge yang menunjukkan cakupan pengujian atau keberadaan pipeline CI/CD yang dapat mendeteksi regresi.

Selain itu, Anda dapat mengevaluasi proyek dengan memeriksa jumlah pengelola dan kontributor aktif, seberapa sering rilis baru dibuat, dan jumlah masalah serta permintaan penarikan yang dibuka dan ditutup. Penting juga untuk mencari informasi tentang strategi pemeliharaan atau dukungan proyek — misalnya, keberadaan dan tanggal versi dukungan jangka panjang.

Selalu perbarui dependensi dan periksa karakteristik kode sebelum menggunakannya

Untuk memastikan keamanan kode, memeriksa kode dan karakteristik proyek itu penting. Contoh karakteristik kode yang harus diperiksa termasuk pengait sebelum dan sesudah pemasangan dan muatan yang disandikan. Untuk karakteristik proyek, pertimbangkan repositori kode sumber, akun pengelola, frekuensi rilis, dan jumlah pengguna hilir.

Salah satu cara untuk menjaga agar dependensi tetap mutakhir adalah dengan menggunakan alat yang menghasilkan permintaan penggabungan atau penarikan dengan saran pembaruan. Penting juga untuk menjadikan pembaruan dependensi dan item simpanan berulang sebagai prioritas.

Evaluasi dan bandingkan alat analisis komposisi perangkat lunak

Tim keamanan harus memastikan alat SCA mampu menghasilkan bill of material yang akurat, baik pada tingkat butiran kasar, seperti untuk dependensi yang dideklarasikan dengan bantuan alat manajemen paket seperti Maven atau npm, dan tingkat butiran halus, seperti untuk artefak seperti file tunggal termasuk “out of band” tanpa menggunakan manajer paket.

Gunakan komponen sesuai dengan ketentuan lisensi sumber terbuka

Pemimpin TI harus memastikan pengembang perangkat lunak mereka menghindari penggunaan komponen sumber terbuka tanpa lisensi, karena hal ini dapat menimbulkan risiko hukum. Untuk memastikan kepatuhan dan menghindari potensi masalah hukum, penting untuk mengidentifikasi lisensi yang dapat diterima untuk komponen yang digunakan dalam pengembangan perangkat lunak.

Faktor yang perlu dipertimbangkan termasuk bagaimana komponen dihubungkan, model penyebaran dan skema distribusi yang dimaksud. Setelah Anda mengidentifikasi lisensi yang dapat diterima, patuhi persyaratan yang dinyatakan dalam lisensi sumber terbuka tersebut.

Baca Juga : 10 risiko keamanan dan operasional sumber terbuka teratas tahun 2023