Perintah dan konteks
Sebuah platform dapat menghasilkan pernyataan asal-usul build (build-provenance) untuk biner dan image kontainer, sementara konsumen memverifikasi pernyataan tersebut terhadap digest artefak menggunakan CLI. Tim keamanan menginginkan deployment produksi memverifikasi setiap artefak; para pengembang khawatir bahwa pipeline lama, pembangun (builder) eksternal, dan jaringan luring (offline) tidak dapat langsung mengadopsinya. Usulkan keputusan produk dan rencana peluncuran, termasuk apa yang dibuktikan dan tidak dibuktikan oleh atestasi, segmentasi, pengaturan default, migrasi, metrik, dan rollback. Keterampilan intinya adalah tata kelola produk dan penalaran kompromi (trade-off), jadi ini adalah pertanyaan product.
Apa yang dievaluasi oleh pewawancara
Pertama, apakah Anda membedakan "sebuah pernyataan ada" dari "pernyataan tersebut tepercaya": verifikasi tetap membutuhkan tanda tangan, digest artefak, identitas workflow, dan konteks kebijakan.
Kedua, apakah Anda mensegmentasikan pengguna berdasarkan risiko dan kemampuan alih-alih menerapkan satu tombol wajib untuk proyek hobi, produksi perusahaan, dan lingkungan yang teregulasi.
Ketiga, apakah Anda merancang migrasi progresif dari observasi (observe) ke peringatan (warn), pemblokiran selektif, dan pemblokiran default dengan pengecualian yang dapat diaudit.
Keempat, apakah metrik mencakup keamanan, pengalaman pengembang, cakupan, dan hasil bisnis alih-alih sekadar jumlah pernyataan yang dihasilkan.
Kelima, apakah model ancaman mencakup builder yang disusupi, kebijakan yang salah, image yang dikemas ulang, dan verifikasi offline.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Apakah target pengguna adalah proyek sumber terbuka (open source), SaaS biasa, atau platform produksi yang teregulasi?
- Apakah build berasal dari GitHub Actions, CI pihak ketiga, mesin pengembang, atau beberapa sumber?
- Apakah produksi dapat membaca pernyataan online, atau harus mendukung jaringan offline dan terisolasi?
- Apakah pengecualian sementara diizinkan, siapa yang menyetujuinya, dan kapan kedaluwarsanya?
- Apakah verifikasi dilakukan oleh platform, admisi kluster, atau pipeline pelanggan?
- Apakah tujuannya adalah auditabilitas rantai pasok, memblokir artefak yang tidak sah, atau respons insiden yang lebih cepat?
Jawaban 30 detik
"Saya mendefinisikan atestasi sebagai sinyal asal build yang dapat diverifikasi, bukan jaminan otomatis bahwa kode sumber aman. Saya mensegmentasikan produksi kritis, produksi biasa, pengembangan, dan build eksternal berdasarkan risiko dan kemampuan migrasi. Saya memulai dengan observasi dan peringatan, lalu memblokir secara selektif, dan akhirnya menerapkan pemblokiran default pada produksi berisiko tinggi, dengan pengecualian berbatas lingkup dan waktu kedaluwarsa. Metrik mencakup cakupan verifikasi yang valid, pemblokiran artefak tidak sah, pemblokiran keliru (false blocks), latensi deployment, tingkat pengecualian, dan waktu respons insiden. Builder yang disusupi, pengemasan ulang, dan verifikasi offline mendapatkan model ancaman terpisah, sementara peluncuran bertahap (gray rollout) mempertahankan rollback yang cepat dan teraudit."
Solusi terperinci
Langkah 1: Tentukan masalah pengguna dan batas kepercayaan (trust boundary)
Atestasi artefak mengikat digest artefak ke klaim asal-usul build, membantu konsumen mengidentifikasi workflow, commit, dan builder yang memproduksinya. Ini tidak membuktikan bahwa sumber bebas dari kerentanan atau memperbaiki builder yang disusupi. Teks produk dan kebijakan harus memisahkan asal-usul (provenance), verifikasi tanda tangan, pemindaian, dan otorisasi deployment.
Langkah 2: Segmentasikan pengguna
Pisahkan layanan produksi kritis, produksi biasa, pratinjau pengembangan, dan kontributor eksternal. Produksi kritis membutuhkan verifikasi ketat dan pengecualian singkat; pengembangan memprioritaskan umpan balik yang cepat; build eksternal mungkin memerlukan bundle yang diunggah atau build ulang tepercaya. Segmentasi menentukan pengaturan default, biaya dukungan, dan urutan migrasi.
Langkah 3: Rancang loop verifikasi
Produsen menulis pernyataan setelah build. Konsumen memverifikasinya terhadap digest artefak dan memeriksa repositori, commit, branch, builder, dan penerbit terhadap kebijakan. Hasil harus menjelaskan alasan yang dapat ditindaklanjuti seperti pernyataan hilang, ketidakcocokan digest, sumber yang tidak diizinkan, atau kedaluwarsa, alih-alih hanya mengembalikan nilai boolean.
Langkah 4: Rencanakan kebijakan progresif
Pertama, ukur cakupan dan alasan kegagalan dalam mode baca-saja (read-only). Selanjutnya, berikan peringatan di non-produksi. Kemudian blokir layanan produksi yang dipilih, dan akhirnya perluas ke pemblokiran default. Setiap tahap membutuhkan kriteria keluar untuk pemblokiran keliru, latensi verifikasi, migrasi pipeline lama, dan volume dukungan. Pengecualian mencatat pemilik, alasan, cakupan, dan masa kedaluwarsa.
Langkah 5: Dukung berbagai asal build
GitHub Actions dapat menghasilkan pernyataan secara langsung, tetapi CI pihak ketiga, builder eksternal, dan build offline memerlukan bukti yang diimpor atau alur penerbit tepercaya. Produk harus mendokumentasikan format bukti, pengikatan digest, dan perintah verifikasi sehingga pengunggahan file JSON tidak disalahartikan sebagai pernyataan tepercaya.
Langkah 6: Tentukan metrik dan guardrail
Metrik utama adalah cakupan verifikasi produksi yang valid, tingkat pemblokiran artefak tidak sah, tingkat pemblokiran keliru, p95 latensi deployment, waktu migrasi, dan tingkat kedaluwarsa pengecualian. Guardrail mencakup tingkat kegagalan build, waktu rollback, tiket dukungan, pemblokiran pelanggan offline, dan ketersediaan pernyataan selama insiden keamanan. Jumlah pernyataan adalah metrik penggunaan, bukan hasil keamanan.
Langkah 7: Siapkan peluncuran bertahap dan rollback
Aktifkan berdasarkan organisasi, repositori, atau layanan sambil mempertahankan versi kebijakan dan log keputusan. Jika verifikasi tidak tersedia, bedakan fail-closed dari fail-open terkontrol: jalur kritis dapat memblokir secara singkat dengan persetujuan manual, sementara lingkungan berisiko rendah dapat mencatat log dan melanjutkan. Rollback menonaktifkan penegakan tanpa menghapus bukti atau catatan audit yang ada.
Contoh jawaban berkualitas tinggi
"Tujuan produk adalah mencegah artefak yang asalnya melanggar kebijakan mencapai produksi, bukan mengklaim bahwa asal-usul membuktikan kode itu aman. Saya mensegmentasikan pelanggan berdasarkan risiko dan kemampuan build, serta menyediakan jalur bukti untuk GitHub Actions, CI pihak ketiga, dan builder offline. Peluncuran bergerak melalui observasi, peringatan, pemblokiran selektif, dan pemblokiran default, berkembang hanya ketika pemblokiran keliru, latensi, dan tingkat migrasi memenuhi ambang batas. Verifikasi menjelaskan bukti yang hilang, ketidakcocokan digest, dan asal yang tidak diizinkan; pengecualian memerlukan persetujuan, kedaluwarsa, dan audit. Saya mengukur cakupan yang valid, pemblokiran tidak sah, pemblokiran keliru, dan waktu respons insiden, dengan fallback terkontrol untuk pemadaman verifikator."
Kesalahan umum
- Memperlakukan jumlah pernyataan sebagai keamanan → banyak pernyataan mungkin tidak valid atau belum diverifikasi → ukur hasil verifikasi yang valid dan pemblokiran.
- Penegakan wajib pada hari pertama → pengguna lama dan offline terblokir → gunakan segmentasi, peluncuran bertahap, dan jendela migrasi.
- Hanya memeriksa tanda tangan → penerbit tepercaya mana pun dapat lolos → periksa kebijakan workflow, commit, repositori, dan builder.
- Menyebut asal-usul (provenance) sebagai pemindaian kerentanan → pengguna salah memahami perlindungannya → pisahkan klaim asal, kerentanan, dan otorisasi.
- Tidak memberikan alasan kegagalan → pengembang tidak dapat memperbaiki masalah → kembalikan alasan terstruktur dan tautan remediasi.
- Pengecualian permanen → penegakan perlahan-lahan melemah secara diam-diam → batasi cakupan, setujui, dan beri kedaluwarsa.
- Mengabaikan pemadaman verifikator → satu pemadaman menghentikan rilis secara luas → definisikan fail-closed, fail-open terkontrol, dan rollback.
- Hanya mendukung satu CI → pelanggan dengan multi-sumber tidak dapat bermigrasi → sediakan jalur impor, bundle, dan penerbit tepercaya.
Pertanyaan lanjutan
Pertanyaan lanjutan 1: Apakah atestasi membuktikan bahwa kode tidak dirusak?
Atestasi mengikat digest artefak ke klaim asal build sehingga konsumen dapat memverifikasi kecocokannya. Ini tidak membuktikan bahwa builder, dependensi, atau sumber benar-benar aman; izin, pemindaian, dan reproducible build tetap diperlukan.
Pertanyaan lanjutan 2: Mengapa tidak langsung menerapkan fail-closed untuk semua orang?
Pelanggan memiliki kemampuan build, sumber bukti, dan kondisi jaringan yang berbeda. Pemblokiran universal dapat menyebabkan pemadaman dan mendorong tim untuk menonaktifkan kebijakan; observasi dan peluncuran bertahap mengkalibrasi aturan dengan kegagalan nyata.
Pertanyaan lanjutan 3: Bagaimana Anda mengukur pemblokiran keliru (false blocks)?
Catat alasan, layanan, versi kebijakan, dan persetujuan manual berikutnya untuk setiap pemblokiran. Gabungkan pemulihan sah yang dikonfirmasi dengan total pemblokiran dan analisis berdasarkan tingkatan (tier) pelanggan; jangan mengklasifikasikan setiap pengecualian sebagai false positive.
Pertanyaan lanjutan 4: Bagaimana pelanggan offline melakukan verifikasi?
Biarkan mereka mengunduh bundle bukti dan trust root yang diperlukan, lalu memverifikasi digest dan asal secara lokal. Dokumentasikan pembaruan trust root, pencabutan (revocation), dan perilaku kedaluwarsa untuk lingkungan yang terisolasi.
Pertanyaan lanjutan 5: Bagaimana jika builder disusupi?
Pernyataan tersebut menggambarkan asal yang diklaim; ini tidak membuktikan bahwa asal tersebut tidak disusupi. Batasi izin workflow, isolasi builder, rotasi identitas penerbit, serta pantau asal yang anomali dan perubahan kebijakan.
Pertanyaan lanjutan 6: Bagaimana Anda mencegah pengecualian menjadi permanen?
Perlakukan setiap pengecualian sebagai anomali yang akan kedaluwarsa dengan hitung mundur dan pemilik yang jelas. Lacak kedaluwarsa dan alasan yang berulang berdasarkan tim, lalu perbaiki celah migrasi alih-alih melemahkan kebijakan secara permanen.