# Membuat dan menggunakan SBOM dalam pengembangan aplikasi

Sumber diperiksa. Metode: https://kompli.id/metodologi/.

Hubungkan daftar komponen perangkat lunak atau SBOM dengan versi rilis, pemeriksaan kerentanan, lisensi, dan tindak lanjut agar inventaris dapat dipakai saat ada masalah.

URL kanonis: https://kompli.id/panduan/keamanan/mengelola-sbom/
Sumber diakses: 2026-09-29
Diperbarui: 2026-09-29
Penulis: Kompli
Sumber diperiksa: 2026-09-29


## SBOM menjawab aplikasi ini tersusun dari apa

Software Bill of Materials atau SBOM mencatat komponen perangkat lunak beserta identitas dan hubungan yang relevan. Daftar ini membantu tim menelusuri komponen terdampak ketika ada kerentanan, perubahan dukungan, atau pemeriksaan lisensi.

SBOM bukan hasil pentest dan bukan jaminan bebas kerentanan. Daftar yang hanya dibuat sekali lalu tidak mengikuti rilis dapat memberi gambaran yang keliru.

## Kaitkan dengan artefak yang benar-benar dirilis

Tetapkan kapan SBOM dibuat, apa yang dicakup, format yang dipakai, dan siapa pemiliknya. Hubungkan berkas dengan identitas produk, versi, waktu, serta artefak rilis. Periksa dependensi langsung dan tidak langsung, paket sistem atau container yang relevan, serta komponen yang tidak terdeteksi otomatis.

| Pemeriksaan | Pertanyaan |
| --- | --- |
| Kecocokan | Apakah daftar sesuai artefak produksi atau hanya repositori pengembangan? |
| Identitas | Bisakah komponen serta versinya dikenali secara konsisten? |
| Kelengkapan | Apa yang tercakup, belum diketahui, atau sengaja dikecualikan? |
| Pemeliharaan | Siapa membuat ulang saat rilis atau dependensi berubah? |
| Penggunaan | Bagaimana temuan berubah menjadi tugas pemeriksaan dan perbaikan? |

Catat keterbatasan cakupan. Jangan mengisi versi yang tidak diketahui dengan perkiraan agar kolom terlihat lengkap.

## Gunakan untuk menilai temuan

Ketika advisori muncul, cari produk dan versi yang memakai komponen tersebut. Periksa apakah fungsi rentan digunakan atau terjangkau, kontrol yang tersedia, dampak, serta pilihan perbaikan. Hasil pencocokan otomatis perlu penilaian, bukan langsung dianggap bukti eksploitasi.

Contoh fiktif: dua layanan memakai pustaka sama, tetapi hanya satu menjalankan fungsi terdampak. Tim memeriksa keduanya, memprioritaskan layanan yang terpapar, dan menyimpan alasan serta hasil uji. Setelah patch, SBOM baru dihubungkan ke rilis baru; daftar lama tetap membantu menelusuri versi sebelumnya sesuai kebijakan retensi.

## Atur berbagi dan tanggung jawab

Sepakati informasi yang diterima pelanggan, jadwal pembaruan, kanal pemberitahuan, dan penanganan komponen yang belum diketahui. Jangan memasukkan rahasia build atau kredensial ke metadata. Kebutuhan kontrak atau sektor harus diperiksa sendiri; panduan ini tidak menyatakan semua bisnis Indonesia wajib menyerahkan SBOM.

Lanjutkan ke [pengelolaan patch](/panduan/keamanan/mengelola-kerentanan-dan-patch/) dan [lisensi komponen](/panduan/operasional-digital/lisensi-open-source-untuk-bisnis/).

## Pahami risiko di balik pemeriksaan

Baca [Software Supply Chain Failures](/panduan/owasp/software-supply-chain-failures/) untuk memahami konsep dan contoh kegagalannya. Gunakan langkah di halaman ini untuk pekerjaan penerapan.
## Sumber rujukan

- [A Shared Vision of SBOM for Cybersecurity (2025)](https://www.cisa.gov/sites/default/files/2025-09/joint-guidance-a-shared-vision-of-software-bill-of-materials-for-cybersecurity_508c.pdf) — Joint guidance 2025: penggunaan SBOM oleh pembuat, pembeli dan operator; manfaat serta batasnya.

## Perlu membahas kebutuhan tim Anda?

Ceritakan sistem yang dikelola dan kebutuhan pengamanan tim Anda.

[Konsultasikan kebutuhan Anda](https://kompli.id/konsultasi/?topik=keamanan)

## Bacaan terkait

- [Pengembangan aplikasi yang aman: threat modeling sampai rilis](https://kompli.id/panduan/keamanan/pengembangan-aplikasi-yang-aman/)
- [Lisensi open source untuk aplikasi bisnis: apa yang diperiksa?](https://kompli.id/panduan/operasional-digital/lisensi-open-source-untuk-bisnis/)