Software Bill of Materials atau SBOM semakin sering digunakan untuk meningkatkan transparansi komponen software. Dokumen ini membantu perusahaan mengetahui library, package, framework, serta dependency pihak ketiga yang terdapat di dalam sebuah aplikasi.

Namun, memiliki daftar komponen bukan berarti perusahaan telah memahami kondisi aplikasi yang sebenarnya.

SBOM dapat menunjukkan komponen yang terdeteksi ketika software dibangun atau dianalisis. Akan tetapi, informasi tersebut belum selalu membuktikan komponen mana yang benar-benar diterapkan, dimuat, dipanggil, atau dieksekusi di lingkungan production.

Perbedaan ini terlihat sederhana, tetapi dapat memengaruhi cara perusahaan menilai kerentanan. Tanpa konteks tambahan, tim keamanan dapat menghabiskan waktu untuk menangani komponen yang tidak aktif, sementara dependency lain yang benar-benar berjalan justru luput dari pengawasan.

Daftar Komponen Tidak Selalu Menggambarkan Kondisi Terkini

SBOM sering diperlakukan sebagai sumber informasi utama mengenai isi sebuah aplikasi. Pendekatan tersebut memang lebih baik dibandingkan tidak memiliki inventaris komponen sama sekali.

Masalahnya, SBOM pada umumnya menggambarkan kondisi pada titik waktu tertentu.

Dokumen tersebut mungkin dibuat saat proses build, setelah pemindaian source code, ketika container image diperiksa, atau sebelum aplikasi dipindahkan ke production. Setelah itu, aplikasi masih melewati sejumlah proses yang dapat mengubah komposisinya.

Tim operasional mungkin menambahkan package untuk kebutuhan tertentu. Agen monitoring dapat dipasang langsung pada server. Plugin dapat dimuat secara dinamis. Hotfix juga terkadang diterapkan tanpa melalui alur build yang sama.

Pada lingkungan cloud dan container, perubahan dapat terjadi lebih cepat. Sebuah image mungkin memiliki beberapa versi yang masih tersimpan, sedangkan workload yang berjalan ternyata menggunakan versi berbeda dari versi yang tercatat dalam pipeline.

Akibatnya, SBOM yang awalnya akurat dapat kehilangan kesesuaiannya dengan kondisi production.

“Tercantum”, “Terpasang”, dan “Berjalan” Adalah Tiga Kondisi Berbeda

Salah satu kesalahan dalam menggunakan SBOM adalah menganggap semua komponen yang tercantum memiliki status keamanan yang sama. Padahal, terdapat perbedaan antara komponen yang tercatat, terpasang, dan benar-benar digunakan.

Komponen yang tercantum berarti dependency tersebut ditemukan dalam source code, manifest, image, atau artefak software. Keberadaannya menunjukkan bahwa komponen tersebut memiliki hubungan dengan aplikasi.

Komponen yang terpasang berarti file atau package-nya tersedia pada server, container, virtual machine, atau environment tempat aplikasi diterapkan.

Sementara itu, komponen yang berjalan berarti library, module, binary, atau fungsi tertentu benar-benar dimuat dan digunakan ketika aplikasi menjalankan prosesnya.

Sebuah library dapat tercantum dalam SBOM tetapi tidak pernah dipanggil oleh aplikasi. Sebaliknya, komponen yang ditambahkan setelah deployment dapat berjalan di production tanpa tercatat dalam SBOM awal.

Oleh karena itu, SBOM perlu dibaca sebagai inventaris awal, bukan kesimpulan akhir mengenai risiko keamanan aplikasi.

Kesenjangan antara Build dan Production Dapat Mengubah Risiko

Proses pengembangan modern melibatkan banyak tahapan, mulai dari penulisan kode, pengelolaan dependency, build, pengujian, penyimpanan artefak, hingga deployment. Setiap tahapan dapat menghasilkan perbedaan komposisi.

Dependency yang tersedia pada tahap development belum tentu disertakan dalam artefak akhir. Sebaliknya, package yang tidak muncul dalam source code dapat masuk melalui base image, operating system package, plugin, atau proses instalasi ketika aplikasi dijalankan.

Kesenjangan tersebut dikenal sebagai dependency drift atau perubahan dependency antara kondisi yang terdokumentasi dan kondisi yang benar-benar diterapkan.

Beberapa kondisi yang dapat menimbulkan perbedaan antara SBOM dan production meliputi:

• penggunaan container image yang tidak sesuai dengan versi rilis;
• penambahan library secara manual pada server;
• dynamic loading terhadap module tertentu;
• penggunaan plugin yang tidak tercatat dalam repository utama;
• pemasangan monitoring agent atau security agent;
• perubahan konfigurasi yang mengaktifkan fungsi tertentu;
• proses rollback ke versi lama;
• package yang diunduh ketika aplikasi mulai dijalankan;
• penggunaan komponen lama yang belum sepenuhnya dihentikan.

Jika perbedaan tersebut tidak dipantau, perusahaan dapat memiliki dua versi kebenaran: daftar yang tersimpan dalam dokumentasi dan software yang benar-benar melayani pengguna.

SBOM Dapat Memunculkan Prioritas yang Keliru

Ketika data SBOM dihubungkan dengan basis data kerentanan, tim keamanan dapat melihat daftar Common Vulnerabilities and Exposures atau CVE yang berkaitan dengan setiap komponen.

Proses ini membantu mempercepat identifikasi potensi risiko. Namun, pencocokan nama package dan nomor versi belum cukup untuk menentukan apakah sebuah aplikasi dapat dieksploitasi.

Ada dua kesalahan penilaian yang perlu diperhatikan.

Pertama, risiko dapat terlihat lebih besar daripada keadaan sebenarnya. Sebuah komponen rentan mungkin tercantum dalam SBOM, tetapi tidak dimuat oleh aplikasi. Fungsi yang mengandung kerentanan juga mungkin tidak pernah digunakan atau tidak dapat dijangkau melalui alur aplikasi.

Kondisi tersebut dapat menghasilkan terlalu banyak peringatan. Tim keamanan akhirnya harus memeriksa ratusan temuan yang secara teknis benar, tetapi belum tentu relevan terhadap ancaman aktual.

Kedua, risiko dapat terlihat lebih kecil daripada keadaan sebenarnya. Hal ini terjadi ketika komponen yang aktif di production tidak tercatat dalam SBOM. Tim tidak menerima peringatan karena dependency tersebut tidak pernah masuk ke inventaris yang dianalisis.

Kesalahan kedua lebih berbahaya karena dapat menciptakan rasa aman yang tidak sesuai dengan kondisi lapangan.

Runtime SBOM Memberikan Pandangan yang Lebih Dekat ke Production

Runtime SBOM dikembangkan untuk memberikan visibilitas terhadap komponen yang hadir atau aktif ketika software sedang berjalan. Pendekatan ini tidak hanya membaca manifest dan artefak, tetapi juga mengamati keadaan aplikasi pada saat runtime.

Informasi runtime dapat membantu tim mengetahui library yang dimuat ke memori, module yang dipanggil, proses yang aktif, serta hubungan antara aplikasi dan dependency yang digunakan.

Penelitian tentang memory-based runtime SBOM menunjukkan bahwa analisis keadaan aplikasi yang sedang berjalan dapat menemukan package yang terlewat oleh SBOM berbasis metadata atau filesystem. Temuan semacam ini memperlihatkan bahwa apa yang terlihat di dalam artefak belum tentu sama dengan apa yang benar-benar dieksekusi.

Meski demikian, runtime SBOM juga bukan jawaban tunggal.

Komponen yang tidak terlihat selama periode observasi belum tentu tidak pernah digunakan. Beberapa fungsi hanya berjalan pada jadwal tertentu, ketika terjadi kondisi khusus, atau setelah menerima jenis permintaan tertentu.

Batch job bulanan, fitur administrasi, proses pemulihan, fungsi darurat, dan module musiman dapat terlewat apabila pengamatan dilakukan terlalu singkat.

Karena itu, SBOM statis dan runtime visibility sebaiknya diposisikan sebagai bukti yang saling melengkapi.

Reachability Analysis Membantu Menilai Kerentanan secara Lebih Tepat

Keberadaan suatu dependency belum otomatis membuktikan bahwa bagian yang rentan dapat dieksploitasi. Tim keamanan masih perlu mengetahui apakah aplikasi memiliki jalur menuju fungsi yang bermasalah.

Di sinilah reachability analysis berperan.

Analisis ini memeriksa hubungan antara kode aplikasi dan kode rentan di dalam dependency. Jika sebuah library memiliki CVE, reachability analysis dapat membantu menilai apakah fungsi yang terdampak benar-benar dapat dipanggil oleh aplikasi.

Perbedaannya dapat dirangkum sebagai berikut:

• SBOM menunjukkan komponen yang teridentifikasi.
• Deployment inventory menunjukkan komponen yang diterapkan.
• Runtime visibility menunjukkan komponen yang teramati saat aplikasi berjalan.
• Reachability analysis menunjukkan kemungkinan jalur menuju kode rentan.
• Penetration testing menguji apakah kelemahan tersebut dapat dimanfaatkan dalam konteks sistem yang sebenarnya.

Kelima informasi tersebut memiliki fungsi berbeda. Mengandalkan salah satunya saja dapat menghasilkan penilaian yang tidak lengkap.

VEX Menambahkan Konteks, tetapi Bukan Bukti Otomatis

Vulnerability Exploitability eXchange atau VEX digunakan untuk menyampaikan apakah suatu produk terdampak oleh kerentanan tertentu. VEX dapat menjadi pendamping SBOM agar perusahaan tidak memperlakukan setiap CVE dengan tingkat urgensi yang sama.

Sebagai contoh, suatu komponen dapat dinyatakan tidak terdampak apabila fungsi rentannya tidak digunakan, tidak dapat dijangkau, atau telah dibatasi oleh konfigurasi tertentu.

Namun, status tersebut tetap membutuhkan dasar yang dapat diverifikasi.

Pernyataan bahwa sebuah komponen tidak terdampak seharusnya tidak hanya didasarkan pada asumsi developer. Keputusan tersebut perlu didukung oleh pemeriksaan kode, konfigurasi, deployment, kontrol keamanan, dan kondisi runtime.

VEX pada dasarnya merupakan cara untuk menyampaikan konteks kerentanan. VEX bukan alat yang dengan sendirinya membuktikan bahwa eksploitasi tidak mungkin terjadi.

Jika kondisi aplikasi berubah, status kerentanan juga perlu ditinjau kembali.

Penetration Testing Menguji Risiko dalam Konteks Sistem Sebenarnya

SBOM, runtime visibility, dan reachability analysis memberikan informasi penting mengenai komponen software. Namun, perusahaan tetap perlu mengetahui bagaimana seluruh komponen tersebut berinteraksi ketika berhadapan dengan skenario serangan.

Penetration testing tidak hanya memeriksa apakah sebuah library memiliki kerentanan. Pengujian juga menilai apakah kelemahan dapat digunakan untuk melewati authentication, meningkatkan hak akses, mengakses data sensitif, menjalankan perintah, atau berpindah ke sistem lain.

Sebuah dependency dengan tingkat keparahan tinggi belum tentu menjadi jalur serangan paling berbahaya. Sebaliknya, kombinasi beberapa kesalahan konfigurasi dan kerentanan dengan tingkat keparahan sedang dapat membuka akses yang lebih luas.

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

Temuan tersebut memperlihatkan bahwa risiko aplikasi tidak selalu berasal dari satu komponen. Risiko dapat muncul dari hubungan antara dependency, konfigurasi, hak akses, API, infrastruktur, serta proses operasional yang tidak terlihat hanya melalui SBOM.

Perusahaan Membutuhkan Rantai Bukti dari Build hingga Runtime

SBOM akan memberikan manfaat lebih besar apabila menjadi bagian dari proses verifikasi yang berkelanjutan. Perusahaan perlu menghubungkan informasi dari tahap pengembangan hingga kondisi aplikasi yang sedang berjalan.

Proses tersebut dapat dimulai dengan beberapa langkah berikut.

1. Menghasilkan SBOM pada Setiap Versi

Setiap rilis aplikasi perlu memiliki SBOM tersendiri. Dokumen tersebut harus dikaitkan dengan versi, artefak, dan waktu pembuatan yang jelas.

2. Mengikat SBOM dengan Artefak yang Tepat

Perusahaan perlu memastikan bahwa SBOM benar-benar menggambarkan artefak yang akan diterapkan. Identitas image, checksum, tag, dan informasi rilis perlu dijaga agar tidak tertukar.

3. Memverifikasi Deployment

Artefak yang disetujui dalam pipeline harus sama dengan artefak yang berjalan di production. Perubahan manual perlu dicatat dan dievaluasi.

4. Memantau Komponen saat Runtime

Pemantauan runtime membantu menemukan library, proses, plugin, atau binary yang aktif. Informasi ini dapat dibandingkan dengan SBOM rilis.

5. Menambahkan Konteks Kerentanan

Data CVE perlu diperkaya dengan reachability analysis, VEX, tingkat paparan layanan, dan kepentingan sistem terhadap bisnis.

6. Melakukan Pengujian Keamanan

Vulnerability assessment dan penetration testing diperlukan untuk menguji apakah kerentanan dapat dimanfaatkan serta seberapa besar dampaknya terhadap sistem.

7. Memperbarui Informasi secara Berkala

SBOM tidak seharusnya menjadi dokumen yang dibuat satu kali. Informasi perlu diperbarui ketika terdapat rilis baru, perubahan konfigurasi, patch, rollback, atau penambahan komponen.

Prioritas Perbaikan Harus Mengikuti Risiko Aktual

Perusahaan tidak memiliki sumber daya tanpa batas untuk memperbaiki seluruh temuan pada waktu bersamaan. Prioritas perlu ditentukan berdasarkan risiko yang benar-benar dihadapi sistem.

Beberapa pertanyaan berikut dapat membantu proses penilaian:

• Apakah komponen terdapat pada aplikasi yang berjalan di production?
• Apakah versi yang diterapkan sama dengan versi yang tercatat?
• Apakah komponen sedang aktif atau dapat dipanggil?
• Apakah fungsi yang rentan dapat dijangkau?
• Apakah layanan dapat diakses dari jaringan publik?
• Apakah sudah tersedia eksploitasi yang digunakan secara aktif?
• Apakah sistem memproses data sensitif?
• Apakah terdapat kontrol keamanan yang membatasi eksploitasi?
• Apa dampaknya terhadap proses bisnis jika kerentanan dimanfaatkan?

Pendekatan ini membantu tim memisahkan temuan administratif dari risiko yang membutuhkan penanganan segera.

SBOM Seharusnya Menjadi Awal Investigasi

SBOM tetap menjadi fondasi penting dalam keamanan rantai pasok software. Perusahaan akan kesulitan melindungi komponen yang tidak diketahui keberadaannya.

Namun, transparansi komponen tidak boleh disamakan dengan bukti keamanan.

Daftar dependency perlu dihubungkan dengan integritas artefak, konsistensi deployment, runtime security, reachability analysis, informasi VEX, serta hasil pengujian keamanan. Tanpa hubungan tersebut, SBOM berisiko hanya menjadi dokumen kepatuhan yang tidak banyak membantu ketika insiden terjadi.

Pertanyaan yang seharusnya diajukan bukan hanya “Apa yang terdapat di dalam software?”, tetapi juga “Apa yang benar-benar berjalan, dapat dijangkau, dan berpotensi dieksploitasi di production?”

Perubahan pertanyaan tersebut akan membantu perusahaan beralih dari sekadar mengumpulkan inventaris menuju pengelolaan risiko yang lebih akurat.

Perkuat Keamanan Aplikasi Bersama Fourtrezz

Fourtrezz membantu perusahaan mengidentifikasi dan memvalidasi kerentanan melalui layanan Vulnerability Assessment dan Penetration Testing. Pengujian dapat dilakukan terhadap aplikasi web, aplikasi desktop, Android, iOS, API, jaringan, dan server.

Melalui simulasi serangan, analisis kerentanan, laporan terperinci, rekomendasi perbaikan, dan pengujian ulang, Fourtrezz membantu perusahaan memahami risiko yang benar-benar dapat memengaruhi sistem serta operasional bisnis.

Konsultasikan kebutuhan pengujian keamanan perusahaan Anda bersama tim Fourtrezz.

Hubungi Fourtrezz:

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