SBOM Mudah Dibuat, Sulit Dipakai. Di Sini Tim Compliance Mulai Kalah atau Menang

Banyak tim sudah bisa generate SBOM dalam hitungan menit. Masalahnya justru mulai setelah file CycloneDX atau SPDX keluar. Begitu auditor, buyer enterprise, atau tim AppSec bertanya, “Mana yang masih relevan hari ini, mana yang benar-benar terekspos, siapa owner-nya, dan pengecualian ini habis kapan?” mendadak suasana rapat berubah.

Itulah SBOM reality check. Membuat SBOM itu bagian termudah. Mengoperasionalkannya di lingkungan nyata jauh lebih susah, karena yang dibutuhkan bukan sekadar daftar komponen, tetapi sistem keputusan yang hidup.

Jawaban Singkat/Key takeaways: SBOM yang bagus bukan file statis, tetapi inventaris yang terus segar, bisa dibandingkan antar-rilis, bisa dipetakan ke reachability, jelas owner-nya, dan punya jalur exception yang disiplin. Kalau lima hal ini nggak ada, SBOM mudah lolos audit dokumen, tetapi lemah saat dipakai untuk prioritas risiko nyata.

Kenapa banyak program SBOM mandek setelah fase awal

Tim biasanya fokus pada satu target yang terlihat jelas, yaitu menghasilkan software bill of materials. Itu wajar, karena permintaan pelanggan, regulator, dan procurement sering dimulai dari situ. Namun setelah file berhasil dihasilkan, muncul gap operasional yang jauh lebih berat.

• Freshness, SBOM kemarin belum tentu cocok untuk build hari ini.
• Diffing, daftar komponen baru tidak berguna kalau kamu nggak tahu apa yang berubah dari rilis sebelumnya.
• Reachability, CVE di dependency belum tentu bisa dieksploitasi di jalur runtime milikmu.
• Ownership, temuan tanpa owner hanya pindah jadi backlog.
• Exception handling, pengecualian tanpa masa berlaku akan berubah jadi lubang permanen.

Karena itu, buyer enterprise yang matang sekarang jarang puas dengan kalimat, “Kami mendukung SBOM.” Mereka ingin tahu apakah SBOM-mu dipakai untuk govern release, bukan hanya disimpan sebagai lampiran.

SBOM yang berguna harus menjawab 5 pertanyaan ini

1. Seberapa segar SBOM ini?

SBOM yang valid saat build versi 2.3.1 bisa usang beberapa jam kemudian kalau pipeline menarik dependency baru, base image berubah, atau komponen build-time ikut bergeser. Jadi, pertanyaan paling penting bukan “punya SBOM atau nggak”, melainkan SBOM ini merepresentasikan artifact mana, kapan, dan dari pipeline mana.

Praktik yang lebih kuat, ikat SBOM ke artifact digest, commit, build ID, dan waktu pembuatan. Pendekatan ini sejalan dengan panduan dari CISA dan ekosistem supply chain modern.

2. Apa yang berubah sejak rilis terakhir?

Banyak tim berhenti di inventaris. Padahal diff lebih bernilai daripada snapshot tunggal. Saat kamu membandingkan dua SBOM, kamu bisa melihat paket baru, versi yang naik, komponen yang hilang, dan perubahan lisensi yang mungkin mengubah profil risiko.

Ini penting untuk procurement, legal, dan AppSec. Risiko sering datang bukan dari keseluruhan daftar, tetapi dari perubahan kecil yang lolos tanpa perhatian.

3. Komponen rentan ini benar-benar bisa dijangkau atau tidak?

Di sini banyak program SBOM gagal memprioritaskan. Mereka melihat CVE, lalu langsung panik. Padahal kerentanan di library yang tidak pernah terpanggil saat runtime, tidak terpakai dalam path produk, atau hanya ada di tool build, level urgensinya berbeda.

Justru ide yang sering terasa aneh di awal adalah ini, SBOM tanpa reachability bisa menciptakan noise lebih cepat daripada insight. Jadi, tujuanmu bukan mengejar daftar CVE terpanjang. Tujuanmu adalah mencari komponen yang benar-benar bisa memengaruhi sistem produksi.

Untuk konteks standar data, cek referensi dari CycloneDX dan SPDX. Formatnya penting, tetapi operasionalisasinya jauh lebih penting.

4. Siapa owner tiap risiko?

Ini titik yang paling sering diabaikan. Dependency ada di aplikasi A, tetapi base image dimiliki platform team. Paket pihak ketiga dipakai service B, tetapi upgrade harus menunggu vendor C. Kalau ownership kabur, remediation melambat.

Karena itu, tambahkan pemetaan sederhana:

• komponen
• service atau produk
• owner teknis
• owner bisnis
• SLA per severity

Tanpa ini, dashboard kelihatan sibuk. Hasil nyatanya tipis.

5. Bagaimana exception ditutup, bukan diwariskan?

Pengecualian memang kadang perlu. Misalnya, patch belum tersedia, vendor belum merilis fix, atau upgrade akan merusak integrasi penting. Namun exception yang sehat harus punya alasan, kompensating control, owner, tanggal kedaluwarsa, dan review ulang.

Kalau exception tidak punya expiry, tim sedang membangun utang risiko yang tersamarkan sebagai proses governance.

Framework praktis, dari file ke keputusan

Kalau kamu ingin program SBOM dipakai oleh compliance team, AppSec leader, dan enterprise buyer sekaligus, pakai alur ini:

1. Generate, hasilkan SBOM per build dan per artifact.
2. Bind, kaitkan ke digest, commit, pipeline, dan environment.
3. Diff, bandingkan dengan rilis sebelumnya.
4. Enrich, tambahkan vulnerability, lisensi, reachability, exploitability, dan owner.
5. Decide, tetapkan gate, SLA, atau exception.
6. Expire, paksa review berkala agar exception dan data lama tidak menumpuk.

Framework ini sengaja sederhana. Namun justru di situ nilainya. Banyak program gagal bukan karena kurang format, melainkan karena terlalu banyak dokumen, terlalu sedikit keputusan operasional.

Apa yang dilihat buyer enterprise saat mengevaluasi vendor

Vendor questionnaire makin matang. Buyer biasanya mulai bertanya:

• Apakah SBOM dihasilkan otomatis untuk setiap release?
• Apakah SBOM dipetakan ke artifact yang dikirim ke customer?
• Apakah ada proses diff antar-rilis?
• Apakah temuan punya owner dan SLA?
• Apakah exception punya expiry dan approval?

Jadi, kalau kamu menjual produk ke enterprise, posisi terbaik bukan sekadar bilang “kami punya SBOM”. Posisi terbaik adalah menunjukkan bahwa program SBOM-mu mendukung trust, response time, dan auditability.

Internal link yang layak kamu baca berikutnya

• SBOM saja nggak cukup, begini cara buktiin siapa yang merilis artifact-mu
• Cara memetakan blast radius dependency transitif
• Playbook rollback cepat saat dependency terkontaminasi

FAQ

Apakah SBOM wajib untuk semua perusahaan?

Nggak selalu wajib untuk semua, tetapi makin sering diminta dalam procurement, audit, dan kontrak enterprise. Di sektor teregulasi, permintaannya jauh lebih umum.

Apa beda SBOM dengan vulnerability scan?

SBOM memberi daftar komponen. Vulnerability scan menilai apakah komponen itu terkait kerentanan tertentu. Keduanya saling melengkapi, bukan saling menggantikan.

Kenapa reachability penting dalam program SBOM?

Karena tidak semua CVE relevan dengan jalur eksekusi nyata. Reachability membantu tim memprioritaskan risiko yang benar-benar bisa berdampak ke produksi.

Format mana yang lebih baik, CycloneDX atau SPDX?

Tergantung kebutuhan ekosistemmu. CycloneDX sering kuat untuk use case keamanan aplikasi, sementara SPDX juga luas dipakai untuk pertukaran data komponen dan lisensi. Yang paling penting, format yang kamu pilih harus masuk ke workflow operasional.

Intinya sederhana. SBOM bukan proyek ekspor file. SBOM adalah sistem untuk menjaga inventaris tetap segar, memahami perubahan, mengurangi noise, menetapkan owner, dan menutup exception dengan disiplin. Kalau kamu baru berhenti di tahap generate, kamu belum gagal. Kamu cuma belum sampai bagian yang paling menentukan.

Kalau kamu sedang membangun program SBOM, proses procurement security, atau workflow AppSec yang lebih bisa diaudit, tulis pengalamanmu di kolom komentar. Lalu, subscribe juga supaya kamu nggak ketinggalan pembahasan praktis soal supply chain security, compliance, dan operasi keamanan aplikasi.