Software Bill of Materials (SBOM) memberi perusahaan daftar terstruktur tentang komponen yang membentuk sebuah aplikasi—termasuk library pihak ketiga, versi, hubungan dependensi, dan asal komponennya. Bagi manajemen, tim keamanan, procurement, dan pemilik aplikasi, SBOM bukan sekadar dokumen teknis. Ia menjadi fondasi untuk menjawab pertanyaan penting: ketika kerentanan baru diumumkan, aplikasi mana yang terdampak, siapa pemiliknya, dan seberapa cepat perusahaan dapat mengambil tindakan?
Tanpa inventaris komponen yang dapat ditelusuri, pemeriksaan sering bergantung pada ingatan developer, pencarian manual di banyak repositori, atau konfirmasi vendor yang datang terlambat. SBOM membantu mengubah proses tersebut menjadi kontrol software supply chain yang lebih sistematis. Namun, menghasilkan satu file SBOM saja belum cukup. Nilainya baru muncul ketika data tersebut akurat, diperbarui pada setiap rilis, dihubungkan dengan proses vulnerability management, dan memiliki pemilik yang jelas.
Apa Itu SBOM dan Mengapa Dibutuhkan Perusahaan?
National Telecommunications and Information Administration (NTIA) mendefinisikan SBOM sebagai catatan formal yang berisi detail serta hubungan rantai pasok dari berbagai komponen yang digunakan untuk membangun software. Dengan kata lain, SBOM bekerja seperti daftar bahan pada sebuah produk, tetapi diterapkan pada aplikasi dan perangkat lunak.
Aplikasi enterprise modern hampir selalu tersusun dari banyak lapisan: source code internal, framework, package open source, SDK, container image, komponen komersial, dan layanan pihak ketiga. Setiap lapisan dapat berubah sepanjang siklus hidup aplikasi. Ketika salah satu komponen memiliki kerentanan, organisasi perlu mengetahui bukan hanya apakah komponen itu pernah digunakan, tetapi versi mana yang aktif, berada di sistem apa, dan siapa yang bertanggung jawab menanganinya.
SBOM membantu perusahaan membangun transparansi tersebut. Ia tidak otomatis membuat aplikasi aman dan bukan pengganti pengujian keamanan. Fungsinya adalah menyediakan data dasar agar identifikasi dampak, prioritas remediasi, audit vendor, dan keputusan risiko dapat dilakukan lebih cepat serta lebih konsisten.
Masalah yang Sering Terjadi Tanpa Inventaris Komponen
1. Dampak Kerentanan Sulit Dipastikan
Ketika kerentanan baru diumumkan, tim harus mencari komponen terdampak di banyak aplikasi dan lingkungan. Jika daftar dependency tidak konsisten, pemeriksaan dapat melebar menjadi pencarian manual yang lambat. Hasilnya pun berisiko tidak lengkap karena komponen transitive—dependency dari dependency lain—tidak selalu terlihat di permukaan.
2. Handover dari Vendor Tidak Memberi Transparansi
Perusahaan dapat menerima source code dan dokumentasi, tetapi tidak memiliki daftar komponen beserta versinya. Kondisi ini menyulitkan tim internal atau vendor pengganti saat melakukan maintenance, security review, maupun pengambilalihan aplikasi yang terbengkalai.
3. Versi di Dokumen Berbeda dengan Versi Produksi
SBOM yang dibuat sekali saat awal proyek cepat menjadi usang. Perubahan package, patch, build image, dan konfigurasi rilis dapat membuat daftar komponen tidak lagi mewakili software yang benar-benar berjalan. Karena itu, SBOM harus mengikuti artifact build atau release yang spesifik.
4. Procurement Sulit Menilai Kesiapan Vendor
Persyaratan “aplikasi harus aman” terlalu umum untuk dievaluasi. Procurement membutuhkan bukti yang dapat diperiksa: apakah vendor memiliki proses secure development, dapat menghasilkan SBOM, memberi notifikasi kerentanan, dan menjelaskan tanggung jawab perbaikan. Persyaratan ini dapat dimasukkan sejak penyusunan RFP pengembangan software.
Data Minimum yang Perlu Ada dalam SBOM
Panduan minimum NTIA mengelompokkan elemen SBOM ke dalam tiga area: data fields, dukungan otomasi, serta praktik dan proses. Pada tingkat komponen, informasi dasar yang perlu tersedia meliputi:
- nama supplier atau pembuat komponen;
- nama komponen;
- versi komponen;
- identitas unik lain yang relevan;
- hubungan dependensi antar-komponen;
- pihak yang membuat data SBOM; dan
- waktu pembuatan atau pembaruan data.
Untuk skala enterprise, data minimum tersebut sebaiknya diperkaya dengan konteks operasional. Misalnya: aplikasi pemakai, environment, criticality layanan, owner bisnis, owner teknis, status dukungan, lisensi, hasil vulnerability scan, dan keputusan risiko. Tambahan ini tidak harus berada seluruhnya di dalam file SBOM; sebagian dapat dikelola pada asset inventory, configuration management database, atau platform vulnerability management yang terhubung.
SBOM Bukan Hanya Daftar Dependency
Daftar package dari package manager memang dapat menjadi sumber awal, tetapi belum tentu mencerminkan seluruh software yang dikirim ke produksi. Build dapat memasukkan komponen dari container base image, binary, plugin, library sistem operasi, atau tahap build lain. Karena itu, organisasi perlu menentukan jenis SBOM dan titik pembuatannya berdasarkan tujuan penggunaan.
Untuk kontrol rilis, pendekatan yang kuat adalah menghasilkan SBOM secara otomatis pada pipeline build, mengikatnya pada artifact atau image tertentu, lalu menyimpan bukti integritasnya. Format yang dapat dibaca mesin—seperti SPDX atau CycloneDX yang disebut dalam panduan NTIA—membantu data diproses secara konsisten oleh alat lain. Pemilihan format harus mengikuti integrasi dan kebutuhan organisasi, bukan sekadar tren alat.
Bagaimana SBOM Terhubung dengan Vulnerability Management?
Nilai utama SBOM terlihat saat muncul kerentanan pada komponen yang banyak digunakan. Alur respons yang matang biasanya mencakup:
- Deteksi: informasi kerentanan dipetakan ke nama, versi, dan identitas komponen.
- Analisis dampak: organisasi mengidentifikasi aplikasi, layanan, environment, dan unit bisnis yang menggunakan komponen tersebut.
- Prioritas: keputusan tidak hanya berdasarkan skor kerentanan, tetapi juga eksposur, criticality layanan, ketersediaan exploit, dan kontrol kompensasi.
- Remediasi: tim memperbarui dependency, mengganti komponen, mengubah konfigurasi, atau menerapkan mitigasi sementara.
- Verifikasi: build baru diuji, SBOM diperbarui, dan status produksi direkonsiliasi.
- Pelaporan: owner bisnis dan teknis menerima status yang dapat ditelusuri, bukan sekadar pernyataan “sudah dicek”.
Alur ini juga perlu terhubung dengan incident response aplikasi enterprise ketika kerentanan sudah dieksploitasi atau menimbulkan gangguan. SBOM mempercepat identifikasi cakupan, tetapi keputusan insiden tetap membutuhkan bukti runtime, log, monitoring, dan analisis forensik yang sesuai.
Persyaratan SBOM untuk Vendor dan Proyek Custom Software
NIST Secure Software Development Framework (SSDF) mendorong organisasi untuk mengintegrasikan praktik keamanan ke dalam siklus pengembangan dan menggunakan bahasa bersama antara produsen serta pembeli software. Untuk proyek custom, perusahaan dapat menerjemahkannya menjadi persyaratan kontraktual dan penerimaan yang terukur.
Beberapa pertanyaan yang layak dimasukkan ke proses vendor assessment adalah:
- Apakah SBOM dihasilkan untuk setiap release atau hanya saat diminta?
- Apakah SBOM terkait dengan versi artifact yang benar-benar dikirim?
- Apakah direct dan transitive dependency tercakup?
- Bagaimana vendor menangani komponen yang tidak dapat diidentifikasi?
- Siapa yang menerima dan menindaklanjuti notifikasi kerentanan?
- Berapa batas waktu analisis dampak dan rencana remediasi berdasarkan severity?
- Bagaimana integritas, akses, penyimpanan, serta pembaruan SBOM dijaga?
- Apa yang diserahkan saat kontrak berakhir atau vendor berganti?
Persyaratan tersebut harus disesuaikan dengan criticality aplikasi dan model delivery. SaaS, software on-premise, mobile app, dan sistem dengan perangkat IoT memiliki visibility serta pembagian tanggung jawab yang berbeda. Jangan menyalin klausul SBOM tanpa memastikan organisasi dapat menerima, membaca, dan menindaklanjuti datanya.
Roadmap Implementasi SBOM dalam 90 Hari
Hari 1–30: Tentukan Scope dan Baseline
- Pilih satu sampai tiga aplikasi prioritas berdasarkan criticality dan eksposur.
- Petakan repository, pipeline, artifact, environment, serta owner bisnis dan teknis.
- Tetapkan tujuan awal, misalnya mempercepat analisis dampak kerentanan komponen.
- Pilih format data dan lokasi penyimpanan yang dapat diakses pihak berwenang.
- Uji kemampuan menghasilkan SBOM pada satu build yang dapat direproduksi.
Hari 31–60: Otomasikan dan Hubungkan
- Masukkan pembuatan SBOM ke pipeline build atau release.
- Hubungkan SBOM dengan artifact identifier, versi rilis, dan environment.
- Integrasikan dengan vulnerability scanning atau proses penilaian yang tersedia.
- Tetapkan alur triage, escalation, exception, dan bukti remediasi.
- Uji kasus komponen rentan secara terkendali tanpa mengganggu produksi.
Hari 61–90: Operasionalkan dan Perluas
- Ukur kelengkapan, freshness, serta waktu analisis dampak.
- Perbaiki komponen yang tidak teridentifikasi dan gap pada transitive dependency.
- Masukkan persyaratan SBOM ke template RFP, SOW, handover, dan acceptance.
- Tentukan retensi data serta kontrol akses berdasarkan kebutuhan keamanan.
- Perluas ke aplikasi berikutnya setelah alur pilot dapat dijalankan secara konsisten.
Metrik yang Lebih Berguna daripada Sekadar “Sudah Punya SBOM”
Keberhasilan implementasi sebaiknya diukur dari kemampuan operasional, bukan jumlah file yang dihasilkan. Metrik yang dapat dipertimbangkan meliputi persentase aplikasi kritis dengan SBOM terbaru, persentase release yang otomatis menghasilkan SBOM, cakupan komponen yang teridentifikasi, waktu yang dibutuhkan untuk menemukan aplikasi terdampak, umur exception yang belum selesai, dan persentase remediasi yang diverifikasi melalui build baru.
Angka target harus ditentukan setelah baseline tersedia. Hindari target seragam untuk semua aplikasi jika criticality, arsitektur, dan model pengelolaannya berbeda.
Kesalahan yang Perlu Dihindari
- Menganggap file SBOM sebagai sertifikat keamanan. SBOM adalah sumber data, bukan bukti bahwa tidak ada kerentanan.
- Membuat SBOM sekali lalu tidak memperbaruinya. Data yang tidak mengikuti release dapat memberi rasa aman yang keliru.
- Memindai tanpa menetapkan owner. Temuan tidak akan selesai jika tidak ada penanggung jawab dan SLA keputusan.
- Mengabaikan false positive dan konteks runtime. Komponen terdeteksi belum tentu dapat dieksploitasi, tetapi asumsi sebaliknya juga harus dibuktikan.
- Meminta SBOM dari vendor tanpa proses konsumsi. Data yang diterima harus dapat diperiksa, dipetakan, dan digunakan dalam respons risiko.
Mulai dari Aplikasi yang Paling Penting
Perusahaan tidak harus langsung menerapkan SBOM pada seluruh portofolio aplikasi. Mulailah dari sistem yang paling kritis, memiliki banyak dependency, berhadapan dengan internet, atau bergantung pada vendor eksternal. Satu pilot yang terhubung dengan build, vulnerability response, dan ownership akan memberi pembelajaran lebih berharga daripada inventaris besar yang tidak pernah diperbarui.
Jika perusahaan Anda sedang merancang aplikasi enterprise, mengevaluasi software lama, atau menyiapkan requirement keamanan untuk vendor, Layana.ID dapat membantu melalui konsultasi IT dan pemetaan kebutuhan serta pengembangan software custom. Langkah awalnya adalah memetakan aplikasi prioritas, proses build, komponen, owner, dan risiko yang perlu dikendalikan—sebelum memilih alat.
Pertanyaan Umum tentang SBOM
Apakah SBOM wajib untuk semua aplikasi?
Kewajiban bergantung pada regulasi, kontrak, industri, dan konteks organisasi. Dari sisi manajemen risiko, prioritas sebaiknya diberikan pada aplikasi kritis, sistem dengan dependency kompleks, dan software yang melibatkan banyak pemasok.
Apakah SBOM sama dengan vulnerability scan?
Tidak. SBOM mencatat komponen dan hubungan dependensinya. Vulnerability scan menggunakan berbagai sumber serta teknik untuk menemukan potensi kerentanan. Keduanya saling melengkapi, tetapi tidak dapat menggantikan pengujian, analisis exploitability, dan verifikasi remediasi.
Kapan SBOM harus diperbarui?
Praktik yang kuat adalah memperbaruinya pada setiap build atau release yang relevan, lalu mengikatnya pada artifact spesifik. Frekuensi aktual perlu disesuaikan dengan ritme rilis, criticality sistem, dan kemampuan operasional organisasi.
Siapa pemilik SBOM di perusahaan?
Tanggung jawab biasanya lintas fungsi. Engineering atau vendor menghasilkan data, security menggunakannya untuk analisis risiko, platform atau DevOps mengintegrasikan pipeline, procurement menetapkan persyaratan pemasok, dan pemilik aplikasi memastikan tindak lanjut bisnis. Satu accountable owner tetap perlu ditetapkan.
Sumber Primer yang Digunakan
Artikel ini merujuk pada NIST SP 800-218 Secure Software Development Framework (SSDF) Version 1.1, NTIA The Minimum Elements for a Software Bill of Materials, serta CISA SBOM Resources Library dan Framing Software Component Transparency. Nama sumber dicantumkan tanpa tautan keluar.