Petunjuk dan ruang lingkup
Perusahaan Anda membangun ribuan citra kontainer setiap hari dari GitHub Actions dan self-hosted runner. Rancang layanan yang menghasilkan dan memverifikasi provenansi build yang dapat dilacak untuk setiap citra, yang hanya mengizinkan deployment jika kebijakan organisasi terpenuhi. Cakup model data, penerbitan (issuance), verifikasi, trust root, rotasi kunci, runner yang terkompromikan, deployment offline, rollback, dan observabilitas.
Panduan perekrutan keamanan rantai pasok publik menggunakan petunjuk desain sistem yang realistis: menghasilkan provenansi yang dapat diverifikasi untuk setiap citra kontainer di ribuan layanan dan runner campuran. SLSA memisahkan pembuatan, pendistribusian, dan verifikasi provenansi; Sigstore mendokumentasikan pemeriksaan identitas, penerbit, tanda tangan, dan digest artefak. Masalahnya adalah rantai kepercayaan dengan kebijakan operasional, bukan sekadar kolom tanda tangan pada catatan registri.
Apa yang sedang diuji oleh pewawancara
- Apakah Anda membedakan digest artefak, klaim provenansi, tanda tangan, log transparansi, dan kebijakan admisi.
- Apakah sumber, dependensi, konfigurasi build, dan runner yang tidak tepercaya muncul dalam model ancaman.
- Apakah klaim terikat pada artefak yang tidak dapat diubah (immutable) daripada tag yang dapat diubah (mutable) atau teks yang tidak terkait.
- Apakah kegagalan verifikasi, rotasi kunci, pencabutan, mode offline, dan rollback memiliki semantik yang eksplisit.
- Apakah Anda memperkirakan biaya penulisan, kueri, cache, retensi, dan audit serta mengekspos versi kebijakan.
Klarifikasi yang perlu ditanyakan terlebih dahulu
- Apakah tujuannya adalah pencegahan deployment atau bukti audit? Asumsikan admisi adalah gerbang ketat (hard gate) dan bukti audit disimpan secara terpisah.
- Apakah artefak hanya berupa kontainer? Mulailah dengan citra OCI dan sediakan titik ekstensi untuk biner dan paket.
- Apakah semua builder online? Asumsikan lingkungan yang dibatasi atau offline memerlukan root dan bundel yang dimuat sebelumnya (preloaded).
- Apakah identitas terikat pada seseorang, repositori, alur kerja (workflow), atau builder? Asumsikan identitas alur kerja dan builder terkelola, bukan sekadar alamat email.
- Berapa lama bukti harus disimpan? Tanyakan durasi kepatuhan dan audit sebelum menentukan ukuran penyimpanan dan indeks.
Jawaban 30 detik
Saya akan memisahkan empat batasan: sebuah builder mengeluarkan provenansi yang berisi revisi sumber, dependensi, parameter, dan identitas builder; penerbit mengikat klaim ke digest artefak yang tidak dapat diubah dan mencatatnya dalam log transparansi; pemverifikasi memeriksa rantai tanda tangan, identitas, digest, versi kebijakan, dan jendela waktu; pengontrol admisi mengembalikan allow, quarantine, atau deny. Sumber, dependensi, dan runner adalah input yang tidak tepercaya, sehingga eksekusi CI yang berhasil bukanlah bukti tersendiri. Versi kebijakan dan alasan kegagalan dapat dilacak, sementara lingkungan offline menggunakan root yang disematkan (pinned) dan bundel dengan masa berlaku terbatas (bounded-age).
Pembahasan mendalam langkah demi langkah
Langkah 1: Memetakan batasan kepercayaan dan ancaman
Buat daftar kontrol sumber, resolusi dependensi, konfigurasi build, runner, registri, penerbit, dan pengontrol deployment. Penyerang dapat mengubah dependensi, mencuri kredensial runner, memindahkan tag, memalsukan klaim, atau memutar ulang bukti lama (replay). Klaim yang harus dibuktikan adalah builder tepercaya mana yang menghasilkan digest apa dari input mana; provenansi tidak membuktikan bahwa kode bebas dari kerentanan.
Langkah 2: Menentukan provenansi dan pengikatan artefak
Sertakan revisi sumber, identitas builder, titik masuk, dependensi yang dikunci, parameter, digest langkah, waktu build, dan digest keluaran. Digest adalah kunci otorisasi; tag hanyalah alias penemuan (discovery). Catat versi skema dalam klaim, tanda tangan, dan keputusan sehingga arti bidang tidak dapat berubah secara diam-diam.
artifact_digest -> provenance_digest -> signature -> log_entry
policy_version + identity + builder + time_window -> admission_decisionLangkah 3: Merancang penerbitan dan transparansi
Builder mengirimkan klaim. Penerbit memvalidasi identitas alur kerja dan bentuk klaim, lalu menandatangani atau mengembalikan bundel yang dapat diverifikasi. Muatan (payload) yang ditandatangani harus mencakup digest artefak dan klaim penting. Log transparansi membantu mendeteksi penerbitan anomali tetapi tidak menggantikan kebijakan deployment. Penulisan bervolume tinggi dapat masuk ke penyimpanan yang tidak dapat diubah terlebih dahulu, dengan indeks asinkron berdasarkan digest, repositori, dan identitas.
Langkah 4: Menerapkan verifikasi deployment
Pemverifikasi menyelesaikan digest yang tidak dapat diubah, memeriksa rantai, trust root, identitas sertifikat, penerbit, integritas klaim, dan bukti log, lalu menerapkan kebijakan. Contoh aturan hanya mengizinkan build cabang utama dari runner terkelola dengan pemeriksaan dependensi terkini. Kembalikan allow, quarantine, atau deny beserta versi kebijakan dan kode alasan, bukan sekadar Boolean.
Langkah 5: Menangani kunci, identitas, dan runner yang terkompromikan
Pilih identitas alur kerja berumur pendek atau kunci terkelola dengan audiens dan izin penerbitan yang dibatasi. Rotasi tidak boleh membatalkan setiap artefak historis; pertahankan root lama untuk jendela validitas dan pencabutannya. Jika runner terkompromikan, cabut identitasnya, bekukan alur kerja yang terpengaruh, tandai klaim terkait, dan blokir admisi baru. Verifikasi ulang atau lakukan rollback artefak yang telah di-deploy berdasarkan risiko lingkungan.
Langkah 6: Mencakup replay, rollback, dan verifikasi offline
Klaim mencakup waktu build, versi, dan jendela kebijakan; tolak bukti yang kedaluwarsa atau tidak cocok dengan digest. Rollback tetap memeriksa apakah digest lama memenuhi kebijakan saat ini atau kebijakan yang kompatibel secara eksplisit. Lingkungan offline memuat root, snapshot pencabutan, dan bundel sebelumnya serta mencatat usia snapshot; snapshot yang kedaluwarsa mengisolasi deployment daripada berpura-pura bahwa verifikasi terkini telah terjadi.
Langkah 7: Menentukan ukuran kapasitas, retensi, dan mode kegagalan
Perkirakan volume artefak, ukuran klaim rata-rata, penulisan tanda tangan, QPS verifikasi, dan lonjakan deployment. Simpan klaim di penyimpanan tidak dapat diubah yang murah dan digest terbaru di indeks cepat (hot index). Jika layanan penerbitan mati, hentikan atau karantina artefak baru. Jika verifikasi mati, produksi gagal secara tertutup (fail-closed); lingkungan berisiko rendah dapat menggunakan jendela cache singkat yang disetujui sebelumnya dengan catatan pengecualian eksplisit.
Langkah 8: Menambahkan observabilitas dan migrasi
Catat digest, versi kebijakan, versi trust-root, kode alasan, dan latensi tanpa menyimpan kode sumber atau rahasia yang tidak perlu. Pantau cakupan provenansi, kegagalan tanda tangan, anomali identitas, penolakan kebijakan, cache hit, keterlambatan log, dan runner yang dicabut. Lakukan shadow-test pada peningkatan kebijakan sebelum peluncuran bertahap; setiap penolakan harus dapat diputar ulang dan dijelaskan.
Contoh jawaban berkualitas tinggi
Saya akan membagi sistem menjadi bukti build, penerbitan dan transparansi, verifikasi deployment, serta kebijakan admisi. Builder menghasilkan provenansi yang mengikat revisi sumber, dependensi, parameter, identitas builder, dan digest keluaran. Penerbit memverifikasi identitas alur kerja, mengikat tanda tangan ke digest yang tidak dapat diubah, dan mencatat peristiwa tersebut. Sebelum deployment, pemverifikasi memeriksa rantai, identitas sertifikat, penerbit, integritas klaim, trust root, jendela waktu, dan versi kebijakan, lalu mengembalikan allow, quarantine, atau deny yang dapat dijelaskan. Tag tidak pernah memberikan otorisasi. Identitas berumur pendek, runner terkelola, rotasi kunci, dan pencabutan mengatasi risiko kredensial; lingkungan offline menggunakan root dengan usia terbatas, snapshot pencabutan, dan bundel. Klaim berada di penyimpanan tidak dapat diubah dengan indeks digest. Kegagalan menggunakan fail-closed, karantina, atau cache terbatas berdasarkan lingkungan, dengan bukti kebijakan dan keputusan yang lengkap.
Kesalahan umum
- Hanya menandatangani tag citra yang dapat diubah (mutable).
- Memverifikasi validitas tanda tangan matematis tanpa pemeriksaan identitas, penerbit, atau klaim.
- Menggabungkan SBOM, provenansi, tanda tangan, dan pemindaian kerentanan ke dalam satu bidang.
- Mempercayai setiap CI runner dan mengabaikan radius dampak pencabutan (blast radius).
- Merotasi kunci dengan membatalkan semua riwayat atau menerima identitas yang dicabut selamanya.
- Fail-open setiap kali pemverifikasi tidak tersedia.
- Hanya menyimpan status lulus/gagal tanpa versi kebijakan, kode alasan, atau bukti yang dapat diputar ulang.
Pertanyaan lanjutan dan jawaban
Bagaimana Anda dapat membuktikan bahwa builder tidak berbohong dalam klaimnya?
Provenansi membuktikan apa yang ditegaskan oleh proses build tepercaya, bukan bahwa setiap langkah jujur. Kurangi asumsi dengan builder yang terisolasi, hak istimewa paling rendah (least privilege), build yang dapat direproduksi atau dibandingkan, log independen, dan batasan kebijakan. Artefak berisiko tinggi dapat memerlukan peninjauan pihak kedua atau atestasi tambahan.
Bagaimana jika registri terkompromikan?
Deploy berdasarkan digest dan verifikasi tanda tangan; mengubah tag atau metadata registri tidak mengubah digest yang ditandatangani. Simpan bukti dan bundel di penyimpanan independen yang tidak dapat diubah. Bekukan rilis baru, bandingkan entri log dan digest, cabut identitas yang terpengaruh, dan verifikasi ulang lingkungan yang telah di-deploy setelah sebuah insiden.
Bagaimana Anda mendukung beberapa builder dan vendor?
Gunakan satu skema klaim dan lapisan pemetaan identitas untuk GitHub Actions, self-hosted runner, dan builder vendor. Adaptor menormalisasi klaim; satu pemverifikasi tetap memeriksa digest, identitas, waktu, dan kebijakan. Vendor tidak boleh mendapatkan aturan bypass terpisah.
Tim mengatakan verifikasi memperlambat rilis. Apa trade-off yang Anda ambil?
Ukur latensi verifikasi, cache hit, dan alasan kegagalan terlebih dahulu. Optimalkan indeks dan pembacaan paralel tanpa menurunkan batas kepercayaan. Tawarkan cache singkat yang dapat diaudit untuk lingkungan berisiko rendah, pertahankan verifikasi ketat dalam produksi, dan gunakan mode bayangan (shadow mode) untuk membedakan cacat nyata dari kesalahan kebijakan. Setiap pengecualian memerlukan pemilik, masa kedaluwarsa, dan pembersihan otomatis.