Daftar Bahan Perangkat Lunak (SBOM)

Daftar Bahan Perangkat Lunak (SBOM) adalah inventaris formal yang dapat dibaca mesin tentang setiap komponen di dalam suatu perangkat lunak: pustaka, versinya, lisensi, dan informasi pemasok.

Sama seperti label makanan mencantumkan bahan-bahannya, SBOM memungkinkan Anda menjawab dalam hitungan detik: apakah produk ini mengandung versi rentan X? Tanpanya, pertanyaan tersebut dapat memerlukan berhari-hari penyelidikan manual.

Ketika kerentanan kritis muncul, pertanyaan operasional pertama adalah paparan: produk kita yang mana yang menyertakan komponen terdampak?

Selama insiden Log4Shell, organisasi yang memiliki SBOM dapat menelusuri inventarisnya dan melakukan triase dalam hitungan jam. Organisasi tanpa SBOM menghabiskan waktu berminggu-minggu untuk mencari di direktori pembangunan. Otoritas pengawas dan pembeli besar semakin sering mewajibkan SBOM sebagai syarat pengadaan.

• Analisis dampak kerentanan secara cepat
• Kepatuhan lisensi dan pelacakan kewajiban
• Transparansi rantai pasokan bagi pelanggan dan auditor

Dua standar terbuka paling banyak digunakan. Alat biasanya dapat mengonversi salah satunya ke yang lain.

• SPDX — standar Linux Foundation yang kuat dalam hal lisensi dan diterima luas oleh otoritas pengawas
• CycloneDX — standar OWASP yang berfokus pada keamanan serta mendukung data kerentanan dan hubungan dependensi

Hindari membuat format sendiri; pengguna dan alat pemindai mengharapkan format-format ini.

Setiap entri komponen harus memuat identitas yang cukup agar dapat dicocokkan dengan umpan kerentanan. Kolom utamanya:

• nama dan versi — harus tepat, bukan rentang
• PURL (alamat paket) — pengenal universal seperti pkg:npm/lodash@4.17.21
• hash — untuk memverifikasi integritas
• lisensi — pengenal lisensi SPDX
• pemasok — pihak yang memproduksinya

Buat SBOM secara otomatis dari sumber atau artefak yang telah dibangun. Syft adalah pembuat lintas ekosistem yang umum digunakan dan menghasilkan kedua standar tersebut.

SBOM yang dibuat pada tahap berbeda menangkap fakta yang berbeda.

• SBOM sumber — hal yang dinyatakan oleh manifes; mungkin tidak menyertakan kode yang dibundel atau disertakan
• SBOM pembangunan — hal yang benar-benar disertakan oleh proses pembangunan; paling akurat untuk rilis
• SBOM waktu proses / yang diterapkan — hal yang benar-benar ada dalam citra yang sedang berjalan, termasuk paket OS

Untuk menjamin keamanan rantai pasokan, buat SBOM pada waktu pembangunan dari artefak sebenarnya, lalu pindai kontainer final untuk menemukan paket OS juga.

SBOM menjadi sangat berguna ketika dianalisis oleh alat pencocokan yang memetakan komponen ke CVE yang diketahui. Hal ini memisahkan pembuatan dari analisis: pindai SBOM lama pada hari ketika CVE baru ditemukan.

SBOM mungkin menunjukkan komponen rentan yang sebenarnya tidak dapat dieksploitasi dalam produk Anda (fungsi yang rentan tidak pernah dipanggil). Dokumen VEX (Pertukaran Eksploitabilitas Kerentanan eXchange) mencatat penilaian tersebut.

VEX mengurangi alarm yang tidak relevan: alih-alih membuat setiap pelanggan panik karena CVE yang tercantum, Anda dapat menerbitkan pernyataan not_affected dengan alasannya, atau affected dengan perbaikannya. Dengan demikian, inventaris mentah berubah menjadi triase yang dapat ditindaklanjuti.

SBOM hanya dapat dipercaya jika autentik dan terikat pada artefak persis yang dijelaskannya. Tanda tangani SBOM dan lampirkan sebagai pengesahan, bukan sebagai berkas terpisah.

SBOM manual segera menjadi tidak sesuai. Integrasikan pembuatannya ke dalam alur kerja agar setiap rilis menghasilkan dan menyimpan satu SBOM sebagai artefak pembangunan, idealnya ditandatangani dan dipindai dalam tugas yang sama.

• Buat dari artefak yang telah dibangun, bukan hanya dari repositori
• Simpan SBOM dalam registri yang dapat dicari dengan kueri dan dikelompokkan berdasarkan versi
• Pindai ulang SBOM yang tersimpan secara terjadwal menggunakan sumber data CVE terbaru
• Jadikan rilis bergantung pada hasil pemindaian kerentanan

SBOM dapat gagal secara diam-diam jika hanya diperlakukan sebagai formalitas.

• Kedaluwarsa — dibuat sekali dan tidak pernah dibuat ulang
• Tidak lengkap — tidak menyertakan paket OS serta kode yang ditautkan secara statis atau disertakan
• Tidak terverifikasi — tidak ada hash yang menghubungkannya dengan artefak yang diterapkan
• Tidak digunakan — dibuat, tetapi tidak pernah dipindai atau ditelusuri

Tujuannya adalah SBOM yang akurat, dibuat ulang, ditandatangani, dan terus-menerus dipindai, bukan berkas JSON sekali pakai.

Terapkan hal yang telah Anda pelajari pada skenario insiden.

Sekarang Anda dapat menginventarisasi isi perangkat lunak dan menindaklanjutinya.

• SBOM adalah daftar setiap komponen yang dapat dibaca mesin, dalam format SPDX atau CycloneDX
• Identifikasi komponen berdasarkan PURL, versi, hash, dan lisensi
• Buat pada waktu pembangunan, lalu masukkan ke alat pencocokan (grype, osv-scanner) untuk menemukan CVE
• Gunakan VEX untuk menyatakan kemampuan eksploitasi yang sebenarnya dan mengurangi alarm palsu
• Tanda tangani dan otomatisasikan dalam integrasi berkelanjutan; pindai ulang SBOM yang tersimpan terhadap umpan baru

Berikutnya: membuktikan asal artefak dengan tanda tangan.