Day19 掃的是模型本身，這篇要問：你部署的到底是不是那個被掃過的版本

前面幾篇的防線，都建立在一個隱含假設上：你部署到生產環境的模型/容器映像，就是你測試過、掃描過、審核過的那一個版本。但如果供應鏈這一環沒有控制好，這個假設隨時可能被打破——一個被竄改過的容器映像、一個沒有經過安全審查就被直接部署的模型版本，都可能繞過前面所有的努力。Binary Authorization 要解決的正是這個問題。

核心概念：部署前的簽章驗證

Binary Authorization 是一種部署時期（deploy-time）的控制機制：只有經過指定簽章者（attestor）驗證通過的容器映像，才允許被部署到 GKE 或其他支援的運算環境。簽章的產生通常綁定在 CI/CD pipeline 的特定階段——例如「已通過漏洞掃描」「已通過安全審查」「已經過核准的建置流程產出」——每完成一個階段就附加一個對應的證明（attestation）。

對 AI 供應鏈的具體應用

把這個機制套用到 AI 模型部署場景：

• 只允許部署經過 Day19 garak 掃描並且結果符合門檻的模型容器映像
• 只允許部署來自核准的 Model Registry、而非任意來源下載的模型檔案
• 微調（fine-tuned）過的模型，要求記錄清楚的訓練資料來源與版本，作為簽章附加資訊的一部分

這樣一來，「這個模型有沒有經過安全審查」不再只是流程上的口頭承諾，而是變成一個部署當下會被強制檢查、無法繞過的技術控制點。

跟前面邊界防線的關係

Day13 的 VPC Service Controls 管的是「資料能不能跨邊界」，Binary Authorization 管的是「未經驗證的東西能不能被部署進來」——兩者合在一起，形成「進不去、出不來、也裝不進來路不明的東西」的完整邊界防線。

待實測提醒：Binary Authorization 目前支援的運算環境範圍（GKE、Cloud Run 等）與簽章流程的具體設定方式會持續擴充，發布前請對照 Binary Authorization 官方文件 確認目前支援範圍是否涵蓋你實際使用的部署環境。

這篇的檢查清單

• [ ] 模型/容器映像部署前是否有強制的簽章驗證機制，而非僅依賴人工流程承諾？
• [ ] 簽章附加資訊是否涵蓋「已通過安全掃描」這個關鍵階段？
• [ ] 微調模型的訓練資料來源是否有清楚記錄並納入驗證流程？