Panduan SBOM + SLSA untuk DevSecOps 2026: Cara Praktis Mengamankan Rantai Pasok Perangkat Lunak

Serangan terhadap software supply chain meningkat karena banyak aplikasi modern dibangun dari ratusan dependensi open-source, container image, dan layanan pihak ketiga. Di 2026, organisasi yang hanya mengandalkan pemindaian kerentanan sesaat akan tertinggal. Kombinasi SBOM (Software Bill of Materials) dan SLSA (Supply-chain Levels for Software Artifacts) memberi fondasi yang lebih kuat untuk visibilitas, integritas build, dan respons insiden.

Apa itu SBOM dan kenapa sekarang jadi prioritas?

SBOM adalah inventaris komponen software—ibarat daftar bahan dalam produk digital. Dengan SBOM, tim bisa menjawab pertanyaan kritis: “Aplikasi ini memakai library apa saja, versi berapa, dan berasal dari mana?” Menurut CISA, SBOM adalah blok dasar dalam manajemen risiko supply chain software.

• Manfaat operasional: percepat identifikasi dampak saat ada CVE baru.
• Manfaat audit: bantu bukti kepatuhan dan komunikasi ke pelanggan enterprise.
• Manfaat bisnis: kurangi waktu henti karena keputusan patch jadi lebih presisi.

Peran SLSA: bukan cuma “apa” yang dipakai, tapi “bagaimana” software dibangun

Jika SBOM fokus pada komponen, SLSA fokus pada kepercayaan proses build. Spesifikasi SLSA v1.0 menekankan provenance (asal-usul artefak) dan peningkatan jaminan bertahap per level.

Ringkas level build SLSA

• Build L1: provenance sudah tersedia (dasar visibilitas).
• Build L2: provenance ditandatangani dan dihasilkan platform build terkelola.
• Build L3: build platform diperkeras untuk mengurangi risiko tampering saat proses build.

Untuk mayoritas tim SaaS, target realistis awal adalah stabil di L2 sebelum naik ke L3.

Framework implementasi 90 hari untuk tim Indonesia

Fase 1 (Minggu 1-4): Visibilitas komponen

• Standarkan format SBOM (CycloneDX atau SPDX) untuk setiap release.
• Integrasikan generator SBOM pada pipeline CI/CD.
• Simpan SBOM sebagai artefak build dan tautkan ke versi aplikasi.

Fase 2 (Minggu 5-8): Integritas build

• Aktifkan signed provenance pada pipeline.
• Batasi akses kredensial build (prinsip least privilege).
• Terapkan kebijakan: artefak tanpa provenance tidak boleh dipromosikan ke production.

Fase 3 (Minggu 9-12): Operasionalisasi respons kerentanan

• Hubungkan data CVE ke SBOM untuk pemetaan dampak otomatis.
• Prioritaskan patch berdasarkan exploitability dan eksposur layanan.
• Buat SLA internal: triase < 24 jam untuk kerentanan kritis pada komponen internet-facing.

KPI yang sebaiknya dipantau

• Coverage SBOM: persentase release yang memiliki SBOM lengkap.
• Provenance Compliance: persentase artefak dengan provenance tervalidasi.
• MTTR Vulnerability: waktu rata-rata dari deteksi hingga mitigasi.
• Policy Violation Rate: jumlah deployment ditolak karena tidak memenuhi kebijakan supply chain.

Kaitan dengan NIST SSDF

NIST SP 800-218 (SSDF) merekomendasikan praktik secure software development yang bisa diintegrasikan ke berbagai SDLC. SBOM dan SLSA membantu menurunkan jumlah kerentanan, meningkatkan ketertelusuran, dan memperkuat komunikasi keamanan antara vendor dan pembeli software.

Kesalahan umum yang perlu dihindari

1. SBOM hanya untuk compliance: padahal nilainya paling besar saat dipakai harian untuk operasi keamanan.
2. Tidak memperbarui SBOM: SBOM basi membuat triase meleset.
3. Tanpa kebijakan enforcement: tanpa gate di CI/CD, kontrol hanya jadi dokumentasi.
4. Fokus tools, lupa proses: keberhasilan lebih ditentukan tata kelola dan kepemilikan lintas tim.

Referensi

• CISA — Software Bill of Materials (SBOM): https://www.cisa.gov/sbom
• SLSA Specification v1.0 (Security Levels): https://slsa.dev/spec/v1.0/levels
• NIST SP 800-218 (SSDF): https://csrc.nist.gov/pubs/sp/800/218/final

Dengan pendekatan bertahap, organisasi tidak perlu menunggu “sempurna” untuk mulai. Mulai dari visibilitas (SBOM), lanjut ke integritas build (SLSA), lalu kencangkan respons insiden berbasis data.