2026 年 ML-DSA 程式碼簽名怎麼接入 CI/CD？

流水線已能產生簽章，部署端卻無法驗證，或團隊還不確定金鑰該放在哪裡？

先在隔離流水線驗證 ML-DSA 的金鑰管理、簽署與驗簽鏈路，再確認軟體產物的消費端相容；通過後才分階段推廣，不能把演算法已標準化當成整個工具鏈都已支援。

這篇適合負責軟體產物簽名的 DevSecOps 工程師，用來梳理流水線檢查步驟。
維護發布基礎設施的工程師，可據此盤點簽署端與驗簽端的依賴。
制定後量子密碼遷移計畫的安全負責人，可用文中的條件定義試點範圍與回退邊界。

先定義 ML-DSA CI/CD 程式碼簽名要保護的對象

先寫清楚你要簽的是建置產物、更新套件，還是另一種交付檔案；再畫出建置、簽署、發布與下載後驗證各由哪個系統負責。若簽署端和消費端對「被簽署的內容」理解不同，即使簽章驗證通過，也未必能證明實際部署的就是經審核的產物。

ML-DSA 已納入 NIST FIPS 204，但標準定義的是演算法，不會替你確認特定 CI/CD 平台、密碼庫、套件格式或舊版用戶端是否支援。把這幾層分開核對，才不會把某個函式庫已提供介面，誤當成整條發布路徑都已就緒。

FIPS 204 列出的三種參數集為 ML-DSA-44、ML-DSA-65 和 ML-DSA-87；對應的簽章大小分別是 2,420、3,309 和 4,627 位元組，數值可在NIST 標準文件的參數集規格核對。這些是簽章本體的大小，不等同於完整封裝、憑證或發布檔案的增加量；你應以實際格式檢查最終產物和傳輸流程。

準備階段：先把金鑰生命週期與信任邊界寫下來

不要從一段網路上抄來的通用命令開始。金鑰如何產生、放在哪裡、誰能呼叫簽署、何時輪替，以及疑似外洩時如何吊銷，都要依你選用的密碼庫與金鑰管理產品官方文件落實；不同產品的介面與存取模型可能不同，沒有文件依據就不要假設操作方式相同。

簽署權限最好與一般建置權限分開審視：能修改原始碼或建置設定的人，是否也能直接取得私鑰？發布工作是否能在未經審核時呼叫簽署？這些問題沒有通用答案，但必須由你在信任邊界圖中明確標示。也要確認簽署身分如何識別、審計紀錄由誰保存，以及金鑰停用後哪些產物仍需驗證。

若流水線使用受控密鑰功能，依照該類 CI/CD 平台的密鑰管理文件核對權限範圍、工作流程觸發條件與日誌處理方式。關鍵要求是：私鑰不能以一般文字寫進流水線設定、原始碼或公開日誌；只把字串遮罩起來，也不能取代限制呼叫權限與保護金鑰來源。

準備完成前，逐項確認：

• [ ] 簽署對象與產物範圍已寫清楚，包含摘要涵蓋哪些內容。
• [ ] 簽署端、發布端和消費端的責任與信任關係已標示。
• [ ] 金鑰產生、儲存、授權、輪替、吊銷流程有對應官方文件。
• [ ] 日誌、稽核紀錄與金鑰存取權限經過檢查。
• [ ] 已記錄密碼庫、簽章格式和驗簽工具的版本與支援依據。

接入階段：讓簽署結果能追溯到建置與產物

簽署步驟不能只回報「成功」。你要讓簽章與建置身分、產物摘要及發布稽核紀錄互相對得上，讓驗簽者能判斷「哪個來源、哪次建置、哪個產物」受保護。若要附帶建置來源資訊，可參考軟體供應鏈來源資料規格所描述的來源證明概念；它與 ML-DSA 簽章不是同一層功能，不能以其中一項取代另一項。

接入時，可按以下順序操作：

• 先建立隔離工作流程：選擇不會直接影響正式發布的測試產物，限制觸發條件與可呼叫簽署的工作身分。
• 再鎖定待簽內容：產生產物摘要，確認後續封裝或上傳不會替換被簽署的位元組。
• 加入簽署與紀錄步驟：記錄建置來源、摘要、簽署身分及簽署結果；密鑰材料不得輸出至一般日誌。
• 核對失敗處理：簽署失敗、摘要不符或稽核紀錄無法寫入時，應停止發布，而不是略過簽章檢查繼續執行。
• 保留可供驗證的交付資料：確認發布端把產物、簽章及必要的驗證資訊一併交付，消費端取得的內容與流水線簽署的內容一致。

若使用封裝格式來承載簽章與相關資料，需依格式文件核對其簽署範圍和解析行為；例如可參考DSSE 格式的專案說明。格式支援仍須由你實際使用的工具版本確認，不能因某種格式存在，就推定所有儲存庫或部署端都能讀取。

驗證階段：分別測簽署端、產物與消費端

驗證不應停在簽署程式回傳成功。你要在接近真實發布的路徑上測試合法產物、內容遭修改的產物，以及錯誤公鑰或錯誤簽章等情況，並確認每種結果都符合預期。尤其要測試部署端使用的驗簽工具和實際交付格式；開發機上的函式庫能驗證，不代表正式環境也能解析同一份簽章。

可先依所選密碼庫的 ML-DSA 簽章介面文件確認函式庫提供哪些介面，再對照實際使用的版本與建置方式。文件列出介面，不等同於你的作業系統映像、套件來源或下游工具已包含該功能；這些仍須在部署環境逐一核實。

特別留意幾種容易漏掉的邊界：驗簽端收到的是原始產物還是重新封裝過的檔案、金鑰識別資訊能否正確取得、格式解析失敗是否會被誤判為驗證成功，以及驗證結果是否真正阻止後續安裝。把負向測試結果留在發布稽核紀錄中，日後才能分辨是簽章錯誤、格式不相容，還是消費端設定有問題。

試點推廣：按條件決定啟用或回退

先挑選非關鍵產物試點，觀察舊版客戶端、儲存庫與發布系統的實際行為。NIST NCCoE 的後量子密碼遷移資料可協助你建立盤點與測試思路；遷移仍要依自身依賴與消費端逐項確認，不應從通用指南推斷某個工具版本已支援 ML-DSA。

決策條件：通過才擴大，否則回退

• 若簽署金鑰有明確保管者、限制呼叫權限，且稽核紀錄可追溯，才進入試點；否則先補齊金鑰治理。
• 若產物摘要、簽章封裝與驗簽端對同一份內容有一致定義，且負向測試能阻止錯誤產物部署，才擴大範圍；否則保持隔離。
• 若舊版客戶端已測試，並能支援新簽章或依既定方式並行驗證，才逐步切換；否則保留舊驗簽能力，不要撤除原流程。
• 若簽署失敗會停止發布，且回退流程不會繞過驗簽檢查，才允許試點進入更重要的發布路徑；否則暫停推廣並修正控制措施。

推廣前也要演練金鑰疑似外洩、驗簽服務不可用和舊端不相容等情況。回退應是恢復已知可運作的驗簽路徑或停止發布，而不是忽略錯誤、先部署再補驗證。若你正在盤點遷移工作，可延伸閱讀NIST 的後量子遷移測試指南，並將密碼庫、產物格式和消費端相容性分列追蹤。

FAQ：簽署標準化後，流水線還要驗證什麼？

ML-DSA 可用於軟體產物簽名嗎？

可以納入方案評估，但要把「演算法標準」和「整條交付鏈可用」分開判斷。先確認實作採用 FIPS 204 定義的 ML-DSA，再核對金鑰管理方式、簽章格式與消費端支援；若產物下載後沒有可靠驗簽路徑，簽署端成功也不足以保護部署流程。

CI/CD 流水線如何測試 ML-DSA 簽署與驗簽？

使用隔離產物走完建置、摘要、簽署、發布與消費端驗證，並記錄建置身分和簽署結果。測試不能只有成功案例：還要確認被修改的產物、錯誤公鑰及格式解析失敗都會被拒絕，且錯誤會阻止發布或部署，而非只寫入警告日誌。

切換後舊版客戶端仍能驗證簽章嗎？

不能預設可以。舊客戶端是否能驗證，取決於實際函式庫、簽章封裝和金鑰分發方式；要在部署環境測試，而不是只確認建置端有新演算法。若舊端尚未支援，應先保留舊驗簽路徑，或明確安排可驗證的並行轉換方式。

ML-DSA 程式碼簽名試點要檢查哪些回退條件？

預先決定簽署或驗簽失敗時是否停止發布、舊客戶端不相容時如何恢復既有驗簽流程，以及金鑰疑似外洩時如何停用與替換。還要確認回退不會變成略過簽章驗證，並保留產物、摘要和建置紀錄，讓團隊能查明問題來自金鑰、格式或消費端。

如果目前用共用建置主機或各自維護的本機環境做測試，常見限制是權限邊界不易分離、環境差異難以重現，且測試資源會和日常建置互相干擾；但需要長期固定負載或實體介面的團隊，未必適合租用環境。若你只需要建立短期、隔離的 Apple 平台建置測試環境，可先評估 ZavCloud 的 Mac 租用方案，並自行核對所選密碼庫與工具版本；租用環境不代表已預先支援 ML-DSA，也不能代替正式的相容性驗證。若要先確認服務交付與使用支援細節，可查看 ZavCloud 的協助中心，再判斷是否適合作為隔離測試環境。