SBOM Bukan Artefak Sekali Jadi: Kenapa Pemindaian Ulang Berkala Wajib Meski Kode Anda Tidak Berubah Sebaris Pun

Catatan peer-to-peer untuk CTO, engineering lead, dan pemilik produk yang aplikasinya sudah stabil di produksi — dan karena itu menganggap tidak ada deploy berarti tidak ada risiko baru.

---

1. Jumat Sore yang Tidak Ada Hubungannya dengan Kode Anda

Jumat, 16:40. Aplikasi Anda terakhir dideploy sebelas minggu lalu. Tidak ada merge request minggu ini. Pipeline terakhir hijau seluruhnya. Tim sedang mengerjakan modul lain.

Lalu masuk satu email dari tim keamanan klien: “Ada advisory kritis untuk library X. Apakah aplikasi yang Anda bangun untuk kami memakainya? Mohon konfirmasi hari ini.”

Anda membuka repo. package.json tidak menyebut library X. composer.json juga tidak. Tapi pertanyaannya bukan apa yang Anda pasang — melainkan apa yang benar-benar terpasang. Library X adalah dependensi dari dependensi dari framework yang Anda pakai. Ia ada di node_modules, ia ikut ter-bundle, dan tidak ada satu orang pun di tim Anda yang pernah memutuskan untuk memakainya.

Butuh empat jam untuk menjawab email yang seharusnya dijawab dalam empat menit. Dan jawabannya ternyata “ya”.

Kode Anda tidak berubah sebaris pun sejak sebelas minggu lalu. Postur keamanan aplikasi Anda berubah total pada hari Selasa, saat advisory itu terbit.

2. Yang Berubah Bukan Kode Anda — Tapi Pengetahuan Dunia Tentang Kode Anda

SBOM (Software Bill of Materials) adalah daftar bahan perangkat lunak: setiap paket, setiap versi, termasuk yang transitif, dalam format mesin yang bisa dibaca ulang — standar de-facto-nya CycloneDX.

Banyak tim memperlakukan SBOM sebagai dokumen kepatuhan: dibuat sekali saat rilis, dilampirkan ke berita acara, lalu selesai. Cara pandang ini salah secara mekanis, dan salahnya mudah dijelaskan dalam satu kalimat:

Basis data kerentanan diperbarui hampir setiap hari; SBOM rilis produksi Anda tidak berubah. Yang berubah adalah hasil pencocokan keduanya.

SBOM adalah daftar bahan. Pemindaian adalah pencocokan daftar bahan itu dengan daftar bahan berbahaya yang dikelola dunia — NVD, OSV, advisory vendor, advisory ekosistem. Daftar pertama statis. Daftar kedua bertambah puluhan ribu entri setiap tahun.

Memindai SBOM sekali saat rilis sama dengan mengecek daftar penarikan produk satu kali, di hari Anda membeli barangnya, lalu tidak pernah lagi.

3. Empat Hal yang Terus Bergerak Saat Repositori Anda Diam

Gate SAST bereaksi terhadap perubahan kode. Setelah go-live, kode aplikasi relatif tenang. Yang tidak pernah berhenti bergerak adalah hulunya:

• CVE baru atas versi yang sudah lama terpasang. log4j-core 2.14.1 adalah versi yang wajar dan “aman” selama bertahun-tahun — sampai 9 Desember 2021, ketika CVE-2021-44228 terbit dan jutaan aplikasi yang tidak berubah sebaris pun mendadak menjadi rentan kritis. Tidak ada yang men-deploy apa pun hari itu. Yang berubah adalah pengetahuan publik.
• Kerentanan yang dulu tidak ada perbaikannya, kini ada. Temuan Critical tanpa patch hulu biasanya dilewati pipeline (--ignore-unfixed) karena memblokirnya hanya memindahkan pekerjaan menjadi penulisan pengecualian. Saat patch akhirnya rilis — tiga minggu kemudian, tanpa pengumuman ke Anda — status temuan itu berubah dari “tidak bisa diapa-apakan” menjadi “harus dikerjakan”. Hanya pemindaian ulang yang menangkap transisi ini.
• Dependensi transitif yang tidak pernah Anda pilih. Proyek modern membawa ratusan paket yang tidak ada di manifest Anda. Mereka masuk lewat lockfile, bukan lewat keputusan. Anda tidak mengikuti rilis mereka, tidak berlangganan advisory mereka, dan tidak akan tahu apa-apa kecuali ada mesin yang mencocokkannya untuk Anda.
• Base image dan paket sistem operasi. Image container yang tidak pernah di-rebuild membawa paket OS yang membeku di tanggal build. Aplikasinya boleh sempurna; openssl di dalam image-nya tidak.

Tambahan yang lebih tidak nyaman: paket bisa berpindah tangan. Backdoor CVE-2024-3094 pada xz-utils di Maret 2024 disisipkan oleh maintainer yang sudah dipercaya selama dua tahun, ke dalam paket yang dipakai hampir semua distribusi Linux. Tidak ada pemindaian yang bisa menangkapnya sebelum ia diketahui. Yang menentukan adalah berapa cepat Anda bisa menjawab “apakah kami memakainya” setelah ia diketahui — dan itu murni soal apakah SBOM Anda terarsip dan dipindai ulang, atau tidak.

Konsekuensinya satu, dan ini yang paling sering ditolak secara emosional oleh tim: bulan tanpa perubahan kode bukan bulan tanpa perubahan risiko.

4. Baris Paling Penting di Tabel Kriteria Kelulusan Anda

Setiap pipeline yang serius punya tabel ambang: apa yang memblokir merge, apa yang cukup jadi peringatan, berapa SLA perbaikannya. Di tabel itu hampir selalu ada satu baris yang terlihat seperti kompromi kecil:

“Critical / High tanpa perbaikan hulu → lolos bersyarat.”

Baris itu memang kompromi yang disengaja dan masuk akal — memblokir kerentanan yang belum ada obatnya hanya menghasilkan dokumen pengecualian, bukan keamanan. Tapi baris itu hanya sah bila dipasangkan dengan pemindaian ulang terjadwal yang akan menaikkannya menjadi Block begitu perbaikan tersedia.

Tanpa pasangan itu, “lolos bersyarat” berhenti menjadi kompromi dan berubah menjadi lubang permanen — dengan dokumentasi rapi yang menjelaskan kenapa lubang itu boleh ada. Ini pola kegagalan yang paling sering saya temukan saat mengaudit pipeline yang “sudah ada gate keamanannya”.

5. SBOM yang Tidak Lengkap Lebih Berbahaya daripada SBOM yang Gagal Dibuat

Kalau pembangkit SBOM gagal, Anda dapat pesan error dan pipeline merah. Itu kondisi yang sehat.

Yang berbahaya adalah SBOM yang terbentuk tetapi tidak lengkap. Misalnya proyek Anda punya komponen PHP dan Node, tetapi konfigurasinya hanya menjabarkan composer.lock. Berkasnya ada, ukurannya wajar, gate hijau, dan tidak ada satu pun pesan kesalahan. Konsekuensinya: seluruh dependensi Node hilang dari SBOM — dan karena SBOM itulah yang dipindai ulang tiap minggu, mereka hilang pula dari pemantauan Anda, seterusnya, tanpa ada yang menyadari.

Karena itu SBOM harus punya syarat sah yang diverifikasi mesin, minimal dua:

• Jumlah komponen bukan nol untuk setiap ekosistem yang lockfile-nya ada di repositori.
• Berkasnya dapat diurai sebagai CycloneDX yang valid.

Dua aturan turunan yang menyertainya:

• Lockfile adalah prasyarat, bukan formalitas. Memindai manifest tanpa lockfile berarti memindai apa yang boleh terpasang, bukan apa yang benar-benar terpasang. Ekosistem yang punya manifest tapi tidak punya lockfile harus menggagalkan tahap awal pipeline, bukan sekadar memberi peringatan.
• Satu pembangkit SBOM untuk seluruh proyek. Perkakas berbeda menjabarkan lockfile dengan kelengkapan berbeda. Selisihnya tidak akan pernah terlihat kecuali Anda sengaja membandingkan keduanya secara langsung. Kami menetapkan Syft → CycloneDX JSON sebagai baku, dan Trivy sebagai satu-satunya sumber penegakan ambang, supaya ambangnya tidak terpecah antar-tool.

6. Mekanisme Pemindaian Ulang yang Tidak Akan Dimatikan Orang dalam Sebulan

Ini bagian yang paling sering gagal dalam praktik, dan penyebabnya bukan teknis.

Pemindaian ulang mingguan yang naif akan menghasilkan laporan berisi 60 temuan yang sama persis, setiap minggu, tanpa henti. Minggu pertama dibaca. Minggu kedua dibaca sekilas. Minggu keempat filternya dibuat, dan mekanisme itu efektif mati — sementara di dasbor semuanya tampak masih berjalan.

Bentuk yang bertahan punya empat langkah, dan langkah ketiga yang menentukan:

1. Ambil SBOM rilis yang sedang berjalan di produksi — bukan SBOM dari branch utama, karena keduanya bisa berbeda.
2. Pindai ulang terhadap basis data kerentanan terbaru.
3. Bandingkan dengan hasil periode sebelumnya.
4. Buka issue otomatis hanya untuk temuan baru, dengan label severity dan SLA yang melekat.

Hasil akhirnya: minggu yang tenang menghasilkan nol notifikasi, dan satu notifikasi yang muncul berarti sesuatu yang benar-benar baru. Itulah satu-satunya bentuk yang masih hidup enam bulan kemudian.

Satu jebakan lagi yang mahal: versi scanner juga perlu ditinjau berkala. Scanner yang di-pin dua tahun lalu memakai basis data yang sudah tidak diperbarui. Pipeline-nya tetap hijau — bukan karena aman, tapi karena tidak tahu apa-apa.

7. Ujian Sebenarnya: Pertanyaan di Jam Pertama Insiden

Nilai SBOM tidak terasa di hari-hari normal. Ia terasa persis pada jam pertama setelah sebuah advisory rantai pasok terbit, ketika satu pertanyaan datang dari klien, dari auditor, atau dari tim keamanan internal:

“Apakah kita memakai paket X versi Y — di sistem mana saja, dan sejak rilis yang mana?”

Tanpa SBOM terarsip, jawabannya adalah menyisir repositori, membuka lockfile satu per satu, menebak-nebak dependensi transitif, dan menyerahkan jawaban setengah yakin dalam hitungan jam atau hari.

Dengan SBOM per rilis yang terarsip dan ter-retensi, jawabannya adalah satu kueri atas berkas yang sudah ada — lengkap dengan dependensi transitif, dan bisa ditelusuri per rilis. Hitungan menit, dengan tingkat keyakinan yang bisa dipertanggungjawabkan.

Ini juga alasan retensi SBOM harus lebih panjang daripada masa proyek. Pertanyaan “sejak kapan kami terdampak” selalu datang belakangan, dan hanya bisa dijawab oleh arsip.

8. Bulan Tanpa Temuan Tetap Bulan dengan Pekerjaan

Ada pertanyaan yang muncul di hampir setiap kontrak pemeliharaan, biasanya di bulan ketiga atau keempat, saat semuanya berjalan tenang:

“Bulan ini tidak ada insiden dan tidak ada fitur baru. Sebenarnya apa yang dikerjakan?”

Ini pertanyaan yang sah, dan tim yang tidak bisa menjawabnya akan kehilangan kontraknya — bukan karena tidak bekerja, tapi karena pekerjaannya tidak terlihat.

Jawabannya harus berupa laporan yang menyatakan apa yang diperiksa, bukan hanya apa yang ditemukan:

• Berapa dependensi diperiksa, berapa diperbarui, berapa ditahan — beserta alasan penahanannya.
• Setiap kerentanan yang dievaluasi, beserta keputusannya: diperbaiki, tidak berlaku pada konteks ini, atau ditunda dengan alasan eksplisit.
• Daftar patching dan pemeliharaan preventif periode berjalan.
• Status regression test, backup, dan capaian SLA terhadap tiket yang masuk.

Memeriksa 40 dependensi dan menyimpulkan tidak ada yang perlu diperbaiki adalah hasil kerja, bukan ketiadaan kerja. Laporan yang hanya melaporkan temuan akan selalu terlihat kosong di bulan yang aman — dan justru membuat pekerjaan pencegahan tampak seperti biaya yang bisa dipotong.

9. Kalau Mau Mulai Minggu Ini

Tidak perlu transformasi DevSecOps besar-besaran. Urutan ini bisa dikerjakan bertahap, dan tiap langkahnya sudah memberi nilai sendiri:

1. Pastikan setiap ekosistem punya lockfile yang sinkron dengan manifest-nya. Tanpa ini, langkah berikutnya menghasilkan angka yang salah.
2. Bangkitkan SBOM dengan satu tool untuk seluruh proyek, keluarkan sebagai CycloneDX JSON.
3. Validasi kelengkapannya — komponen bukan nol per ekosistem, berkas valid — dan jadikan kegagalan validasi sebagai penggagal pipeline.
4. Arsipkan SBOM sebagai artefak rilis, melekat pada rilis yang berjalan di produksi, bukan sekadar artefak pipeline yang kedaluwarsa dalam 30 hari.
5. Jadwalkan pipeline mingguan yang memindai ulang SBOM produksi terhadap basis data terbaru.
6. Tambahkan pembandingan antar-periode, dan buka issue hanya untuk temuan baru. Ini langkah yang menentukan apakah mekanisme ini masih hidup bulan depan.
7. Tetapkan SLA per severity dan tinjau versi scanner Anda tiap kuartal.

Butuh satu sampai dua hari kerja untuk proyek berukuran sedang. Dibandingkan dengan empat jam panik di Jumat sore, ditambah pertanyaan susulan dari tim keamanan klien yang kini meragukan semua jawaban Anda.

10. Bagaimana Erasys Menjalankannya

SBOM bukan tambahan opsional pada cara kami bekerja — ia satu tahap tetap di dalam DevSecOps Erasys, pada gate komposisi perangkat lunak (GATE-SCA) yang berjalan di setiap merge request, sejajar dengan gate analisis statis dan gate pemindaian image.

Yang kami jamin bukan “aplikasi Anda tidak akan pernah punya CVE” — tidak ada penyedia yang bisa menjamin itu, dan siapa pun yang menjanjikannya sedang menjual sesuatu yang tidak ia kendalikan. Kerentanan baru diterbitkan setiap hari, atas paket yang hari ini masih dianggap bersih.

Yang kami jamin adalah hal yang benar-benar berada dalam kendali kami, dan semuanya bisa Anda verifikasi sendiri:

• Setiap rilis membawa SBOM lengkap yang tervalidasi mesin — bukan berkas yang sekadar terbentuk. Komponen bukan nol untuk tiap ekosistem, format CycloneDX yang sah, satu pembangkit untuk seluruh proyek.
• SBOM rilis produksi dipindai ulang secara terjadwal terhadap basis data kerentanan terbaru — bukan hanya saat ada deploy, termasuk selama bulan-bulan tenang ketika tidak ada perubahan kode sama sekali.
• Temuan baru dibuka sebagai issue otomatis dengan severity dan SLA yang melekat, dan hanya temuan baru — sehingga mekanismenya tetap dipakai, bukan dimatikan dalam sebulan.
• Kerentanan Critical yang perbaikannya tersedia memblokir merge, dan yang muncul dari pemindaian terjadwal punya batas waktu perbaikan yang tertulis, bukan “secepatnya”.
• SBOM dan seluruh laporan gate diarsipkan per rilis dengan masa retensi yang melampaui masa proyek — sehingga pertanyaan “apakah kami terdampak, dan sejak rilis mana” bisa dijawab dalam hitungan menit, bertahun-tahun kemudian.
• Laporan pemeliharaan bulanan menyatakan apa yang diperiksa, bukan hanya apa yang ditemukan — sehingga bulan yang aman tetap bisa dipertanggungjawabkan sebagai bulan kerja.
• Kepemilikan setiap temuan jelas: siapa memperbaiki, dalam berapa lama, dan apa konsekuensinya bila lewat. Keputusan lisensi dan penerimaan risiko tetap berada di tangan Anda, difasilitasi Technical Lead kami.

Ini berlaku sama untuk aplikasi yang kami bangun dari nol maupun sistem berjalan yang masuk ke dalam kontrak pemeliharaan kami — termasuk sistem yang tidak kami tulis kodenya. Untuk sistem yang sudah berjalan, langkah pertamanya selalu sama: membangkitkan SBOM pertama dan memindainya. Hasil pemindaian pertama itu hampir selalu mengejutkan, dan justru itu gunanya.

11. Penutup

Kode yang stabil adalah kabar baik. Tapi stabil bukan sinonim dari aman, karena permukaan risiko aplikasi Anda tidak hanya ditentukan oleh apa yang Anda tulis — melainkan juga oleh ratusan paket yang Anda bawa, yang terus dinilai ulang oleh dunia luar setiap hari.

SBOM yang dibuat sekali dan tidak pernah dipindai ulang bukan kontrol keamanan. Ia dokumen kepatuhan yang akan basi dalam hitungan minggu, dan bahayanya justru pada rasa aman yang ia berikan.

Kalau Anda ingin tahu seperti apa hasil pemindaian pertama atas aplikasi Anda yang sekarang — yang sudah berjalan tenang berbulan-bulan — hubungi kami. Percakapan itu biasanya dimulai dengan satu berkas SBOM, dan berakhir dengan daftar yang jauh lebih pendek daripada yang ditakutkan, tapi tidak pernah kosong.

---

Tulisan lain dalam seri ini: Case for Automated SAST — menangkap cacat keamanan di commit, bukan di audit; Kredensial yang Dihardcode — vektor kebocoran nomor satu pada tim yang ship cepat; dan TDD di Era Vibe Coding.