Satu perintah instalasi dapat memangkas pekerjaan pengembangan selama beberapa hari. Tim developer tidak perlu menulis kembali fungsi autentikasi, pemrosesan dokumen, pembuatan laporan, komunikasi dengan API, atau komponen antarmuka dari awal. Package open-source membuat pengembangan aplikasi berjalan lebih cepat dan memungkinkan perusahaan memusatkan sumber daya pada kebutuhan bisnis yang lebih penting.

Namun, kecepatan tersebut tidak datang tanpa konsekuensi.

Setiap package yang ditambahkan ke dalam aplikasi membawa kode, proses pemeliharaan, riwayat kerentanan, aturan lisensi, serta ketergantungan terhadap pihak di luar organisasi. Bahkan package yang terlihat sederhana dapat membawa sejumlah dependency tambahan yang tidak pernah dipilih secara langsung oleh developer.

Karena itu, keputusan menggunakan package open-source tidak seharusnya berhenti pada pertanyaan apakah komponen tersebut dapat bekerja. Perusahaan juga perlu mempertanyakan siapa yang memeliharanya, bagaimana pembaruannya dilakukan, risiko apa yang dibawanya, dan seberapa besar dampaknya apabila komponen tersebut bermasalah.

Open-source bukan sumber masalah dengan sendirinya. Risiko muncul ketika perusahaan menikmati efisiensinya tanpa memiliki kendali terhadap dependency yang membentuk aplikasi.

Keputusan Kecil Developer Dapat Menjadi Ketergantungan Besar bagi Perusahaan

Pada tahap awal pengembangan, pemilihan package sering dianggap sebagai keputusan teknis yang sederhana. Developer mencari komponen yang sesuai, memeriksa dokumentasi, menjalankan instalasi, lalu menghubungkannya dengan aplikasi.

Keputusan tersebut mungkin hanya membutuhkan waktu beberapa menit. Akan tetapi, package yang dipilih dapat digunakan selama bertahun-tahun dan menjadi bagian penting dari proses bisnis perusahaan.

Sebuah library dapat memegang fungsi autentikasi pengguna, mengelola komunikasi dengan database, memproses dokumen pelanggan, menangani pembayaran, atau menghubungkan aplikasi dengan sistem eksternal. Ketika fungsi tersebut sudah tertanam dalam arsitektur, menggantinya bukan lagi pekerjaan sederhana.

Perusahaan kemudian bukan hanya menggunakan kode open-source. Perusahaan menjadi bergantung pada arah pengembangan, ketersediaan pembaruan, dan kualitas pemeliharaan proyek tersebut.

Ketergantungan ini semakin penting apabila package digunakan dalam sistem yang melayani pelanggan, menyimpan data sensitif, mendukung transaksi, atau menjadi bagian dari operasional utama. Semakin kritis fungsi yang dijalankan, semakin besar pula konsekuensi bisnis dari setiap kelemahan yang terdapat di dalamnya.

Di sinilah dependency berubah dari persoalan developer menjadi keputusan risiko bisnis.

Kode yang Tidak Ditulis Perusahaan Tetap Menjadi Tanggung Jawab Perusahaan

Ada anggapan bahwa risiko pada package open-source merupakan tanggung jawab pembuat atau pengelola proyek. Pandangan tersebut kurang tepat dari sudut pandang bisnis.

Ketika dependency menyebabkan kebocoran data, gangguan layanan, atau pengambilalihan akun, pelanggan tidak akan memisahkan kode internal dan kode pihak ketiga. Bagi pelanggan, seluruh komponen tersebut merupakan bagian dari aplikasi yang disediakan perusahaan.

Tanggung jawab penanganan insiden juga tidak berpindah kepada maintainer package. Perusahaan tetap harus melakukan investigasi, pemulihan sistem, komunikasi kepada pihak terdampak, serta pengendalian kerusakan reputasi.

Hal yang sama berlaku pada aplikasi yang dibangun oleh vendor. Penggunaan library pihak ketiga oleh vendor tidak menghapus tanggung jawab pemilik sistem. Perusahaan tetap perlu memahami komponen apa yang digunakan dan bagaimana risiko tersebut dikelola setelah aplikasi diserahterimakan.

Package open-source mungkin tidak membutuhkan biaya lisensi. Namun, kegagalan mengelolanya dapat menghasilkan biaya operasional, keamanan, hukum, dan reputasi yang jauh lebih besar.

Satu Package Dapat Membawa Rantai Dependency yang Tidak Terlihat

Daftar package utama sering kali hanya menunjukkan sebagian kecil dari komponen yang benar-benar terdapat dalam aplikasi.

Sebuah package dapat membutuhkan package lain agar dapat bekerja. Package tambahan itu dapat kembali bergantung pada komponen yang berbeda. Hubungan berlapis tersebut membentuk apa yang disebut sebagai transitive dependency.

Developer mungkin hanya memilih satu library secara langsung, tetapi sistem dapat mengunduh puluhan komponen tambahan melalui proses instalasi otomatis. Sebagian komponen bahkan mungkin tidak pernah diperiksa secara manual karena berada jauh di dalam pohon dependency.

Kondisi ini dapat dibandingkan dengan perusahaan yang menunjuk satu pemasok utama. Di balik pemasok tersebut terdapat sejumlah sub pemasok yang ikut memengaruhi kualitas dan keamanan produk akhir. Masalah pada satu sub pemasok tetap dapat mengganggu seluruh rantai.

Dalam pengembangan software, kerentanan pada dependency tidak langsung dapat memiliki dampak yang sama seriusnya dengan kerentanan pada package utama. Perbedaannya, keberadaan dependency tersebut sering tidak diketahui sampai muncul peringatan keamanan atau insiden.

Perusahaan tidak dapat menganggap aplikasi aman hanya karena package utama berasal dari proyek populer. Seluruh rantai komponen perlu dilihat sebagai satu kesatuan risiko software supply chain.

Popularitas Package Bukan Jaminan Keamanan

Jumlah unduhan, bintang pada repository, dan banyaknya tutorial dapat menjadi indikator penerimaan komunitas. Namun, indikator tersebut tidak cukup untuk membuktikan bahwa sebuah package aman digunakan.

Package yang populer tetap dapat memiliki kerentanan. Proyek yang digunakan oleh banyak organisasi juga dapat bergantung pada sedikit maintainer dengan sumber daya terbatas. Dalam kondisi tertentu, popularitas justru meningkatkan daya tarik package sebagai sasaran serangan karena satu kompromi dapat berdampak pada banyak pengguna.

Penilaian risiko dependency perlu melihat faktor yang lebih luas, antara lain:

• aktivitas pembaruan proyek;
• kecepatan respons terhadap laporan kerentanan;
• jumlah maintainer yang aktif;
• keamanan proses publikasi package;
• riwayat perubahan kepemilikan;
• kualitas dokumentasi keamanan;
• dukungan terhadap versi lama;
• kompatibilitas lisensi;
• tingkat akses package terhadap sistem;
• kemudahan mengganti komponen apabila proyek dihentikan.

Package dengan fungsi sederhana tetapi meminta akses luas perlu dipertanyakan. Demikian pula package yang jarang diperbarui, bergantung pada satu pengelola, atau memiliki banyak isu keamanan yang tidak ditangani.

Keputusan yang tepat bukan mencari package yang terlihat sempurna, melainkan memilih komponen yang risikonya dapat dipahami dan dikendalikan.

Risiko Dependency Tidak Berhenti pada Kerentanan yang Memiliki CVE

Pembahasan dependency security sering terpusat pada daftar kerentanan yang telah memiliki identitas CVE. Padahal, risiko package open-source jauh lebih luas.

Kerentanan pada komponen

Package dapat memiliki kelemahan yang memungkinkan penyerang menjalankan kode, melewati autentikasi, membaca data, atau menyebabkan gangguan layanan.

Masalah menjadi lebih serius ketika perusahaan menggunakan versi lama yang tidak lagi memperoleh pembaruan keamanan.

Malicious package

Tidak semua package dibuat dengan tujuan yang sah. Penyerang dapat menerbitkan komponen yang sejak awal dirancang untuk mencuri token, kredensial, data lingkungan pengembangan, atau informasi sensitif lainnya.

Package seperti ini dapat terlihat normal dan bahkan menjalankan fungsi yang dijanjikan. Aktivitas berbahayanya disembunyikan dalam proses instalasi atau fungsi tambahan yang jarang diperiksa.

Typosquatting

Penyerang dapat membuat package dengan nama yang menyerupai komponen populer. Perbedaan satu huruf, tanda baca, atau urutan karakter dapat membuat developer menginstal package yang salah.

Kesalahan sederhana dalam penulisan nama package kemudian berubah menjadi jalur masuk bagi kode berbahaya.

Dependency confusion

Konflik penamaan antara repository internal dan publik dapat membuat sistem mengambil package dari sumber yang tidak semestinya. Penyerang dapat memanfaatkan kondisi ini dengan menerbitkan package publik yang memiliki nama sama tetapi versi lebih tinggi.

Tanpa pengaturan repository dan sumber package yang ketat, proses build dapat mengunduh komponen yang dikendalikan penyerang.

Pengambilalihan akun maintainer

Package yang sebelumnya aman dapat berubah menjadi berbahaya apabila akun maintainer atau akses publikasinya dikompromikan.

Karena pembaruan berasal dari sumber yang selama ini dipercaya, perubahan berbahaya dapat masuk melalui mekanisme update yang terlihat normal.

Proyek yang tidak lagi dipelihara

Tidak semua risiko berasal dari serangan. Sebuah package dapat ditinggalkan karena maintainer tidak lagi memiliki waktu, sumber daya, atau kepentingan untuk melanjutkannya.

Ketika kerentanan baru ditemukan, perusahaan mungkin tidak memperoleh patch. Tim internal kemudian harus menerima risiko, memperbaiki komponen sendiri, atau melakukan migrasi yang mahal.

Risiko lisensi

Penggunaan package juga membawa konsekuensi hukum. Beberapa lisensi memiliki persyaratan atribusi, distribusi, atau pembukaan kode turunan.

Apabila lisensi tidak diperiksa sejak awal, perusahaan dapat menghadapi hambatan ketika produk akan dikomersialkan, dialihkan kepada pihak lain, atau digunakan dalam lingkungan tertentu.

Semua risiko tersebut menunjukkan bahwa dependency management bukan sekadar proses mencari CVE. Organisasi perlu menilai keamanan, keberlanjutan, integritas, dan kesesuaian bisnis setiap komponen.

Masalah Pertama Bukan Selalu Kerentanan, Melainkan Ketidaktahuan

Ketika kerentanan besar diumumkan, pertanyaan pertama yang muncul biasanya sederhana: apakah perusahaan menggunakan komponen tersebut?

Akan tetapi, banyak organisasi tidak dapat menjawabnya dengan cepat.

Dependency dapat tersebar di berbagai aplikasi, repository, container, server, dan layanan internal. Beberapa komponen digunakan secara langsung, sedangkan lainnya masuk melalui dependency tambahan. Aplikasi lama juga mungkin tidak memiliki dokumentasi yang memadai.

Akibatnya, tim keamanan menghabiskan waktu untuk mencari keberadaan package sebelum dapat menentukan dampak dan melakukan perbaikan.

Keterlambatan ini berbahaya karena informasi mengenai kerentanan juga dapat dipelajari oleh penyerang. Semakin lama perusahaan mengidentifikasi sistem terdampak, semakin panjang periode ketika celah dapat dieksploitasi.

Organisasi tidak dapat mengelola risiko yang tidak dapat dilihat. Karena itu, inventaris komponen software harus diperlakukan sebagai fondasi pengelolaan keamanan aplikasi.

SBOM Tidak Seharusnya Menjadi Dokumen yang Berhenti di Arsip

Software Bill of Materials atau SBOM membantu organisasi memetakan komponen yang membentuk sebuah aplikasi. Di dalamnya dapat tercantum nama package, versi, pemasok, lisensi, serta hubungan dependency.

Keberadaan SBOM dapat mempercepat analisis ketika sebuah kerentanan diumumkan. Tim tidak perlu memeriksa aplikasi satu per satu dari awal karena daftar komponennya telah tersedia.

Namun, manfaat tersebut hanya muncul apabila SBOM diperbarui secara konsisten dan digunakan dalam proses operasional.

SBOM yang dibuat satu kali lalu disimpan sebagai dokumen kepatuhan akan segera kehilangan relevansi. Setiap perubahan versi, penambahan package, pembaruan container, atau modifikasi proses build dapat mengubah komposisi aplikasi.

Karena itu, pembuatan SBOM sebaiknya terintegrasi dengan pipeline pengembangan dan dilakukan pada setiap rilis. Data tersebut juga perlu dihubungkan dengan informasi kerentanan, tingkat kekritisan aset, status eksploitasi, dan proses remediasi.

Nilai SBOM bukan terletak pada banyaknya komponen yang berhasil dicatat. Nilainya terletak pada kemampuan perusahaan menggunakan informasi tersebut untuk mengambil keputusan dengan cepat.

Scanning Dependency Tidak Sama dengan Mengelola Risiko

Software Composition Analysis membantu menemukan dependency, lisensi, dan kerentanan yang terdapat dalam aplikasi. Penggunaan alat ini merupakan langkah penting dalam software supply chain security.

Namun, hasil scanning tidak dapat berdiri sendiri.

Sebuah alat dapat menghasilkan ratusan temuan. Tidak semua temuan memiliki tingkat risiko yang sama bagi perusahaan. Kerentanan dengan skor tinggi mungkin terdapat pada fungsi yang tidak pernah digunakan, sedangkan temuan dengan skor lebih rendah dapat berada pada sistem yang terbuka ke internet dan menangani data sensitif.

Tanpa konteks, tim dapat mengalami alert fatigue. Terlalu banyak peringatan membuat fokus terbagi dan remediasi terhadap risiko yang benar-benar penting menjadi terlambat.

Karena itu, hasil scanning perlu dikaitkan dengan beberapa pertanyaan:

• Apakah fungsi yang rentan digunakan oleh aplikasi?
• Apakah komponen dapat dijangkau oleh penyerang?
• Data atau proses bisnis apa yang terpengaruh?
• Apakah telah tersedia eksploitasi yang dapat digunakan?
• Apakah sistem dapat diperbarui tanpa mengganggu operasional?
• Kontrol keamanan apa yang dapat mengurangi risiko sementara?
• Siapa yang bertanggung jawab melakukan perbaikan?

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Daftar kerentanan dapat memberitahu perusahaan bahwa masalah tersedia. Penetration testing membantu menunjukkan apakah kelemahan tersebut dapat dimanfaatkan dalam konteks sistem yang sebenarnya dan seberapa besar dampaknya terhadap bisnis.

Dependency Harus Dinilai Sebelum Digunakan

Banyak perusahaan baru mengevaluasi package setelah alat keamanan menemukan masalah. Pendekatan tersebut membuat organisasi selalu berada dalam posisi reaktif.

Penilaian seharusnya dimulai sebelum dependency masuk ke dalam aplikasi.

Tidak setiap package membutuhkan proses persetujuan yang rumit. Namun, tingkat evaluasi perlu disesuaikan dengan fungsi dan dampaknya. Library untuk memformat tanggal tidak dapat dinilai dengan standar yang sama seperti komponen autentikasi, enkripsi, pembayaran, atau pengelolaan sesi.

Sebelum menyetujui penggunaan package, tim dapat mempertimbangkan hal-hal berikut:

• Apakah fungsi tersebut benar-benar dibutuhkan?
• Apakah kebutuhan sederhana dapat dipenuhi tanpa menambah dependency besar?
• Apakah proyek masih aktif dipelihara?
• Siapa maintainer dan bagaimana reputasi pengelolaannya?
• Apakah terdapat riwayat kerentanan serius?
• Bagaimana mekanisme pelaporan dan perbaikan masalah?
• Apakah lisensinya sesuai dengan kebutuhan perusahaan?
• Apakah package membutuhkan akses yang berlebihan?
• Apakah terdapat alternatif yang lebih terpelihara?
• Bagaimana rencana migrasi apabila package dihentikan?
• Siapa yang akan memantau pembaruan setelah aplikasi masuk ke production?

Proses ini tidak bertujuan menghambat developer. Tujuannya adalah mencegah keputusan jangka pendek berubah menjadi technical debt dan risiko keamanan jangka panjang.

Kecepatan Development Tidak Perlu Dibayar dengan Risiko yang Tidak Tercatat

Melarang seluruh penggunaan open-source bukan solusi yang realistis. Hampir seluruh pengembangan software modern memanfaatkan komponen pihak ketiga dalam berbagai bentuk.

Tanpa open-source, biaya dan waktu pengembangan dapat meningkat secara signifikan. Tim juga harus mengulang pekerjaan yang sebenarnya telah diselesaikan dan diuji oleh komunitas.

Namun, kebebasan menggunakan package tanpa batas juga bukan praktik yang sehat.

Perusahaan perlu membangun jalur penggunaan dependency yang aman sekaligus efisien. Beberapa langkah yang dapat diterapkan meliputi:

• menyediakan repository internal atau sumber package tepercaya;
• menetapkan daftar komponen yang telah disetujui;
• menggunakan lockfile dan version pinning;
• memeriksa integritas artifact;
• menjalankan scanning otomatis dalam CI/CD;
• membuat SBOM pada setiap rilis;
• memantau kerentanan setelah deployment;
• menentukan batas waktu remediasi;
• menghapus dependency yang tidak lagi digunakan;
• menguji pembaruan sebelum masuk ke production.

Governance yang baik tidak membuat developer mengulang seluruh proses penilaian setiap kali membutuhkan komponen. Sebaliknya, governance menyediakan standar dan jalur yang jelas agar keputusan dapat dibuat lebih cepat dengan tingkat risiko yang dapat diterima.

Tanggung Jawab Dependency Tidak Boleh Dibebankan Hanya kepada Developer

Developer memiliki peran penting dalam memilih dan memperbarui package. Namun, dependency risk tidak dapat dikelola oleh developer seorang diri.

Tim keamanan perlu menetapkan baseline, menjalankan monitoring, dan membantu memprioritaskan temuan. Arsitek software perlu menilai dampak dependency terhadap desain jangka panjang. Product owner perlu memahami konsekuensi bisnis apabila pembaruan ditunda.

Tim legal dan procurement juga memiliki peran dalam mengevaluasi lisensi serta kewajiban kontraktual. Sementara itu, manajemen perlu memastikan tersedianya waktu, anggaran, dan prioritas untuk melakukan maintenance.

Tanpa pembagian tanggung jawab yang jelas, temuan dependency akan berpindah dari satu tim ke tim lain tanpa penyelesaian. Developer menganggapnya sebagai urusan security, security menunggu keputusan product owner, sedangkan manajemen tidak memperoleh gambaran mengenai dampaknya.

Setiap dependency penting seharusnya memiliki pemilik risiko, mekanisme pemantauan, dan jalur eskalasi yang jelas.

Vendor Development Harus Transparan terhadap Komponen yang Digunakan

Ketika aplikasi dibangun oleh vendor, perusahaan perlu meminta transparansi terhadap package dan framework yang digunakan.

Serah terima aplikasi tidak cukup hanya mencakup source code dan dokumentasi penggunaan. Perusahaan juga perlu mengetahui dependency yang membentuk sistem serta cara memeliharanya setelah proyek selesai.

Beberapa pertanyaan yang perlu diajukan kepada vendor antara lain:

• Apakah vendor dapat menyerahkan SBOM?
• Package apa saja yang digunakan dalam aplikasi?
• Bagaimana vendor melakukan scanning dependency?
• Apakah terdapat komponen yang tidak lagi dipelihara?
• Siapa yang bertanggung jawab melakukan pembaruan?
• Berapa lama dukungan keamanan diberikan?
• Bagaimana kerentanan setelah serah terima akan ditangani?
• Apakah source code, lockfile, dan konfigurasi build ikut diserahkan?
• Apakah terdapat lisensi yang membatasi penggunaan aplikasi?
• Apakah sistem dapat dipelihara tanpa ketergantungan penuh pada vendor?

Perusahaan belum memiliki kontrol yang memadai atas sebuah aplikasi apabila tidak mengetahui komponen yang membentuknya.

Transparansi dependency juga perlu dimasukkan dalam kontrak pengembangan. Dengan demikian, keamanan software supply chain bukan sekadar janji teknis, tetapi menjadi tanggung jawab yang dapat diukur.

Pengelolaan Dependency Harus Mengikuti Seluruh Siklus Hidup Aplikasi

Dependency management tidak dapat dilakukan hanya menjelang peluncuran. Pengendalian harus mengikuti perjalanan aplikasi sejak perencanaan hingga penghentian.

Pada tahap awal, perusahaan perlu mengevaluasi kebutuhan, tingkat risiko, lisensi, dan keberlanjutan package.

Selama development, tim perlu menggunakan sumber tepercaya, mengunci versi, memeriksa integritas, dan menjalankan scanning otomatis.

Sebelum deployment, daftar komponen perlu divalidasi. Temuan yang belum diperbaiki harus melalui proses risk acceptance yang jelas, lengkap dengan alasan, kontrol sementara, pemilik risiko, dan batas waktu penyelesaian.

Setelah aplikasi berada di production, dependency harus terus dipantau. Package yang aman pada saat peluncuran dapat memiliki kerentanan baru beberapa bulan kemudian.

Ketika aplikasi dihentikan, repository, token, artifact, dan akses publikasi juga perlu dikelola agar tidak menjadi jalur serangan yang terlupakan.

Pendekatan menyeluruh ini menjadikan dependency management sebagai bagian dari Secure SDLC, bukan tugas tambahan yang dilakukan ketika tim memiliki waktu luang.

Lima Pertanyaan Bisnis Sebelum Menyetujui Package

Sebelum sebuah dependency digunakan pada sistem perusahaan, pengambil keputusan setidaknya perlu memperoleh jawaban atas lima pertanyaan berikut:

1. Fungsi bisnis apa yang akan bergantung pada package ini?
2. Apa dampaknya apabila package tidak lagi dipelihara atau tidak dapat diperbarui?
3. Siapa yang bertanggung jawab memantau dan memperbaikinya?
4. Seberapa cepat perusahaan dapat mengganti atau menghapusnya?
5. Apakah efisiensi yang diperoleh sebanding dengan risiko jangka panjangnya?

Pertanyaan tersebut membantu perusahaan keluar dari pola pikir bahwa package open-source hanya merupakan pilihan implementasi.

Setiap jawaban menunjukkan siapa yang menanggung risiko, berapa besar dampaknya, dan apakah organisasi memiliki kemampuan untuk mempertahankan keamanan aplikasi dalam jangka panjang.

Open-Source Memberikan Kecepatan, tetapi Perusahaan Harus Tetap Memegang Kendali

Open-source telah menjadi fondasi penting dalam software development modern. Perusahaan tidak perlu menghindarinya hanya karena terdapat risiko pada dependency.

Hal yang perlu dihindari adalah penggunaan komponen tanpa inventaris, evaluasi, pemilik, dan proses pembaruan yang jelas.

Setiap package yang masuk ke dalam aplikasi memperluas software supply chain perusahaan. Di dalamnya terdapat kode, maintainer, proses publikasi, repository, lisensi, dan dependency tambahan yang ikut menentukan keamanan sistem.

Karena itu, keberhasilan pengelolaan dependency bukan diukur dari seberapa sedikit package yang digunakan. Keberhasilannya diukur dari seberapa baik perusahaan mengetahui, menilai, memantau, dan memperbaiki komponen tersebut.

Perusahaan tidak perlu berhenti menggunakan open-source. Perusahaan hanya perlu berhenti menganggap setiap dependency sebagai keputusan gratis tanpa konsekuensi bisnis.

Perkuat Keamanan Aplikasi Bersama Fourtrezz

Risiko pada dependency tidak selalu dapat dipahami hanya melalui daftar package dan hasil scanning otomatis. Perusahaan perlu mengetahui apakah kerentanan tersebut benar-benar dapat dimanfaatkan, bagaimana jalur serangannya, dan seberapa besar dampaknya terhadap data maupun proses bisnis.

Fourtrezz membantu perusahaan mengevaluasi keamanan aplikasi dan infrastruktur melalui layanan penetration testing, vulnerability assessment, red teaming, konsultasi keamanan siber, serta pengembangan solusi digital berbasis cybersecurity.

Melalui pendekatan yang menggabungkan pengujian teknis dan pemahaman risiko bisnis, Fourtrezz membantu organisasi menemukan kelemahan yang tidak terlihat oleh pemeriksaan otomatis serta menyusun prioritas perbaikan yang lebih relevan.

Hubungi Fourtrezz:

Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]