SBOM Saja Nggak Cukup, Begini Cara Buktiin Siapa yang Merilis Artifact-mu

Kalau release pipeline-mu masih berhenti di SBOM, kamu baru tahu apa yang masuk ke package. Kamu belum bisa membuktikan siapa yang membangun dan mem-publish artifact itu. Di situlah CI/CD provenance jadi pembeda antara rapi di atas kertas dan benar-benar tahan terhadap tampering.

Buat platform engineer, tim DevSecOps, dan maintainer, masalah utamanya sederhana. Saat artifact sudah keluar ke registry, publik butuh bukti bahwa build memang lahir dari workflow yang sah, source yang benar, dan identitas publisher yang bisa diverifikasi. Kalau bukti itu lemah, attacker cukup menyusup ke pipeline atau token publish untuk merusak rantai distribusi software.

Apa yang sebenarnya diselesaikan oleh CI/CD provenance

Banyak tim fokus ke dependency list, CVE scan, atau SBOM. Itu penting. Namun, itu belum menjawab pertanyaan yang paling krusial saat insiden terjadi, artifact ini benar dibuat oleh pipeline resmi atau bukan?

CI/CD provenance menutup celah itu. Jadi, alih-alih hanya menyimpan metadata komponen, kamu juga punya jejak verifiable tentang build dan publish.

• Source, commit, repo, dan builder bisa ditelusuri.
• Identity publisher bisa diverifikasi, bukan sekadar dipercaya.
• Integrity artifact bisa dicek ulang sebelum dipakai di production.
• Auditability naik, sehingga incident response lebih cepat.

Empat lapisan yang bikin provenance benar-benar berguna

1. Trusted publishing, buang token jangka panjang

Kalau pipeline masih publish pakai API token statis yang disimpan lama, itu titik lemah klasik. Begitu token bocor, attacker bisa merilis paket palsu atas nama proyekmu. Karena itu, trusted publishing jauh lebih kuat, terutama lewat OIDC workload identity.

Model ini membuat registry percaya pada identitas workload dari CI, bukan pada secret panjang umur. GitHub Actions, misalnya, bisa mengeluarkan identity token singkat yang diverifikasi pihak registry. Hasilnya, blast radius turun.

2. Sigstore, tanda tangan tanpa drama key management lama

Banyak tim menunda signing karena capek mengelola private key, rotasi, escrow, dan distribusi public key. Di sinilah Sigstore menarik. Dengan Sigstore, kamu bisa pakai identitas OIDC untuk mendapatkan sertifikat ephemerial, lalu menandatangani artifact dan mencatatnya ke transparency log.

Artinya, verifikasi nggak lagi bergantung pada asumsi internal semata. Konsumen dapat mengecek signature, certificate chain, dan log entry. Buat ekosistem open source, ini perubahan besar karena trust pindah dari secret lokal ke identitas dan transparansi.

3. SLSA, kerangka kematangan, bukan sekadar checklist

SLSA membantu tim memetakan seberapa matang supply chain security mereka. Banyak orang mengira SLSA itu dokumen compliance. Padahal, nilai utamanya ada pada desain build yang sulit dimanipulasi, provenance yang bisa diverifikasi, dan kontrol builder yang lebih ketat.

Kalau disederhanakan, SLSA mendorong kamu bergerak dari build yang “pokoknya jalan” ke build yang reproducible, isolated, dan attestable. Jadi, saat artifact muncul, ada bukti yang menempel, bukan cerita lisan.

4. Artifact signing, verifikasi di sisi konsumen

Signing tanpa verification policy cuma jadi dekorasi. Karena itu, artifact signing harus dipasangkan dengan gate di sisi deploy, admission control, atau policy engine. Jadi, image, binary, atau package yang tidak punya signature valid langsung ditolak.

Ini poin yang sering dilewatkan. Banyak tim bangga karena sudah sign image. Namun, cluster atau runtime mereka tetap menerima artifact unsigned. Hasilnya, security terlihat maju, padahal enforcement nol.

Framework praktis, Identity, Build, Attest, Enforce

Kalau kamu butuh model implementasi yang gampang dibawa ke tim, pakai urutan ini, Identity, Build, Attest, Enforce.

• Identity, pastikan CI pakai OIDC, bukan secret publish statis.
• Build, jalankan build di runner yang terisolasi dan workflow yang ditinjau.
• Attest, hasilkan provenance dan signature untuk setiap artifact penting.
• Enforce, tolak artifact yang tidak lolos verifikasi di deploy path.

Bagian paling sering terlupakan justru tahap terakhir. Tim berhenti di attest. Padahal, tanpa enforce, attacker masih punya ruang lewat jalur distribusi alternatif, cache yang tercemar, atau manual push yang lolos review.

Kenapa SBOM saja belum cukup

SBOM memberi daftar isi. Provenance memberi bukti asal. Signature memberi bukti integritas. Ketiganya saling melengkapi, bukan saling menggantikan.

Ini ide yang sering bikin tim kaget, artifact dengan SBOM lengkap tetap bisa berbahaya kalau artifact itu dibangun oleh workflow yang salah atau dipublish oleh identitas yang dicuri. Jadi, fokus hanya ke inventory tanpa bukti builder itu setengah jalan.

Kalau kamu tertarik ke sisi inventory dan dependency risk, baca juga cara deteksi vulnerabilities sebelum kode-mu jadi SBOM. Lalu, untuk pondasi proses keamanan tim, lanjutkan ke panduan membangun infrastruktur DevSecOps.

Urutan implementasi paling masuk akal untuk tim sibuk

1. Aktifkan trusted publishing di registry yang mendukung OIDC.
2. Tambahkan signing dengan Sigstore pada artifact yang paling kritis dulu.
3. Generate provenance attestation di pipeline release, bukan hanya di branch biasa.
4. Pasang verification policy pada deploy atau admission layer.
5. Naikkan target kematangan mengacu ke SLSA secara bertahap.

Dengan urutan ini, kamu nggak perlu menunggu program transformasi besar. Kamu bisa mulai dari release path yang risikonya paling tinggi, lalu memperluas coverage setelah pola kerjanya matang.

Kesalahan yang paling sering bikin program ini gagal

• Masih bergantung pada token statis, sehingga publisher identity tetap rapuh.
• Signing tanpa policy, jadi artifact unsigned tetap lolos.
• Provenance dibuat opsional, akibatnya coverage bolong.
• Runner terlalu longgar, sehingga build environment mudah dicemari.
• Hanya fokus ke image container, padahal package, binary, dan release asset juga rawan.

FAQ

Apakah Sigstore menggantikan SBOM?

Tidak. Sigstore membantu tanda tangan dan verifikasi identitas artifact. SBOM tetap berguna untuk mengetahui komponen yang masuk ke build.

Apakah SLSA wajib level tinggi sejak awal?

Nggak perlu. Mulai dari kontrol yang paling berdampak, seperti OIDC trusted publishing, provenance, dan verification policy. Setelah itu, tingkatkan isolasi builder dan hardening pipeline.

Artifact signing paling berguna di mana?

Paling terasa saat dipadukan dengan enforcement. Misalnya, cluster hanya menerima image yang punya signature valid dan provenance yang sesuai workflow resmi.

Apakah maintainer proyek kecil juga perlu provenance?

Iya. Justru maintainer kecil sering jadi target karena automation dan secret management mereka biasanya lebih minim. Trusted publishing memberi peningkatan besar tanpa overhead sebesar PKI tradisional.

Intinya jelas. Kalau kamu ingin mengurangi risiko release yang disusupi, jangan berhenti di SBOM. Naikkan jaminan dengan CI/CD provenance, trusted publishing, dan artifact signing yang benar-benar diverifikasi.

Kalau kamu sedang merapikan pipeline atau ingin saya bahas implementasi per platform, tulis pertanyaanmu di komentar. Lalu, jangan lupa subscribe supaya update supply chain security berikutnya nggak lewat.