GitHub Actions iOS 建置產物如何驗真？2026 企業清單

GitHub 官方流程要求產生 artifact attestation 的工作流程明確授予 attestations: write 與 id-token: write 兩項權限（GitHub 官方使用指南）。因此，正式發布不能只看工作流程是否成功：先把來源證明綁定最終交付檔，再核對倉庫、工作流程、提交與 Apple 簽章；來源證明不代表程式安全，也不能取代簽章驗證。本週先抽查一個正式版本，確認整條證據鏈能否回溯。

企業安全負責人：需要訂定來源核驗規則與拒收條件。
平台工程負責人：需要確保 GitHub Actions 與 Mac 建置流程能產生可複核的證據。
iOS 發布負責人：需要確認 Xcode 歸檔、匯出、簽章與最終交付檔彼此對應。

驗真對象應是送交測試者、客戶或應用程式發行流程的實際檔案，而不是任意一個建置中間產物。測試版與正式版也要分開定義：測試流程通過，不代表正式發布所需的審批、簽署和證據留存已完成。

發布負責人先建立交付物清單，至少記錄檔案識別資訊、版本或建置標記、產物摘要、來源證明位置、簽章檢查結果，以及發布核准紀錄。接著界定每一份證據對應哪個檔案；若工作流程先產生歸檔檔案，之後再匯出、簽署或重新封裝，就必須判斷來源證明實際涵蓋的是哪一個版本。

GitHub 說明 artifact attestations 用來提供產物的來源資訊，並可用來驗證來源脈絡；它不是安全審查或發布許可的替代品。企業應將證明視為供應鏈證據的一環，而非對交付內容的品質保證（GitHub 對 artifact attestations 的說明）。

平台團隊負責讓證明由可信的建置流程產生，並確保它與實際交付檔案一致。GitHub 官方操作指南列出建立 attestation 所需的工作流程權限；設定時應採用最小權限，不要為了讓工作流程通過而擴大其他工作或整個倉庫的權限（權限與產生步驟）。

建議在發布工作流程中檢查以下事項：

• [ ] 正式建置使用經審核的倉庫與工作流程，不從個人測試流程直接搬用產物。
• [ ] 權限只在需要產生證明的工作範圍內授予，其他工作維持較低權限。
• [ ] 產生證明的對象是最後要交付的檔案，並能以檔案摘要辨識。
• [ ] 若簽署、匯出或封裝會改變檔案內容，後續重新產生或核對證明，不把舊證明視為新檔案的證明。
• [ ] 工作流程記錄、證明與發布產物保存在可供稽核的地方，並能由發布版本回查。

GitHub 亦提供以 API 讀取 attestations 的方式，其存取權限須依官方 API 文件設定；若企業以自動化服務彙整證據，應另外審查該服務的憑證與讀取範圍（GitHub attestations API 權限說明）。

GitHub Actions iOS 建置產物驗真，關鍵不只是確認「有證明」，而是判斷證明中的來源是否符合企業政策。安全負責人應把允許的倉庫、工作流程身分、提交及觸發脈絡寫成可執行規則，避免只憑工作流程名稱或成功狀態放行。

GitHub 文件說明可透過驗證工具檢查 attestation，並限制預期的倉庫來源；可重用工作流程也可用於加強建置證明的可信度（驗證與來源檢查指南、可重用工作流程安全建議）。企業應把這些能力轉成自己的放行條件，而非假設預設驗證結果符合內部政策。

建議至少設定以下拒收情況：倉庫不是核准來源、工作流程不在允許清單、提交無法對應到審核紀錄、觸發方式不符合正式發布規則、產物摘要不一致，或證明缺失且無法補足。若只有證明服務暫時無法使用，應依風險政策進入人工升級或暫緩流程，不要把「無法驗證」當成「驗證通過」。

來源證明與 Apple 代碼簽署回答的是不同問題。前者協助確認產物由哪個倉庫、提交和工作流程產生；後者則用來核對 Apple 發布流程中的簽署與交付狀態。兩者必須各自成立，不能以 GitHub 證明代替簽署檢查，也不能因檔案有有效簽章就推定來源符合團隊政策。

Apple 的 Xcode 發行文件涵蓋測試與發布分發流程；涉及已註冊裝置的分發時，Apple 亦說明歸檔及匯出步驟。發布團隊應依實際選用的分發方式保存相應記錄，並檢查簽署後檔案是否就是最終交付版本（Xcode 測試與發布分發文件、註冊裝置分發、歸檔與匯出文件）。

Apple 的程式碼簽署說明也指出，簽署格式與驗證是獨立的技術檢查；因此，發布紀錄應保留實際驗證結果，而不只保存簽署設定或憑證名稱（Apple 簽署格式與驗證說明）。

注意：若來源證明綁定的是簽署前的歸檔檔案，而交付的是之後匯出或簽署的檔案，兩者可能不是同一個位元組序列。請對最終交付檔重新建立或驗證相應證據，並保留從歸檔到發布檔的轉換紀錄。

GitHub Actions 產生的來源證明能確認什麼？
可用來核對建置產物的來源脈絡，例如倉庫、提交與相關工作流程資訊。驗證時須對照企業允許的來源條件；它不能證明程式碼沒有弱點，也不能代替安全測試與發布審批。

如何確認 iOS 發布包對應正確的倉庫與提交？
從最終交付檔的摘要找到相應證明，再檢查倉庫、工作流程與提交是否符合核准清單。將結果連同版本識別資訊及審批紀錄保存；來源不符或證據無法回溯時，先拒絕放行。

來源證明能取代 Apple 簽章驗證嗎？
不能。來源證明說明產物的建置來源，Apple 簽章驗證則檢查簽署與交付檔狀態。兩者應分開執行，並確認來源證明涵蓋完成匯出與簽署後的實際交付檔。

私有倉庫使用 artifact attestations 有什麼方案條件？
GitHub 官方文件指出，私有或內部倉庫使用 artifact attestations 需要 GitHub Enterprise Cloud。導入前請依倉庫可見性和組織方案核對官方條件，並確認工作流程已取得所需權限。

一次發布抽查應能從交付檔回到產物摘要、來源證明、工作流程執行紀錄、倉庫和提交，再連到 Apple 簽署檢查及審批紀錄。若鏈條在簽署後的檔案、人工匯出步驟或審批責任人處中斷，該發布流程便尚未具備完整的可追溯性。

發布證據清單

• [ ] 最終交付檔及可識別該檔案的摘要。
• [ ] 與該交付檔相符的 GitHub artifact attestation。
• [ ] 倉庫、提交、工作流程身分與觸發脈絡的核驗結果。
• [ ] Xcode 歸檔、匯出與 Apple 簽章檢查紀錄。
• [ ] 審核者、發布核准結論，以及例外處理紀錄。
• [ ] 發生失敗或證據不符時的拒收、升級與復原紀錄。

Mac CI 節點方案比較

Mac CI 生產准入條件

• 若節點身分、工作流程權限及簽署憑證已分離，且正式發布可回溯到核准提交，則可進入受控放量。
• 若來源證明可驗證，但最終檔案的簽章或匯出紀錄不完整，則先限期補齊，不以來源證明單獨准入。
• 若節點共用憑證、執行來源未受控，或故障後無法還原發布證據，則暫緩正式發布，直到責任邊界與證據保存方式完成整改。

採購 Mac 並非唯一選項：自購設備會帶來資本支出、折舊與維護責任；讓開發者各自建置容易形成環境差異；一般雲端虛擬機也不能直接取代需要 macOS 與 Xcode 的 Mac 節點。若負載長期穩定、需要實體周邊或內部控制硬體，企業自購可能較合適；若正在驗證發布流程或需要彈性取得遠端 Mac，則可把 JEXCLOUD 的遠端 Mac 服務 納入評估，並依自身權限、簽署隔離與審計要求核對 遠端 Mac 方案資訊。即使採用租用節點，來源證明、Apple 簽章檢查與發布核准仍應由企業自己的流程負責。