Keamanan Dependensi dan Rantai Pasok Perangkat Lunak: Mewaspadai Risiko dari Kode yang Anda Pakai

Aplikasi bisnis modern hampir tidak pernah ditulis sepenuhnya dari nol. Pengembang memakai ratusan, bahkan ribuan, pustaka dan komponen pihak ketiga: untuk antarmuka, pembayaran, pengiriman surel, pengolahan gambar, dan banyak hal lainnya. Pendekatan ini menghemat waktu dan biaya, tetapi membawa konsekuensi yang jarang dibicarakan di luar kalangan teknis: Anda mewarisi risiko keamanan dari setiap komponen yang Anda pakai.

Dalam beberapa tahun terakhir, serangan yang menyasar rantai pasok perangkat lunak semakin sering terjadi. Penyerang tidak lagi menembus sistem Anda secara langsung; mereka menyusup ke pustaka populer, layanan pembangunan, atau akun pengembang, lalu menunggu komponen yang tercemar sampai ke ribuan aplikasi. Bisnis yang tidak pernah menjadi target pun bisa terdampak.

Artikel ini menjelaskan keamanan dependensi dan rantai pasok perangkat lunak untuk pemilik bisnis dan pengambil keputusan. Tujuannya bukan membuat Anda menjadi ahli keamanan, melainkan membantu Anda mengajukan pertanyaan yang tepat kepada tim atau vendor, memahami praktik dasar yang masuk akal, dan menghindari kelalaian yang paling umum.

Ringkasan

• Setiap pustaka pihak ketiga adalah bagian dari permukaan serangan aplikasi Anda
• Risiko berasal dari kerentanan yang diketahui dan dari komponen yang sengaja dicemari
• Daftar komponen yang dipakai adalah dasar dari semua langkah keamanan berikutnya
• Pembaruan yang rutin dan terkendali lebih aman daripada menunda hingga menumpuk
• Keamanan rantai pasok melibatkan orang, proses, dan alat, bukan hanya satu produk

Mengapa dependensi menjadi isu bisnis

Sebuah aplikasi web biasa mungkin hanya memuat beberapa puluh pustaka secara langsung, tetapi setiap pustaka itu sendiri bergantung pada pustaka lain, dan seterusnya. Ketika semua lapisan dihitung, jumlahnya bisa mencapai ratusan atau ribuan komponen yang ditulis oleh orang yang tidak Anda kenal, dipelihara oleh sukarelawan, dan diperbarui tanpa Anda ikut serta.

Setiap komponen itu adalah kode yang berjalan dengan hak akses yang sama dengan aplikasi Anda. Pustaka yang bermasalah dapat membaca data pelanggan, mencuri kunci akses, atau membuka pintu belakang. Yang membuatnya sulit adalah keterlihatannya: tanpa alat dan proses, kebanyakan bisnis tidak tahu persis komponen apa yang berjalan di sistemnya.

Dari sudut pandang bisnis, dampaknya nyata: kebocoran data pelanggan, gangguan layanan, kerugian reputasi, kewajiban hukum, dan biaya pemulihan. Semua ini terjadi bukan karena Anda kurang berhati-hati dalam kode yang Anda tulis, melainkan karena kode orang lain yang Anda percayai.

Jenis-jenis risiko rantai pasok

Risiko pada dependensi tidak seragam. Memahami jenisnya membantu menentukan pertahanan yang sesuai, karena cara menghadapi kerentanan lama berbeda dengan cara menghadapi komponen yang sengaja dicemari.

• Kerentanan yang diketahui: cacat pada versi pustaka yang sudah dipublikasikan dan dapat dieksploitasi
• Paket berbahaya: pustaka yang sengaja dibuat untuk mencuri data atau menjalankan kode jahat
• Pengambilalihan akun pemelihara: penyerang menguasai akun pengembang pustaka yang sah lalu merilis versi tercemar
• Salah ketik nama paket: paket berbahaya bernama mirip pustaka populer yang terpasang karena salah ketik
• Konfusi dependensi: sistem pembangunan mengambil paket publik berbahaya menggantikan paket internal
• Pembangunan yang tercemar: alat atau layanan pembangunan dan penerbitan disusupi
• Pustaka yang ditinggalkan: komponen tanpa pemelihara sehingga kerentanan tidak pernah diperbaiki

Kategori terakhir sering diremehkan. Pustaka yang dulu populer dan kini tidak dipelihara tetap berjalan di banyak aplikasi, dan ketika kerentanan baru ditemukan, tidak ada yang memperbaikinya. Mengenali komponen yang sudah ditinggalkan adalah bagian penting dari pengelolaan risiko.

Langkah pertama: ketahui apa yang Anda pakai

Anda tidak dapat melindungi apa yang tidak Anda ketahui. Langkah pertama yang paling berharga adalah memiliki daftar lengkap komponen yang dipakai aplikasi, termasuk versi dan asalnya. Daftar ini sering disebut bill of materials perangkat lunak, atau SBOM, dan semakin diminta oleh pelanggan korporasi maupun regulator.

Daftar ini sebaiknya dihasilkan otomatis dari proses pembangunan, bukan disusun manual yang cepat usang. Dengan daftar tersebut, ketika sebuah kerentanan besar diumumkan, Anda dapat menjawab dalam hitungan menit: apakah kami memakai komponen itu, di aplikasi mana, dan versi berapa? Tanpa daftar, jawabannya memerlukan berhari-hari penelusuran.

1. 01Hasilkan daftar komponen langsung dan tidak langsung secara otomatis untuk setiap aplikasi
2. 02Catat versi, sumber, dan lisensi setiap komponen
3. 03Simpan daftar bersama setiap rilis agar dapat ditelusuri ke belakang
4. 04Hubungkan daftar dengan sumber informasi kerentanan yang diperbarui terus-menerus
5. 05Beri tanda pada komponen kritis, yang tidak terpelihara, atau yang berlisensi bermasalah

Pemindaian kerentanan dan prioritas perbaikan

Alat pemindai dapat membandingkan daftar komponen Anda dengan basis data kerentanan yang dikenal dan memberi peringatan bila ada yang cocok. Ini murah dan otomatis, sehingga sudah selayaknya menjadi bagian dari proses pembangunan. Namun alat ini juga dapat menghasilkan banyak peringatan, dan di sinilah penilaian manusia diperlukan.

Tidak semua kerentanan sama berbahayanya bagi Anda. Sebuah cacat parah pada fungsi yang tidak pernah Anda panggil mungkin tidak dapat dieksploitasi, sedangkan cacat sedang pada komponen yang menghadap internet bisa sangat berbahaya. Prioritaskan berdasarkan keparahan, apakah komponen tersebut menghadap publik, dan apakah ada eksploitasi aktif yang diketahui.

Tetapkan juga siapa yang bertanggung jawab. Peringatan tanpa pemilik tidak akan diselesaikan. Setiap aplikasi sebaiknya memiliki orang atau tim yang jelas yang menerima, menilai, dan menutup temuan, serta jangka waktu yang disepakati untuk setiap tingkat keparahan.

Pembaruan: disiplin kecil yang berdampak besar

Banyak insiden besar terjadi bukan karena kerentanan baru, melainkan karena perbaikan yang sudah tersedia berbulan-bulan namun belum diterapkan. Menunda pembaruan karena takut merusak sesuatu terasa aman, tetapi justru menumpuk risiko dan membuat pembaruan berikutnya semakin besar dan menakutkan.

Pendekatan yang lebih sehat adalah pembaruan kecil dan sering, didukung pengujian otomatis yang memberi keyakinan bahwa perubahan tidak merusak fungsi penting. Pembaruan kecil lebih mudah diuji, lebih mudah dibatalkan, dan lebih mudah dicari penyebabnya bila ada masalah.

• Pembaruan keamanan diterapkan segera setelah diuji, bukan menunggu jendela besar
• Pembaruan versi besar dijadwalkan secara berkala dengan waktu untuk pengujian
• Pengujian otomatis yang cukup agar perubahan dapat divalidasi dengan cepat
• Rencana pembatalan bila pembaruan menyebabkan masalah
• Alat yang mengusulkan pembaruan secara otomatis untuk ditinjau manusia

Memilih dan menilai komponen sebelum memakainya

Pencegahan paling murah terjadi sebelum sebuah komponen masuk ke aplikasi Anda. Sebelum memakai pustaka baru, tanyakan beberapa hal sederhana yang dapat dijawab dalam beberapa menit: apakah ia dipelihara secara aktif, berapa banyak yang memakainya, apakah ada riwayat masalah keamanan, dan bagaimana lisensinya. Pemeriksaan ini makin penting ketika kode ditulis dengan bantuan asisten AI, yang kadang menyarankan pustaka usang atau bahkan tidak ada, seperti dibahas dalam pengembangan software dengan bantuan AI.

• Aktivitas pemeliharaan: rilis terakhir, respons terhadap masalah, dan jumlah pemelihara
• Popularitas dan penggunaan: komponen yang dipakai luas lebih banyak dikaji pihak lain
• Riwayat kerentanan dan kecepatan perbaikannya
• Jumlah dependensi yang dibawanya, karena setiap tambahan memperbesar permukaan serangan
• Lisensi yang kompatibel dengan model bisnis Anda
• Apakah fungsinya benar-benar diperlukan atau bisa ditulis sendiri dengan sederhana

Pertanyaan terakhir sering diabaikan. Mengambil pustaka besar hanya untuk satu fungsi kecil menambah risiko tanpa perlu. Kadang menulis beberapa baris kode sendiri lebih aman daripada menambah dependensi baru, selama fungsinya sederhana dan tidak menyangkut hal sensitif seperti kriptografi.

Mengamankan proses pembangunan dan rilis

Rantai pasok tidak hanya tentang pustaka yang Anda ambil, tetapi juga bagaimana aplikasi Anda sendiri dibangun dan dikirimkan. Bila sistem pembangunan Anda disusupi, penyerang dapat menyisipkan kode jahat ke dalam produk Anda sendiri, lalu didistribusikan kepada pelanggan Anda dengan tanda tangan yang tampak sah.

• Akses ke repositori kode dan sistem pembangunan dengan autentikasi berlapis
• Hak akses minimum untuk akun dan token yang dipakai proses otomatis
• Penyimpanan rahasia dan kunci di tempat khusus, bukan di dalam kode
• Peninjauan kode oleh orang kedua sebelum perubahan digabungkan
• Penguncian versi dependensi agar pembangunan dapat diulang secara konsisten
• Pencatatan jejak siapa mengubah apa dan kapan pada seluruh alur rilis

Rahasia yang tertanam di dalam kode adalah kesalahan klasik. Kunci akses yang tersimpan di repositori, apalagi yang bersifat publik, dapat ditemukan dan disalahgunakan dalam hitungan menit. Pakailah pengelola rahasia, dan pindai repositori secara otomatis untuk mendeteksi rahasia yang tidak sengaja tersimpan.

Rantai pasok di luar kode: vendor dan layanan

Rantai pasok bisnis Anda juga mencakup layanan pihak ketiga yang terhubung ke sistem: penyedia pembayaran, layanan analitik, alat dukungan pelanggan, dan banyak lagi. Skrip yang dimuat dari layanan luar ke halaman toko online Anda dapat mencuri data pembayaran bila penyedianya disusupi.

Kendalikan apa yang boleh berjalan di sistem Anda. Batasi skrip pihak ketiga pada yang benar-benar diperlukan, gunakan kebijakan keamanan konten yang membatasi sumber skrip, dan tinjau secara berkala layanan eksternal yang terhubung. Setiap integrasi adalah kepercayaan yang Anda berikan; pastikan ia pantas.

Untuk vendor perangkat lunak yang Anda beli atau sewa, ajukan pertanyaan tentang praktik keamanan mereka: bagaimana mereka mengelola dependensi, seberapa cepat mereka memperbaiki kerentanan, apakah mereka menyediakan daftar komponen, dan bagaimana mereka memberi tahu pelanggan saat terjadi insiden.

Lisensi dan kepatuhan komponen sumber terbuka

Selain keamanan, dependensi membawa aspek hukum: lisensi. Setiap komponen sumber terbuka datang dengan ketentuan yang menentukan bagaimana ia boleh dipakai, dimodifikasi, dan didistribusikan. Sebagian lisensi sangat longgar, sebagian lain mensyaratkan pembukaan kode turunan atau pencantuman atribusi. Mengabaikannya dapat menimbulkan sengketa atau memaksa perubahan produk di saat yang tidak tepat.

Daftar komponen yang sama yang dipakai untuk keamanan juga dapat dipakai untuk memeriksa lisensi. Tetapkan kebijakan sederhana tentang jenis lisensi yang diterima, yang perlu ditinjau, dan yang dilarang untuk produk Anda. Dengan begitu, pengembang dapat memutuskan dengan cepat dan tim hukum hanya menangani kasus yang benar-benar memerlukan perhatian.

Hal ini terutama penting bila Anda menjual aplikasi kepada pelanggan, menyediakan perangkat lunak sebagai layanan, atau sedang bersiap untuk investasi atau akuisisi. Pihak yang menilai bisnis Anda hampir pasti akan memeriksa kepatuhan lisensi, dan daftar yang rapi mempercepat prosesnya.

Menyeimbangkan kecepatan dan keamanan

Ada ketegangan alami antara bergerak cepat dan berhati-hati. Tim produk ingin fitur baru segera rilis, sementara kontrol keamanan terasa seperti penghambat. Cara menyelesaikannya bukan dengan memilih salah satu, melainkan dengan membuat kontrol keamanan menjadi bagian otomatis dari alur kerja sehingga hampir tidak menambah gesekan.

Pemindaian otomatis pada setiap perubahan, pembaruan yang diusulkan secara otomatis, dan pemeriksaan lisensi yang berjalan di latar belakang memberi perlindungan tanpa menambah pekerjaan manual yang besar. Yang memerlukan keputusan manusia hanyalah pengecualian dan temuan yang berisiko tinggi, sehingga perhatian tim tertuju pada hal yang paling penting.

Kesiapan menghadapi insiden

Sebaik apa pun pencegahannya, insiden tetap mungkin terjadi. Persiapan menentukan apakah insiden itu terkendali atau berubah menjadi krisis. Rencanakan sebelumnya: siapa yang dihubungi, bagaimana menilai dampak, bagaimana mengisolasi sistem yang terpengaruh, dan bagaimana memberi tahu pelanggan serta pihak berwenang bila diperlukan.

Daftar komponen yang akurat sangat membantu saat insiden. Ketika kerentanan besar diumumkan, tim yang punya daftar dapat segera tahu apakah terdampak dan di mana, lalu memperbaikinya sebelum penyerang sempat memanfaatkannya. Tim yang tidak punya harus meraba-raba sementara waktu terus berjalan.

Latih rencana ini seperti latihan kebakaran. Simulasikan skenario, misalnya sebuah pustaka populer diumumkan tercemar, dan telusuri apa yang akan dilakukan. Latihan sederhana selama satu jam sering mengungkap celah yang tidak terlihat di atas kertas.

Langkah awal yang realistis

1. 01Minta tim atau vendor Anda menghasilkan daftar komponen untuk aplikasi paling penting
2. 02Aktifkan pemindaian kerentanan otomatis pada proses pembangunan
3. 03Tetapkan pemilik, ambang prioritas, dan jangka waktu perbaikan untuk setiap tingkat keparahan
4. 04Terapkan kebiasaan pembaruan rutin dengan dukungan pengujian otomatis
5. 05Pindahkan rahasia dari kode ke penyimpanan khusus dan aktifkan pemindaian rahasia
6. 06Tinjau skrip dan layanan pihak ketiga yang berjalan di sistem Anda dan singkirkan yang tidak perlu
7. 07Susun rencana insiden singkat dan latih sekali dalam setahun

Pertanyaan yang layak diajukan kepada tim atau vendor

Pertanyaan-pertanyaan berikut tidak memerlukan keahlian teknis untuk diajukan, tetapi jawabannya mengungkap banyak hal tentang kematangan sebuah tim. Jawaban yang jelas dan percaya diri adalah pertanda baik, sedangkan jawaban yang mengambang atau defensif menunjukkan area yang perlu diperbaiki sebelum insiden terjadi.

• Apakah kami memiliki daftar lengkap komponen yang dipakai aplikasi kami, dan seberapa mutakhir?
• Bagaimana kami diberi tahu bila ada kerentanan pada komponen yang kami pakai?
• Berapa lama rata-rata dari pengumuman kerentanan kritis hingga perbaikan diterapkan?
• Siapa yang dapat mengubah kode dan proses rilis kami, dan bagaimana aksesnya dilindungi?
• Di mana rahasia dan kunci disimpan, dan siapa yang dapat mengaksesnya?
• Apa yang akan kita lakukan jika sebuah pustaka populer yang kita pakai ternyata tercemar?

Penutup

Keamanan rantai pasok perangkat lunak bukan masalah yang dapat diselesaikan sekali dan dilupakan. Ia adalah disiplin berkelanjutan: mengetahui apa yang Anda pakai, memantau kerentanan, memperbarui secara rutin, memilih komponen dengan hati-hati, dan mengamankan proses pembangunan.

Bagi pemilik bisnis, langkah terpenting adalah mengajukan pertanyaan yang tepat dan memastikan ada pemilik yang bertanggung jawab. Dengan beberapa kebiasaan dasar yang konsisten, Anda dapat memanfaatkan manfaat komponen pihak ketiga tanpa menanggung risiko yang tidak terkendali.