【懶人包】 5 點看懂本篇重點：
- AWS對外說明如何將ML-DSA抗量子數位簽章演算法導入軟體供應鏈，整合至建置與部署流程。
- 關鍵服務包括AWS KMS、AWS Private CA及IAM Roles Anywhere，分別負責金鑰管理、憑證信任鏈與身分驗證。
- 保護範圍涵蓋執行檔、容器映像檔及軟體物料清單（SBOM）的簽章與驗證。
- 簽章私密金鑰保存在KMS的硬體安全模組中，並可在部署前驗證簽章、阻擋未通過驗證的容器映像檔。
- 目標是因應量子電腦未來可能破解傳統數位簽章的風險，但通過驗簽不代表軟體本身沒有漏洞。
雲端服務業者AWS對外說明如何將模組格基式數位簽章演算法（ML-DSA）導入軟體供應鏈，透過AWS KMS、AWS Private CA及IAM Roles Anywhere等服務，將抗量子數位簽章整合至軟體建置與部署流程。這套做法涵蓋執行檔、容器映像檔及軟體物料清單（SBOM）的簽章與驗證，以因應未來量子電腦可能破解傳統數位簽章演算法的風險。
量子電腦的發展，讓現有的密碼學面臨長期威脅。傳統數位簽章演算法在量子電腦成熟後可能被破解，這意味著現在簽署的軟體，未來可能失去可信度。ML-DSA是被認為能抵抗量子電腦攻擊的簽章演算法之一，提前導入等於為軟體供應鏈買一份長期保險。
企業若要在軟體建置流程採用ML-DSA，除了建立簽章金鑰，也需要透過憑證確認簽章者身分。AWS在實作範例中，利用AWS Private CA建立採用ML-DSA的憑證信任鏈，透過AWS KMS建立及管理ML-DSA簽章金鑰，並由AWS Private CA核發對應的程式碼簽章憑證，形成完整的可信任體系。
在金鑰保護方面，簽章私密金鑰保存在AWS KMS的硬體安全模組（HSM）中，不必交由軟體建置系統保管。這是一個重要的安全設計：私密金鑰從不離開硬體保護，即使建置系統遭到入侵，攻擊者也無法竊取金鑰來偽造簽章，大幅降低了供應鏈攻擊的風險。
對於部署在AWS以外環境的建置代理程式，企業也可透過IAM Roles Anywhere搭配ML-DSA憑證進行身分驗證。建置代理程式通過驗證並取得AWS存取權限後，即可呼叫AWS KMS對軟體成品及SBOM進行簽章，將抗量子簽章納入既有的持續整合與持續交付（CI/CD）流程，不需要大幅改動現有工作流程。
完成軟體簽章後，企業也可在部署前檢查簽章是否有效，確認軟體內容是否遭到竄改，以及簽章者的憑證是否可信任。這道驗證關卡確保只有經過合法簽署的軟體才能進入正式環境，任何在傳輸或儲存過程中被修改過的檔案都會被攔下。
AWS並示範在容器部署流程加入准入控制，阻止未通過ML-DSA簽章驗證的容器映像檔部署。這意味著即使攻擊者設法將惡意映像檔送入系統，只要沒有合法簽章，就無法實際運行，為容器化環境多加了一道防線。
針對SBOM（軟體物料清單），則透過in-toto Statement將SBOM與對應軟體成品的摘要值記錄在簽署資料中，再以ML-DSA進行簽章。這讓驗證端可以確認SBOM內容是否遭到修改，以及SBOM是否對應準備部署的軟體成品，確保物料清單本身的可信度。
不過，AWS也提醒，通過數位簽章驗證不代表軟體本身沒有漏洞或惡意程式碼。簽章只能證明軟體確實來自聲稱的簽署者、且內容未被竄改，無法保證程式碼品質。如果簽署者本身的開發流程有問題，或是合法簽署的軟體含有漏洞，簽章機制並無法發現。
這套做法的意義在於超前部署。量子電腦真正能威脅現有密碼學可能還需要數年，但軟體供應鏈的信任基礎需要提前建立。等到威脅迫在眉睫才開始遷移，成本與風險都會大得多。AWS的示範為有意導入的企業提供了具體的參考架構。
對台灣的科技產業而言，軟體供應鏈安全日益受到重視。無論是半導體、資通訊還是新創團隊，只要涉及軟體交付，都值得關注抗量子密碼學的進展。雖然全面導入仍需時間，但及早理解相關技術與服務，有助於在未來平滑過渡。
