Temu Duga Reka Bentuk Sistem: Bagaimanakah anda membina perkhidmatan asal-usul (provenance) rantaian bekalan perisian yang boleh disahkan?

Gesaan dan skop

Syarikat anda membina beribu-ribu imej kontena setiap hari daripada GitHub Actions dan pelari dihoskan sendiri (self-hosted runners). Reka bentuk perkhidmatan yang menghasilkan dan mengesahkan asal-usul binaan yang boleh dikesan untuk setiap imej, membenarkan pelaksanaan hanya apabila dasar organisasi dipatuhi. Rangkumi model data, pengeluaran, pengesahan, punca kepercayaan (trust roots), giliran kunci, pelari yang terjejas, pelaksanaan luar talian, pengunduran (rollback) dan kebolehlihatan (observability).

Panduan pengambilan pekerja keselamatan rantaian bekalan awam menggunakan gesaan reka bentuk sistem yang realistik: menghasilkan asal-usul yang boleh disahkan untuk setiap imej kontena merentas beribu-ribu perkhidmatan dan pelari bercampur. SLSA memisahkan penghasilan, pengedaran dan pengesahan asal-usul; Sigstore mendokumentasikan semakan identiti, pengeluar, tandatangan dan ringkasan artifak. Masalah ini ialah rantaian kepercayaan dengan dasar operasi, bukan sekadar medan tandatangan pada rekod registri.

Perkara yang sedang diuji oleh penemu duga

• Sama ada anda membezakan ringkasan artifak, tuntutan asal-usul, tandatangan, log ketelusan dan dasar kemasukan.
• Sama ada sumber yang tidak dipercayai, kebergantungan, konfigurasi binaan dan pelari muncul dalam model ancaman.
• Sama ada tuntutan mengikat kepada artifak yang tidak boleh diubah dan bukannya tag yang boleh diubah atau teks yang tidak berkaitan.
• Sama ada kegagalan pengesahan, giliran kunci, pembatalan, mod luar talian dan pengunduran mempunyai semantik yang eksplisit.
• Sama ada anda menganggarkan kos penulisan, pertanyaan, cache, pengekalan dan audit serta mendedahkan versi dasar.

Penjelasan untuk ditanya terlebih dahulu

• Adakah matlamatnya pencegahan pelaksanaan atau bukti audit? Andaikan kemasukan ialah pintu kawalan ketat (hard gate) dan bukti audit disimpan secara berasingan.
• Adakah artifak hanya kontena? Mulakan dengan imej OCI dan tinggalkan titik sambungan untuk binari dan pakej.
• Adakah semua pembina dalam talian? Andaikan persekitaran terhad atau luar talian memerlukan punca dan berkas (bundles) yang dipramuat.
• Adakah identiti terikat kepada seseorang, repositori, aliran kerja atau pembina? Andaikan identiti aliran kerja dan pembina terurus, bukan alamat e-mel sahaja.
• Berapa lamakah bukti mesti dikekalkan? Tanya tentang tempoh pematuhan dan audit sebelum menentukan saiz storan dan indeks.

Jawapan 30 saat

Saya akan memisahkan empat sempadan: pembina mengeluarkan asal-usul yang mengandungi semakan sumber, kebergantungan, parameter dan identiti pembina; pengeluar mengikat tuntutan kepada ringkasan artifak yang tidak boleh diubah dan merekodkannya dalam log ketelusan; pengesah menyemak rantaian tandatangan, identiti, ringkasan, versi dasar dan tetingkap masa; pengawal kemasukan mengembalikan allow, quarantine atau deny. Sumber, kebergantungan dan pelari adalah input yang tidak dipercayai, jadi larian CI yang berjaya bukanlah bukti dengan sendirinya. Versi dasar dan sebab kegagalan boleh dikesan, manakala persekitaran luar talian menggunakan punca yang dipinkan dan berkas dengan had umur.

Panduan mendalam langkah demi langkah

Langkah 1: Petakan sempadan kepercayaan dan ancaman

Senaraikan kawalan sumber, penyelesaian kebergantungan, konfigurasi binaan, pelari, registri, pengeluar dan pengawal pelaksanaan. Penyerang mungkin mengubah kebergantungan, mencuri kelayakan pelari, mengalihkan tag, memalsukan tuntutan atau memainkan semula bukti lama (replay). Tuntutan yang perlu dibuktikan ialah pembina dipercayai yang mana menghasilkan ringkasan yang mana daripada input yang mana; asal-usul tidak membuktikan bahawa kod bebas daripada kerentanan.

Langkah 2: Tentukan asal-usul dan pengikatan artifak

Sertakan semakan sumber, identiti pembina, titik masuk, kebergantungan terkunci, parameter, ringkasan langkah, masa binaan dan ringkasan output. Ringkasan ialah kunci kebenaran; tag hanyalah alias penemuan. Rekod versi skema dalam tuntutan, tandatangan dan keputusan supaya maksud medan tidak boleh berubah secara senyap.

artifact_digest -> provenance_digest -> signature -> log_entry
policy_version + identity + builder + time_window -> admission_decision

Langkah 3: Reka bentuk pengeluaran dan ketelusan

Pembina menyerahkan tuntutan. Pengeluar mengesahkan identiti aliran kerja dan bentuk tuntutan, kemudian menandatangani atau mengembalikan berkas yang boleh disahkan. Muatan yang ditandatangani mesti meliputi ringkasan artifak dan tuntutan kritikal. Log ketelusan membantu mengesan pengeluaran anomali tetapi tidak menggantikan dasar pelaksanaan. Penulisan volum tinggi boleh mendarat dalam storan tidak boleh diubah terlebih dahulu, dengan indeks tak segerak mengikut ringkasan, repositori dan identiti.

Langkah 4: Laksanakan pengesahan pelaksanaan

Pengesah menyelesaikan ringkasan yang tidak boleh diubah, menyemak rantaian, punca kepercayaan, identiti sijil, pengeluar, integriti tuntutan dan bukti log, kemudian menggunakan dasar. Contoh peraturan hanya membenarkan binaan cawangan utama daripada pelari terurus dengan semakan kebergantungan semasa. Kembalikan allow, quarantine atau deny dengan versi dasar dan kod sebab, bukan Boolean kosong.

Langkah 5: Kendalikan kunci, identiti dan kompromi pelari

Utamakan identiti aliran kerja jangka pendek atau kunci terurus dengan khalayak dan kebenaran pengeluaran yang terhad. Giliran tidak boleh membatalkan setiap artifak sejarah; kekalkan punca lama untuk tetingkap kesahan dan pembatalannya. Jika pelari terjejas, batalkan identitinya, bekukan aliran kerja yang terjejas, tandakan tuntutan berkaitan dan sekat kemasukan baharu. Sahkan semula atau undurkan artifak yang dilaksanakan mengikut risiko persekitaran.

Langkah 6: Rangkumi ulang tayang, pengunduran dan pengesahan luar talian

Tuntutan termasuk masa binaan, versi dan tetingkap dasar; tolak bukti yang tamat tempoh atau ringkasan tidak sepadan. Pengunduran masih menyemak bahawa ringkasan lama memenuhi dasar semasa atau dasar yang serasi secara eksplisit. Persekitaran luar talian mempramuat punca, snapshot pembatalan dan berkas serta merekodkan umur snapshot; snapshot yang tamat tempoh mengasingkan pelaksanaan dan bukannya berpura-pura pengesahan semasa telah berlaku.

Langkah 7: Tentukan saiz kapasiti, pengekalan dan mod kegagalan

Anggarkan volum artifak, purata saiz tuntutan, penulisan tandatangan, QPS pengesahan dan lonjakan pelaksanaan. Simpan tuntutan dalam storan tidak boleh diubah yang murah dan ringkasan terkini dalam indeks pantas (hot index). Jika pengeluaran terhenti, hentikan atau kuarantin artifak baharu. Jika pengesahan terhenti, pengeluaran gagal-tutup (fail-closed); persekitaran berisiko rendah mungkin menggunakan tetingkap cache yang singkat dan dipraluluskan dengan rekod pengecualian yang jelas.

Langkah 8: Tambah kebolehlihatan dan migrasi

Rekod ringkasan, versi dasar, versi punca kepercayaan, kod sebab dan kependaman tanpa menyimpan sumber atau rahsia yang tidak perlu. Pantau liputan asal-usul, kegagalan tandatangan, anomali identiti, penafian dasar, capaian cache, kelewatan log dan pelari yang dibatalkan. Uji bayang (shadow-test) peningkatan dasar sebelum pelancaran berperingkat; setiap penafian harus boleh diulang tayang dan dijelaskan.

Contoh jawapan berkualiti tinggi

Saya akan membahagikan sistem kepada bukti binaan, pengeluaran dan ketelusan, pengesahan pelaksanaan dan dasar kemasukan. Pembina menghasilkan asal-usul yang mengikat semakan sumber, kebergantungan, parameter, identiti pembina dan ringkasan output. Pengeluar mengesahkan identiti aliran kerja, mengikat tandatangan pada ringkasan yang tidak boleh diubah dan merekodkan peristiwa tersebut. Sebelum pelaksanaan, pengesah menyemak rantaian, identiti sijil, pengeluar, integriti tuntutan, punca kepercayaan, tetingkap masa dan versi dasar, kemudian mengembalikan allow, quarantine atau deny yang boleh dijelaskan. Tag tidak pernah memberi kebenaran. Identiti jangka pendek, pelari terurus, giliran kunci dan pembatalan menangani risiko kelayakan; persekitaran luar talian menggunakan punca terhad umur, snapshot pembatalan dan berkas. Tuntutan berada dalam storan tidak boleh diubah dengan indeks ringkasan. Kegagalan menggunakan fail-closed, kuarantin atau cache terhad mengikut persekitaran, dengan bukti dasar dan keputusan yang lengkap.

Kesilapan biasa

• Menandatangani tag imej yang boleh diubah sahaja.
• Mengesahkan kesahan tandatangan matematik tanpa semakan identiti, pengeluar atau tuntutan.
• Menggabungkan SBOM, asal-usul, tandatangan dan imbasan kerentanan ke dalam satu medan.
• Mempercayai setiap pelari CI dan mengabaikan radius impak (blast radius) pembatalan.
• Menggilirkan kunci dengan membatalkan semua sejarah atau menerima identiti yang dibatalkan selama-lamanya.
• Gagal-buka (fail-open) setiap kali pengesah tidak tersedia.
• Menyimpan lulus/gagal sahaja tanpa versi dasar, kod sebab atau bukti yang boleh diulang tayang.

Soalan susulan dan jawapan

Bagaimanakah anda boleh membuktikan bahawa pembina tidak menipu dalam tuntutannya?

Asal-usul membuktikan apa yang ditegaskan oleh proses binaan yang dipercayai, bukan bahawa setiap langkah adalah jujur. Kurangkan andaian dengan pembina terpencil, keistimewaan paling sedikit (least privilege), binaan yang boleh dihasilkan semula atau dibandingkan, log bebas dan kekangan dasar. Artifak berisiko tinggi boleh memerlukan semakan pihak kedua atau perakuan (attestations) tambahan.

Bagaimana jika registri terjejas?

Laksanakan mengikut ringkasan dan sahkan tandatangan; menukar tag atau metadata registri tidak mengubah ringkasan yang ditandatangani. Simpan bukti dan berkas dalam storan bebas yang tidak boleh diubah. Bekukan keluaran baharu, bandingkan entri log dan ringkasan, batalkan identiti yang terjejas dan sahkan semula persekitaran yang dilaksanakan selepas sesuatu insiden.

Bagaimanakah anda menyokong beberapa pembina dan vendor?

Gunakan satu skema tuntutan dan lapisan pemetaan identiti untuk GitHub Actions, pelari dihoskan sendiri dan pembina vendor. Penyesuai menormalkan tuntutan; satu pengesah masih menyemak ringkasan, identiti, masa dan dasar. Vendor tidak sepatutnya mendapat peraturan pintasan yang berasingan.

Pasukan mengatakan pengesahan memperlahankan keluaran. Apakah pertukaran (trade-off) yang anda buat?

Ukur kependaman pengesahan, capaian cache dan sebab kegagalan terlebih dahulu. Optimumkan indeks dan bacaan selari tanpa merendahkan sempadan kepercayaan. Tawarkan cache pendek yang boleh diaudit kepada persekitaran berisiko rendah, kekalkan pengesahan yang kukuh dalam pengeluaran dan gunakan mod bayang (shadow mode) untuk membezakan kecacatan sebenar daripada kesilapan dasar. Setiap pengecualian memerlukan pemilik, tarikh luput dan pembersihan automatik.