題干與適用場景
平台可以為二進位檔與容器映像產生建置來源證明，消費者使用 CLI 驗證證明與產物摘要是否匹配。安全團隊要求生產部署必須驗證；開發團隊擔心舊流水線、外部建置器與離線環境無法立即接入。請提出產品決策與發布方案，明確 Artifact Attestation 解決及無法解決的風險、使用者分層、預設策略、遷移路徑、指標與回退。核心考察產品取捨與發布治理，因此歸為 product。
面試官考察點
第一，能否把「證明存在」與「證明可信」區分：來源聲明還需要驗證簽章、產物摘要、工作流身分與策略上下文。
第二，能否識別不同使用者的風險與能力，避免用一個強制開關覆蓋個人專案、企業生產與受監管環境。
第三，能否設計漸進式遷移：觀測、警告、選擇性阻斷、預設阻斷，並保留可稽核豁免。
第四，能否用安全、開發者體驗、覆蓋率與業務結果衡量價值，而非只看產生證明數量。
第五，能否說明威脅模型邊界，例如受損建置環境、錯誤策略、映像重打包與離線驗證。
回答前需要澄清的問題
- 目標客戶是開源專案、一般 SaaS，還是受監管生產平台？
- 目前建置來自 GitHub Actions、第三方 CI、開發者本地，還是多種來源？
- 生產部署是否能讀取線上證明，是否存在離線或隔離網路？
- 失敗時允許臨時豁免嗎，誰批准，多久過期？
- 證明驗證由平台、叢集 admission，還是客戶自己的流水線負責？
- 主要目標是供應鏈稽核、阻止未授權產物，還是降低事件回應時間？
30 秒回答框架
「我先把 attestation 定義為可驗證的建置來源訊號，而非自動保證原始碼安全。按風險與遷移能力把客戶分為生產關鍵、一般生產、開發與外部建置四層；先提供觀測與警告，再對高風險生產預設阻斷，支援帶原因與期限的豁免。指標同時看有效驗證覆蓋率、誤阻斷率、部署延遲、豁免率與供應鏈事件處置時間。對受損建置環境、重打包與離線驗證單獨設計威脅模型，灰度期間保留快速回退與稽核。」
分步驟深入解答
第一步：定義使用者問題與信任邊界
Artifact Attestation 將產物摘要與建置來源綁定，協助消費者判斷產物由哪個工作流、提交與建置環境產生。它不能證明原始碼沒有漏洞，也不能自動修復遭攻陷的建置器。產品文案與策略必須分開表達 provenance、簽章驗證、漏洞掃描與部署授權。
第二步：建立使用者分層
把生產關鍵服務、一般生產服務、開發預覽與外部貢獻者分開。生產關鍵服務通常需要強驗證與短豁免；開發環境更重視回饋速度；外部建置可能只能提交證明包或使用受信任重建流程。分層決定預設策略、支援成本與遷移順序。
第三步：設計驗證閉環
產生端在建置完成後寫入證明，消費端按產物摘要驗證，並檢查工作流儲存庫、提交、分支、建置器與簽發者是否符合策略。驗證結果應回傳可操作原因，例如缺少證明、摘要不匹配、來源不在允許集合或證明過期，而非只有布林值。
第四步：規劃漸進式策略
先以唯讀方式統計覆蓋率與失敗原因；第二階段對非生產環境發出警告；第三階段對選定生產服務阻斷；第四階段擴大到預設阻斷。每階段設定退出條件，包括誤阻斷率、驗證延遲、舊流水線遷移率與支援工單量。豁免需要負責人、原因、範圍與過期時間。
第五步：處理多種建置來源
GitHub Actions 可以直接產生證明，但第三方 CI、外部建置器與離線建置需要匯入證明或採用受信任簽發流程。產品要提供清晰的證據格式、摘要綁定與驗證命令，避免使用者誤以為上傳 JSON 檔案就等於可信證明。
第六步：定義指標與護欄
核心指標包括生產產物有效驗證覆蓋率、未授權產物阻斷率、誤阻斷率、部署延遲 p95、遷移完成時間與豁免到期率。護欄包括建置失敗率、回滾耗時、支援工單、離線客戶阻斷數與安全事件中的證明可用率。證明產生數量只能作為使用量指標，不能代表安全效果。
第七步：準備灰度與回退
按組織、儲存庫或服務逐步開啟，保留策略版本與每次決策日誌。若驗證服務不可用，應區分 fail-closed 與受控 fail-open：生產關鍵路徑可短時阻斷並提供人工審批，低風險環境可記錄後繼續。回退只撤銷強制策略，不刪除既有證明與稽核紀錄。
高品質示範回答
「我會把產品目標定為阻止來源不符合策略的產物進入生產，而不是宣稱證明能保證程式碼安全。先按風險與建置能力分層，針對 GitHub Actions、第三方 CI、離線建置分別提供證據路徑。發布採用觀測、警告、選擇性阻斷、預設阻斷四階段，只有在誤阻斷率、部署延遲與遷移率達標後擴大範圍。驗證結果要解釋缺少證明、摘要不匹配、來源不允許等原因；豁免必須有審批、期限與稽核。核心指標是有效驗證覆蓋率、未授權產物阻斷率、誤阻斷率與事件處置時間，並為驗證服務故障設計受控回退。」
常見錯誤
- 把證明數量當安全效果 → 可能產生大量無效或未驗證證明 → 衡量有效驗證與阻斷結果。
- 第一天全量強制 → 舊流水線與離線客戶同時被阻斷 → 採用分層灰度與遷移窗口。
- 只驗證簽章不看來源策略 → 任意受信任簽發者都可能通過 → 檢查工作流、提交、儲存庫與建置器。
- 把 provenance 當漏洞掃描 → 使用者誤解保護範圍 → 分開表達來源、漏洞與授權控制。
- 沒有可解釋失敗原因 → 開發者無法修復 → 回傳結構化原因與修復連結。
- 豁免永久有效 → 強制策略逐漸失效 → 限定範圍、審批人與過期時間。
- 忽略驗證服務故障 → 一次故障造成大面積發布中斷 → 定義 fail-closed、受控 fail-open 與回退。
- 只支援單一 CI → 多源建置使用者無法遷移 → 提供匯入、證明包與受信任簽發路徑。
追問及應對
追問一：證明能否證明程式碼沒有被篡改？
它能把產物摘要與聲明的建置來源綁定，讓消費者驗證兩者是否匹配；不能證明建置環境、依賴或原始碼絕對安全，需要結合權限、掃描與可重現建置。
追問二：為什麼不直接全量 fail-closed？
客戶能力、建置來源與網路條件不同。全量阻斷可能製造業務中斷並促使團隊關閉策略；先觀測與灰度可以用真實失敗資料校準規則。
追問三：如何衡量誤阻斷？
記錄每次阻斷的原因、服務、策略版本與後續人工批准；將確認的合法產物恢復率與總阻斷量結合，按客戶層級觀察，不把所有豁免都視為誤報。
追問四：離線客戶如何驗證？
允許下載證明包與必要信任根，在隔離環境本地驗證產物摘要與來源；產品要明確信任根更新、撤銷與證明過期處理。
追問五：如果建置器被攻陷怎麼辦？
證明只能說明聲明的來源，不能自動證明來源未被攻陷。應限制工作流權限、使用隔離建置器、輪換簽發身分，並將異常來源與策略變更納入監控。
追問六：如何避免豁免成為常態？
把豁免設為有期限的異常，顯示到期倒數與責任人，按團隊統計到期率與重複原因；持續修復遷移缺口，而非永久放寬規則。