SBOM, SLSA, dan Sigstore: Fondasi Keamanan Rantai Pasok Open Source

SBOM, SLSA, dan Sigstore adalah tiga fondasi yang kini sering disebut bersamaan ketika membahas keamanan rantai pasok perangkat lunak open source. SBOM mencatat isi software, SLSA menilai kekuatan proses build, dan Sigstore memungkinkan penandatanganan tanpa mengelola kunci panjang umur. Artikel ini menjelaskan fungsi masing-masing dan batasnya, terutama kenyataan bahwa provenance yang valid bukan bukti paket aman.

SBOM: Daftar Bahan Perangkat Lunak

CISA menggambarkan SBOM sebagai inventaris bersarang, semacam daftar bahan yang menyusun sebuah perangkat lunak, dan menyebutnya blok bangunan penting dalam keamanan rantai pasok. Isinya mencakup nama dan versi tiap komponen, termasuk dependensi transitif yang sering tidak disadari tim. Format yang umum dipakai adalah SPDX dan CycloneDX.

Nilai praktis SBOM terlihat saat insiden. Ketika sebuah paket dinyatakan berbahaya, seperti pada gelombang worm npm yang kami ulas di artikel supply chain attack, tim yang punya SBOM per rilis dapat menjawab pertanyaan pertama dalam menit: apakah kami memakai versi itu, dan di produk mana. Pendamping SBOM adalah VEX (Vulnerability Exploitability eXchange), yang oleh CISA digambarkan sebagai atestasi, semacam advisori keamanan, tentang apakah sebuah produk terpengaruh oleh kerentanan yang diketahui. Halaman SBOM CISA juga mencantumkan panduan bersama "2026 Updates to Minimum Elements for a Software Bill of Materials" yang menambah kolom data, praktik, dan proses baru, jadi rujuklah versi terbarunya.

Batas SBOM: ia memberi visibilitas, bukan pencegahan. SBOM tidak mendeteksi bahwa komponen sudah berbahaya, dan hanya sebaik data yang dimasukkan ke dalamnya. Di sisi regulasi, kewajiban seperti EU Cyber Resilience Act mendorong produsen mengenal komponen produknya, sehingga SBOM semakin relevan bagi vendor yang menjual ke Eropa.

SLSA: Tingkat Kepercayaan pada Proses Build

SLSA (dibaca "salsa") adalah kerangka tingkat jaminan untuk proses build. Menurut spesifikasi SLSA v1.0, jalur Build memiliki tiga level:

• L1, provenance ada. Produsen menghasilkan provenance yang menjelaskan platform, proses, dan input utama build. Berguna untuk menangkap kesalahan, tetapi mudah dilewati atau dipalsukan.
• L2, build di platform terhosting. Build berjalan di platform terhosting dan provenance ditandatangani secara digital, sehingga memalsukannya butuh serangan yang disengaja. Ini melindungi dari perusakan setelah build.
• L3, build yang diperkeras. Ada kontrol kuat agar build tidak saling memengaruhi, bahkan dalam proyek yang sama, dan rahasia penandatanganan terjauhkan dari langkah build buatan pengguna. Targetnya adalah perusakan saat build, misalnya oleh orang dalam atau kredensial yang dikompromikan.

Spesifikasi menyerahkan detail implementasi kepada tiap ekosistem atau organisasi, dan aspek keamanan sumber (source) dikeluarkan dari v1.0 untuk berfokus pada jalur Build. Dengan kata lain, SLSA menjawab pertanyaan "bagaimana artefak ini dibangun dan oleh siapa", bukan "apakah kodenya baik".

Sigstore: Penandatanganan Tanpa Kunci Panjang Umur

Menurut dokumentasi resmi, Sigstore adalah proyek open source untuk menandatangani dan memverifikasi artefak seperti berkas rilis, image kontainer, dan biner tanpa mengelola kunci berumur panjang. Tiga komponen intinya:

• Cosign, klien yang membuat pasangan kunci sementara, meminta sertifikat, menandatangani artefak, dan mencatat peristiwa penandatanganan.
• Fulcio, otoritas sertifikat yang memeriksa token identitas OIDC penanda tangan lalu menerbitkan sertifikat berumur pendek yang mengikat identitas itu ke kunci publik.
• Rekor, log transparansi yang hanya bisa ditambah, menyimpan digest, tanda tangan, dan sertifikat agar peristiwa penandatanganan dapat diaudit publik.

Identitas penanda tangan bisa berupa email pengguna, akun layanan, atau workflow CI. Kunci privat dibuang setelah satu kali penandatanganan. Ini menghilangkan masalah kunci yang bocor, tetapi mengalihkan kepercayaan ke identitas: verifikator harus memeriksa bahwa identitas pada sertifikat memang yang diharapkan.

Provenance yang Valid Bukan Bukti Paket Aman

Di sinilah banyak tim salah paham. Pada 11 Mei 2026, paket @tanstack terbit dengan provenance yang valid secara kriptografis walaupun berbahaya. Menurut analisis OpenSSF, penyerang memakai token OIDC sah dari runner untuk menandatangani lewat Sigstore, sehingga atestasi benar menyebut builder, repositori, dan workflow. OpenSSF juga mencatat bahwa provenance bawaan npm mencapai Build L2, sedangkan L3 menuntut tiga sifat isolasi: satu build tidak bisa meracuni cache build lain, build tidak bisa mengakses rahasia platform seperti kunci penandatanganan provenance, dan satu build tidak bisa memengaruhi lingkungan build berikutnya. Menurut OpenSSF, serangan TanStack melanggar ketiganya. Unit 42 melaporkan hal serupa pada paket @redhat-cloud-services: paket berbahaya membawa provenance SLSA yang valid setelah akun GitHub seorang karyawan yang dikompromikan dipakai untuk mendorong commit yang melewati code review.

Kesimpulannya: provenance membuktikan di mana dan oleh pipeline mana sebuah artefak dibangun, bukan bahwa pipeline itu berperilaku benar atau kode yang masuk memang yang dimaksud. Menurut OpenSSF, SLSA juga tidak menilai apakah konfigurasi pemicu workflow aman atau apakah izinnya sudah minimal, sehingga kesalahan seperti penggunaan pull_request_target berada di luar jangkauannya. Jangan menjadikan tanda "provenance valid" sebagai satu-satunya gerbang.

Cara Memakai Ketiganya Secara Realistis

1. Hasilkan SBOM setiap rilis produksi dan simpan bersama artefak. Perbarui saat dependensi berubah.
2. Verifikasi tanda tangan dan identitas untuk artefak penting, bukan sekadar keberadaan tanda tangan.
3. Pakai provenance sebagai satu sinyal. Gabungkan dengan pin versi, cooldown, dan peninjauan perubahan dependensi.
4. Perkeras pipeline: izin minimal, jangan jalankan kode fork dengan akses rahasia, perlakukan cache sebagai batas kepercayaan, dan pantau publikasi dari workflow yang gagal. Lihat panduan pipeline CI/CD.
5. Manfaatkan fitur registry seperti trusted publishing dan staged publishing, yang dijelaskan di artikel perubahan keamanan npm.

Satu catatan terakhir tentang kepemilikan: tetapkan siapa yang bertanggung jawab atas SBOM, verifikasi tanda tangan, dan kebijakan pipeline. Tanpa pemilik yang jelas, ketiga fondasi ini cenderung berhenti sebagai dokumen yang dibuat sekali lalu dilupakan.

Baca juga: GlassWorm: Malware Ekstensi VS Code dan Open VSX.

Pertanyaan yang Sering Diajukan

Apakah SBOM hanya untuk perusahaan besar?

Tidak. Tim kecil pun terbantu karena SBOM menjawab pertanyaan paling mendesak saat ada paket berbahaya: apakah kami memakainya. Banyak alat pemindai dependensi dapat menghasilkannya otomatis.

Apa bedanya SLSA dan Sigstore?

SLSA adalah kerangka tingkat jaminan proses build. Sigstore adalah perangkat untuk menandatangani dan memverifikasi artefak. Keduanya saling melengkapi: provenance SLSA sering ditandatangani lewat Sigstore.

Jika artefak punya tanda tangan valid, bolehkah langsung dipercaya?

Tidak otomatis. Tanda tangan valid membuktikan identitas penanda tangan dan integritas artefak, bukan niat atau kebersihan kodenya.

Kesimpulan

SBOM, SLSA, dan Sigstore adalah fondasi yang bernilai, tetapi masing-masing menjawab pertanyaan berbeda dan tidak menggantikan kebiasaan dasar seperti pin versi dan hak akses minimal. Mulailah dengan SBOM per rilis dan verifikasi identitas, lalu perkeras pipeline Anda. Untuk mempelajari praktiknya bersama mentor, lihat kursus Linuxhackingid.