Persyaratan SBOM untuk Pengadaan dan Assurance Software
SBOM menjawab pertanyaan pengadaan yang spesifik: komponen software apa yang membentuk produk yang benar-benar dikirim? NTIA dan CISA menjelaskannya sebagai inventaris bertingkat, bukan sertifikasi keamanan. Karena itu SBOM dipakai sebagai bukti rilis untuk tindak lanjut kerentanan, lisensi, dan pemasok; bukan bukti bahwa produk bebas celah atau patuh secara hukum.
Jadikan SBOM keluaran kontrak
Cantumkan penyerahan SBOM di ruang lingkup pembelian, kriteria penerimaan, dan serah-terima rilis. Minta CycloneDX, SPDX, atau format mesin lain yang disepakati. NTIA mencatat format tersebut sebagai pilihan pertukaran SBOM; CycloneDX mendefinisikan struktur untuk komponen, relasi dependensi, dan metadata. PDF atau spreadsheet boleh menjadi lampiran pembaca, tetapi tidak menggantikan berkas yang dapat diparsing dan dibandingkan.
Minta satu SBOM untuk setiap artefak rilis: installer, paket mobile, image container, library, dan layanan yang dipasang terpisah. Inventaris tingkat portofolio mudah menyamarkan perbedaan versi. Pemasok perlu menyatakan cakupan transitive dependency, binary yang dibundel, modul opsional, paket sistem operasi, dan alat build. Ketiadaan hanya bernilai bila cakupannya tegas.
Jadwal pengadaan yang bisa diuji
| Field kontrak | Contoh terisi | Bukti penerimaan | Pemilik |
|---|---|---|---|
| Identitas artefak | portal-api:2.4.1, digest sha256:ab12... | Manifest rilis dan digest | Pemilik rilis pemasok |
| Format | CycloneDX JSON 1.6 | Parser menerima berkas | Pemilik build pemasok |
| Identitas komponen | pkg:npm/[email protected] | purl dan versi | Pemilik build pemasok |
| Relasi | aplikasi bergantung pada express | Edge dependensi hadir | Pemilik build pemasok |
| Waktu kirim | saat rilis diterbitkan | Lampiran record rilis | Pemilik pengadaan |
| Kanal pembaruan | SBOM baru setelah komponen berubah | Berkas bertanggal dan changelog | Kontak keamanan pemasok |
Contoh minimal yang dapat diuji:
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"metadata": {"component": {"name": "portal-api", "version": "2.4.1"}},
"components": [{"type": "library", "name": "express", "version": "4.21.2", "purl": "pkg:npm/[email protected]"}]
}Data ini hanya contoh format, bukan klaim tentang produk tertentu. Bukti inti adalah keterikatan digest artefak dengan record SBOM. Tanpanya pemasok dapat menyerahkan inventaris yang valid untuk build lain atau rilis lama.
Uji penerimaan sebelum milestone
Pemilik pengadaan mengumpulkan artefak rilis, digest, SBOM, waktu pembuatan, nama dan versi tool, serta kontak pemasok. Tim engineering menghitung ulang digest artefak, mem-parsing SBOM, lalu membandingkan nama, versi, dan digest tingkat atas dengan record rilis. Security mengambil sampel komponen berisiko tinggi: resolusikan package identifier, bandingkan versinya dengan lockfile atau inspeksi image, dan nilai apakah relasi dependensinya masuk akal. Simpan keluaran uji bersama bukti pengadaan.
Penerimaan lulus bila seluruh artefak wajib tersedia, parser berhasil, identitas cukup dapat diresolusikan untuk tujuan yang disepakati, dan keterikatan rilis terbukti. Tolak bila hanya ada tabel statis, tidak ada hubungan ke artefak, cakupan tidak dinyatakan, identifier ambigu, atau inventaris lebih lama dari rilis. Data tidak lengkap harus ditandai tidak lengkap, bukan dianggap bersih.
Kelola pengecualian sebagai utang berakhir
Pemasok lama mungkin belum dapat membuat SBOM lengkap. Catat ID pengecualian, field yang hilang, produk terdampak, pemilik bisnis, pemilik security, bukti pengganti sementara, tanggal berakhir, dan tanggal perbaikan. Contoh: EXC-SBOM-014 mengizinkan inventaris paket internal untuk satu rilis sambil pemasok mengaktifkan CycloneDX; penerimaan bersifat bersyarat dan kedaluwarsa pada tanggal yang ditetapkan. Pengecualian bukan pengabaian permanen.
Pakai inventaris sesudah pembelian
CISA menjelaskan VEX sebagai atestasi apakah kerentanan diketahui memengaruhi produk. Minta VEX atau kanal respons pemasok bila triage membutuhkan itu, tetapi bedakan dengan SBOM: inventaris menunjukkan kemungkinan keterpaparan; VEX dapat menjelaskan keberlakuan. Pemilik security mencocokkan advisory baru dengan inventaris rilis tersimpan dan membuka remediasi setelah relevansi produk/versi dikonfirmasi.
Perbaikan dapat berupa membetulkan generator build, menambahkan package identifier, memperbaiki edge dependensi, atau menerbitkan SBOM yang dikoreksi untuk artefak sama. Ulangi parser dan pengecekan digest. Audit kode dapat menilai kecocokan deklarasi komponen dengan bukti build.
Ulangi pengikatan rilis
Jalankan generator setelah resolusi dependensi, simpan hasil di samping artefak rilis tak berubah, lalu catat command, versi generator, waktu UTC, digest artefak, digest SBOM, dan reviewer. Parser yang sukses saja belum cukup: bandingkan satu package transitive dan edge dependensi teresolusi dengan data lock build. Hasil yang diharapkan adalah package URL dan versi cocok; mismatch, edge hilang, atau pengganti tanpa tanda tangan adalah gagal. Pemilik pengadaan membuka remediasi pemasok; pemilik security menyimpan inventaris lama untuk triage advisory.
Pemeriksaan pengadaan dan penutupan
Minta pemasok satu SBOM yang terikat ke artefak terkirim secara tepat, bukan inventaris saat ini dari branch lain. Untuk image container, catat digest imutabel, waktu pembuatan, versi tool, nama dan versi komponen, package URL, relasi dependensi, hash bila tersedia, serta waktu feed kerentanan. Perintah yang berguna ialah syft registry.example.test/payments@sha256:REPLACE_ME -o cyclonedx-json > payments.cdx.json; output yang diharapkan berupa JSON dengan metadata komponen dan digest image yang menunjukkan release candidate sama. Bandingkan kemudian dengan digest manifest deployment. Bila SBOM menyebut 1.8.4 sedangkan digest terdeploy memuat 1.8.3, bukti belum menutup pemeriksaan.
Kasus tepi: package bisa hadir hanya dalam build layer, artefak hasil generate, atau plugin runtime opsional. Tidak muncul dalam lockfile bukan bukti package tidak ada di deliverable. Minta pemasok menjelaskan scope, file dikecualikan, dan komponen belum terselesaikan. Kecocokan kerentanan adalah masukan triage, bukan bukti eksploit otomatis; catat jalur yang terjangkau, fitur terkonfigurasi, rentang versi terdampak, dan keputusan perbaikan pemasok.
Tutup item saat digest artefak, hash SBOM, hasil validasi, pemilik pengecualian, dan tanggal retest tersimpan bersama. Buat ulang setelah dependensi berubah, base image dibangun ulang, signing berubah, atau release baru dibuat; jangan memakai SBOM lama hanya karena label versi produk sama.