SBOM: Cara Memetakan Komponen Perangkat Lunak untuk Keamanan

Ketika sebuah aplikasi mengalami kerentanan, tim teknis sering perlu menjawab pertanyaan yang tampak sederhana: komponen apa saja yang dipakai aplikasi tersebut, dan apakah komponen yang terdampak benar-benar ada di lingkungan kita? Tanpa inventaris yang dapat dipercaya, proses penilaian risiko bisa berubah menjadi pencarian manual yang memakan waktu.

Software Bill of Materials (SBOM) membantu mengatasi masalah itu dengan menyediakan daftar komponen perangkat lunak yang membentuk suatu aplikasi. SBOM bukan jaminan bahwa aplikasi aman, tetapi dapat menjadi fondasi penting untuk memahami dependensi, menilai paparan kerentanan, dan meningkatkan transparansi rantai pasok perangkat lunak.

Apa Itu SBOM?

SBOM adalah catatan terstruktur tentang komponen yang disertakan dalam perangkat lunak. Isinya dapat mencakup pustaka langsung, dependensi transitif, versi komponen, pemasok atau pembuat, serta pengenal yang membantu mengidentifikasi paket secara konsisten. Format yang umum dijumpai antara lain SPDX dan CycloneDX.

Bayangkan sebuah aplikasi web menggunakan kerangka kerja utama, pustaka autentikasi, klien basis data, dan puluhan paket tambahan. Berkas manifest proyek mungkin hanya menunjukkan dependensi langsung, sementara paket-paket tersebut membawa dependensi lain. SBOM yang dibuat dengan benar berusaha memetakan komponen itu sehingga tim tidak hanya mengandalkan ingatan pengembang atau dokumentasi lama.

Mengapa SBOM Penting untuk Keamanan?

Mempercepat penilaian kerentanan

Ketika CVE baru diumumkan, tim dapat mencocokkan nama dan versi komponen dalam SBOM dengan informasi kerentanan. Ini membantu menyaring sistem yang mungkin terdampak sebelum pemeriksaan manual dilakukan. Hasil pencocokan tetap perlu divalidasi: sebuah paket mungkin tercatat, tetapi kode yang rentan belum tentu digunakan atau dapat dijangkau dalam konfigurasi aplikasi tertentu.

Meningkatkan transparansi rantai pasok

Perangkat lunak modern sering menggabungkan kode internal, pustaka sumber terbuka, paket pihak ketiga, dan citra kontainer. SBOM memberi tim operasi, keamanan, pengadaan, serta pelanggan gambaran yang lebih konsisten mengenai komposisi produk. Hal ini sangat berguna saat organisasi mengevaluasi vendor atau harus menjelaskan dampak insiden.

Mendukung pemeliharaan dan audit

Inventaris komponen membantu menemukan dependensi usang, paket yang tidak lagi dipelihara, dan perbedaan antara versi yang disetujui dengan artefak yang benar-benar dirilis. Namun, SBOM harus disimpan bersama informasi versi dan proses pembangunan agar tetap relevan.

Cara Membuat SBOM dalam Alur Kerja Pengembangan

1. Tentukan artefak yang akan diperiksa. Pilih apakah SBOM dibuat dari kode sumber, berkas dependensi, citra kontainer, atau paket hasil build. Hasilnya bisa berbeda karena setiap pendekatan melihat lapisan yang berbeda.
2. Gunakan alat yang sesuai. Alat seperti Syft dapat menghasilkan SBOM dari direktori proyek, image kontainer, atau artefak tertentu. Pastikan alat dan versinya dicatat agar hasil dapat direproduksi.
3. Pilih format yang didukung. SPDX dan CycloneDX banyak digunakan. Pilih format yang dapat diproses oleh sistem inventaris dan pemindai kerentanan organisasi, bukan sekadar format yang mudah diekspor.
4. Validasi kelengkapan. Periksa apakah nama paket, versi, sumber, dan hubungan dependensi tersedia. Komponen yang tidak memiliki metadata lengkap dapat menyulitkan pencocokan dan perlu ditinjau.
5. Hubungkan dengan pipeline CI/CD. Buat SBOM pada tahap build atau rilis, simpan bersama artefak, dan ulangi proses saat dependensi berubah. Untuk layanan penting, pertimbangkan juga pemeriksaan terhadap image yang benar-benar akan dijalankan.

Contoh sederhana menggunakan Syft untuk membuat SBOM format CycloneDX dari image kontainer adalah:

syft nama-image:tag -o cyclonedx-json=sbom.cdx.json

Perintah tersebut merupakan ilustrasi; nama image, tag, versi alat, dan kebijakan penyimpanan harus disesuaikan dengan lingkungan sendiri. Jalankan pemindaian di sistem yang berwenang dan pastikan artefak yang diperiksa sama dengan artefak yang dirilis.

SBOM Bukan Pengganti Pemindaian Keamanan

SBOM menjawab pertanyaan “komponen apa yang diketahui ada?”, bukan secara otomatis “apakah aplikasi dapat dieksploitasi?”. Daftar komponen dapat tidak lengkap, metadata dapat salah, dan kecocokan versi tidak selalu membuktikan bahwa kode rentan aktif. Sebaliknya, SBOM yang tidak menemukan suatu paket juga tidak membuktikan bahwa paket itu tidak ada jika proses pembuatannya tidak mencakup seluruh lapisan.

Karena itu, gabungkan SBOM dengan pemindaian kerentanan, tinjauan konfigurasi, pengujian aplikasi, dan proses respons insiden. Tetapkan pemilik yang bertanggung jawab memperbarui dependensi, batas waktu penanganan temuan, serta mekanisme untuk menghubungkan peringatan kerentanan dengan versi produk yang terdampak.

Praktik Baik Mengelola SBOM

• Hasilkan SBOM secara otomatis dan konsisten, bukan hanya ketika audit berlangsung.
• Catat waktu pembuatan, versi alat, identitas build, dan hash artefak bila tersedia.
• Simpan SBOM dengan kontrol akses yang sesuai; inventaris komponen dapat mengungkap detail teknis produk.
• Bandingkan SBOM antar-rilis untuk menemukan perubahan dependensi yang tidak diharapkan.
• Uji proses pemulihan: ketika kerentanan diumumkan, pastikan tim dapat menemukan rilis yang memakai komponen terkait.

Checklist Sebelum SBOM Dipakai dalam Produksi

Sebelum menjadikan SBOM sebagai dasar keputusan, pastikan dokumen tersebut benar-benar berkaitan dengan rilis yang sedang diperiksa. Cocokkan identitas artefak, nomor versi, waktu build, dan hash bila tersedia. Jika tim hanya menyimpan satu berkas bernama sbom.json yang terus ditimpa, akan sulit membuktikan komponen mana yang ada pada versi terdahulu ketika insiden ditemukan.

Berikut pemeriksaan praktis yang dapat diterapkan dalam proses rilis:

• Cakupan jelas: dokumentasikan apakah SBOM dibuat dari kode sumber, paket akhir, atau image yang dijalankan.
• Format dapat dibaca: validasi berkas dengan alat yang mendukung SPDX atau CycloneDX dan tangani kesalahan parsing.
• Riwayat tersimpan: arsipkan SBOM per versi rilis dengan akses yang sesuai dan masa retensi yang ditetapkan.
• Temuan ditindaklanjuti: tetapkan siapa yang memeriksa kecocokan kerentanan, siapa yang menerima pengecualian, dan kapan keputusan harus ditinjau kembali.
• Proses diuji: lakukan simulasi dengan satu komponen yang diketahui rentan untuk memastikan tim dapat menemukan semua rilis terdampak.

Checklist ini membuat SBOM lebih dari sekadar berkas kepatuhan. Dokumen tersebut menjadi bagian dari proses operasional yang bisa diuji, diaudit, dan digunakan saat mengambil keputusan.

Kesimpulan

SBOM membuat komposisi perangkat lunak lebih mudah ditelusuri dan membantu organisasi merespons kerentanan dengan lebih terarah. Nilai terbesarnya muncul ketika SBOM dihasilkan dari artefak yang benar, diperbarui setiap rilis, divalidasi, dan dihubungkan dengan proses manajemen kerentanan. Mulailah dari satu aplikasi penting, ukur kelengkapan inventarisnya, lalu perluas ke layanan lain secara bertahap.

Referensi

• CISA: Software Bill of Materials
• SPDX — Software Package Data Exchange
• CycloneDX
• Syft — CLI untuk menghasilkan SBOM