SLSA Provenance: Cara Memverifikasi Asal Build Software

Perangkat lunak modern dibangun melalui rangkaian proses yang melibatkan kode sumber, dependensi, sistem build, akun layanan, dan repositori artefak. Jika sebuah paket dirusak di tengah rantai pasok, hasil akhirnya bisa terlihat normal meskipun tidak lagi mewakili kode yang dimaksud pengembang. SLSA provenance membantu menjawab pertanyaan penting: bagaimana artefak ini dibuat, dari sumber mana, dan melalui proses apa?

Provenance bukan jaminan bahwa aplikasi bebas kerentanan. Fungsinya adalah menyediakan bukti yang dapat diperiksa mengenai asal dan proses pembuatan artefak. Ketika digabungkan dengan kontrol akses, build terisolasi, penandatanganan, dan verifikasi otomatis, bukti tersebut membantu organisasi mengurangi risiko manipulasi rantai pasok perangkat lunak.

Apa Itu SLSA Provenance?

SLSA, singkatan dari Supply-chain Levels for Software Artifacts, adalah kerangka kerja untuk meningkatkan keamanan proses produksi perangkat lunak. Provenance merupakan pernyataan terstruktur tentang bagaimana artefak dibuat. Isinya dapat mencakup identitas builder, sumber yang digunakan, parameter build, serta hubungan antara masukan dan keluaran.

Informasi ini membantu konsumen artefak membedakan paket yang benar-benar dihasilkan oleh pipeline tepercaya dari paket yang asal-usulnya tidak jelas. Format dan persyaratan tepatnya bergantung pada versi spesifikasi SLSA dan sistem build yang digunakan. Karena itu, penerapan harus merujuk dokumentasi resmi, bukan sekadar menambahkan berkas metadata tanpa validasi.

Mengapa Asal Build Perlu Diverifikasi?

Keamanan aplikasi tidak hanya bergantung pada kode yang ditulis pengembang. Dependensi yang disusupi, token CI/CD yang bocor, runner build yang dikendalikan pihak lain, atau artefak yang diganti setelah proses build dapat memengaruhi paket akhir. Pemeriksaan kode sumber saja belum tentu membuktikan bahwa file yang diunduh pengguna berasal dari kode tersebut.

Provenance memberikan konteks tambahan untuk pemeriksaan. Tim dapat memverifikasi apakah artefak berasal dari repositori yang diharapkan, dibuat oleh builder yang diizinkan, dan menggunakan parameter yang sesuai kebijakan. Bukti ini juga berguna saat audit, investigasi insiden, dan penelusuran versi yang terdampak.

Komponen Penting dalam Provenance

• Subjek atau artefak: keluaran build yang diidentifikasi, biasanya melalui digest kriptografis seperti hash.
• Sumber: repositori, revisi kode, atau bahan masukan yang dipakai untuk menghasilkan artefak.
• Builder: sistem atau layanan yang menjalankan proses build dan identitas yang dapat diverifikasi.
• Parameter proses: informasi relevan mengenai konfigurasi atau langkah build yang membantu penilaian kebijakan.
• Pernyataan yang terlindungi: metadata provenance perlu dilindungi dari perubahan tidak sah, misalnya dengan tanda tangan atau mekanisme kepercayaan yang didukung ekosistem terkait.

Hash membantu mengikat pernyataan dengan artefak tertentu, tetapi hash saja tidak membuktikan bahwa sumber atau builder tepercaya. Verifikator tetap harus memeriksa identitas penandatangan, asal bukti, serta apakah nilai yang dinyatakan sesuai dengan kebijakan organisasi.

Alur Implementasi di Pipeline CI/CD

1. Tentukan artefak yang perlu dilacak. Mulai dari paket rilis, image container, pustaka, atau binary yang didistribusikan ke pengguna maupun lingkungan produksi.
2. Perkuat lingkungan build. Batasi hak akses runner, pisahkan kredensial, lindungi token, dan gunakan konfigurasi pipeline yang dapat ditinjau. Provenance tidak akan banyak membantu jika builder sendiri mudah dimanipulasi.
3. Hasilkan provenance dari proses tepercaya. Gunakan fitur platform build atau tooling yang mendukung format dan persyaratan SLSA yang relevan. Hindari membuat klaim manual yang tidak didukung bukti proses sebenarnya.
4. Simpan dan distribusikan bukti bersama artefak. Pastikan provenance dapat ditemukan oleh sistem verifikasi dan tetap terkait dengan digest artefak yang tepat.
5. Verifikasi sebelum rilis atau deployment. Periksa identitas builder, repositori dan revisi sumber, digest, serta persyaratan kebijakan. Tolak artefak bila bukti tidak tersedia atau pemeriksaan penting gagal.
6. Catat hasil dan tangani pengecualian. Simpan log verifikasi, tentukan siapa yang dapat menyetujui pengecualian, dan pastikan keputusan tersebut dapat diaudit.

Kesalahan yang Sering Terjadi

Salah satu kekeliruan adalah menganggap keberadaan file provenance otomatis berarti artefak aman. Penyerang dapat membuat metadata palsu jika proses penerbitan bukti tidak tepercaya. Kesalahan lain adalah hanya memeriksa apakah tanda tangan ada, tanpa memvalidasi siapa yang menandatangani dan apakah identitas tersebut memang diizinkan.

Organisasi juga perlu menghindari kebijakan yang terlalu longgar, misalnya menerima semua builder dari sebuah platform tanpa membatasi proyek atau alur kerja yang diperbolehkan. Sebaliknya, aturan yang terlalu ketat tanpa mekanisme pembaruan dapat menghambat rilis saat pipeline berubah. Uji kebijakan terhadap build normal, build gagal, pergantian kunci, dan pemulihan insiden.

Kesimpulan

Dengan memeriksa provenance, digest artefak, identitas builder, dan kebijakan sumber secara bersama-sama, tim dapat membuat keputusan rilis yang lebih dapat dipertanggungjawabkan. Jadikan verifikasi sebagai gerbang otomatis dalam CI/CD dan tinjau ulang kebijakan saat pipeline, kredensial, atau sistem build berubah.