Pendahuluan
Serangan software supply chain telah menjadi ancaman siber paling mahal di dekade ini. Insiden seperti backdoor xz-utils (2024) yang hampir menyusup ke distribusi Linux utama membuktikan bahwa attacker tidak lagi menyerang kode Anda — mereka menyerang kode yang Anda gunakan.
Di 2026, keamanan rantai pasok bukan lagi opsional. Regulasi seperti US Executive Order 14028 dan EU Cyber Resilience Act mewajibkan produsen software menerbitkan SBOM dan membuktikan integritas artefak. Artikel ini membahas tiga pilarnya: SBOM, SLSA, dan Sigstore.
1. SBOM: Inventaris Setiap Komponen
Software Bill of Materials (SBOM) adalah daftar formal seluruh komponen — library, container image, tooling — yang menyusun sebuah aplikasi. Format dominan di 2026: SPDX (ISO/IEC 5962) dan CycloneDX.
SBOM menjawab pertanyaan kritis saat CVE baru rilis: "Apakah saya terdampak?" Tanpa SBOM, tim harus mengaudit manual ribuan dependency — dengan SBOM cukup jalankan scanner:
syft scan docker.io/library/nginx:alpine -o spdx-json > sbom.json
grype sbom.json --fail-on high2. SLSA: Level Kematangan Pipeline
Supply-chain Levels for Software Artifacts (SLSA) menilai seberapa aman proses build Anda, dari Level 0 hingga 4:
| Level | Makna | Persyaratan Kunci | |-------|-------|-------------------| | L0 | Tanpa jaminan | — | | L1 | Build terdokumentasi | Provenance dasar, no secret di log | | L2 | Build ter-host | Build service terpusat, provenance terautentikasi | | L3 | Build non-forgeable | Build terisolasi, tidak bisa dimodifikasi developer | | L4 | Build reproducible | Hermetic build, reproducible, provenance di-hash |
Target realistis untuk tim modern adalah SLSA Level 3: build di CI terpusat, artefak ditandatangani, dan provenance dihasilkan otomatis — bukan dari laptop developer yang bisa dikompromikan.
3. Sigstore: Code Signing Tanpa Ribet
Masalah klasik code signing adalah manajemen kunci privat — jika bocor, artefak bisa dipalsukan. Sigstore mengubah paradigma ini dengan keyless signing: kunci ephemeral per-build, identitas diverifikasi via OIDC (misal email@example.com), dan semua tanda tangan tercatat di transparency log (Rekor) yang bisa diaudit publik.
Sign tanpa menyimpan secret kunci
cosign sign --oidc-issuer https://token.actions.githubusercontent.com \
ghcr.io/org/app:v1.0.0
Verifikasi sebelum deploy
cosign verify --certificate-identity \
"https://github.com/org/app/.github/workflows/*" ghcr.io/org/app:v1.0.0Dengan cosign + OIDC, CI menandatangani artefak tanpa menyimpan kunci di mana pun — menghilangkan salah satu vektor serangan terbesar.
Praktik Nyata di Pipeline 2026
package-lock.json, go.sum, poetry.lock di-commit dan diverifikasi di CIid-token: write di GitHub Actions menggantikan PAT untuk publish artefakTantangan Baru 2026
AI-generated code membawa dimensi baru: model AI bisa menyarankan package lookalike berbahaya. Package squatting yang meniru nama library populer dengan variasi tipografis halus (lodash vs 1odash) meningkat tajam. Solusinya: verifikasi source dan publisher identity, bukan hanya nama package.
Kesimpulan
Supply chain security di 2026 bergerak dari best practice menjadi kewajiban regulasi dan tuntutan pasar. Dengan SBOM untuk visibilitas, SLSA sebagai roadmap keamanan build, dan Sigstore untuk integritas artefak, tim bisa membangun fondasi yang tahan serangan.
Mulai dari yang kecil: generate SBOM minggu ini, aktifkan dependabot, dan pindahkan satu workflow ke keyless signing. Semakin cepat dimulai, semakin murah.
---
Ditulis untuk blog pribadi — Ringga Septia Pribadi
