症狀：CI 顯示有 attestation，卻無法確認它屬於哪個發布檔案。
最快解法：以官方文件說明的產物摘要為核對基準，逐項驗證來源身分與實際交付檔案；來源證明不代表程式碼安全、測試通過或 Apple 簽章與公證有效。GitHub 說明指出，attestation 會將證明與產物摘要關聯。
誰適合看：企業 CI 負責人，需要為 iOS 建置產物建立來源核驗流程。
供應鏈安全負責人，需要掌握證明的能力邊界。
發布工程師，需要把來源證明接上測試、簽章與歸檔驗收。
GitHub Artifact Attestations iOS CI 驗收指標
驗收的目標不是確認「有沒有證明」，而是確認證明能否連回你實際要發布的檔案，以及組織是否信任該建置路徑。建議將下列項目分開記錄，避免一個綠色狀態被誤讀成全套安全保證。
- 來源身分：證明指向的倉庫、提交與工作流程，是否符合本次發布所核准的來源。
- 產物摘要：attestation 綁定的檔案摘要，是否與交付端拿到的檔案一致。
- 工作流程身分：工作流程檔案、所在倉庫與觸發方式，是否屬於組織批准的建置路徑。
- 倉庫資格：目前倉庫類型、組織方案與設定，是否符合 GitHub 當下的生成條件。
- 其他放行證據：測試結果、Apple 簽章與發布核准是否各自完成並留存。
GitHub 將 Artifact Attestations 定位為建立產物來源證明、並驗證所消費軟體的機制。生成方法、驗證行為及倉庫條件，應分別依照官方概念說明與目前的功能資格說明核對。不要把某個倉庫成功執行一次，推論為所有企業倉庫都符合資格。
如何驗證構建產物來源？
使用 GitHub 官方驗證工具檢查候選檔案，並明確指定預期倉庫。下列命令中的路徑和倉庫名稱須換成實際值：
gh attestation verify path/to/app.ipa --repo OWNER/REPO
gh attestation verify 是驗證流程的一部分，不是發布核准的同義詞。檢查結果時，將工具回報的來源與團隊核准的倉庫、提交及工作流程逐項比對。若驗證未通過、找不到可用證明，或輸出來源與預期不符，應依內部規則阻擋放行或進入人工複核，而不是直接忽略警告。命令與驗證方法以官方驗證指南為準。
用產物摘要鎖定實際交付檔案
Attestation 的驗收對象必須明確：它證明的是哪一個檔案，而不是籠統地證明「這次建置」。iOS 流程可能先產生封存檔，再經匯出、簽署或重新封裝成要交付的檔案。每個轉換階段都要記下輸入與輸出，確認證明是在目標發布檔案上生成，還是只對應較早階段的產物。
例如，建置流程產生檔案 A、交付流程再輸出檔案 B。若 attestation 綁定的是 A，你不能把它當成 B 的來源證明；必須為 B 建立相應證據，或將 A 到 B 的轉換與驗收程序另外記錄。Apple 對應用程式封存與匯出流程的說明，亦提醒發布交付檔案與前一階段的建置結果需分辨處理。
在產物產生與發布交接點，對同一個檔案計算摘要並比對驗證結果。若驗證在建置輸出上完成、發布時卻使用另一個匯出檔案，就不能以「同一工作流程」取代檔案層級的核對。
判斷工作流程與倉庫是否可信
通過驗證只能說明證明與檢查結果符合相應驗證條件，不會替你決定某個工作流程是否值得信任。這項政策要由組織自行建立：列出允許的倉庫、工作流程檔案與觸發來源，再確認發布任務實際使用的路徑符合清單。
GitHub Actions 使用可重用工作流程時，還要確認呼叫端與被呼叫工作流程的身分是否符合團隊政策。可依官方可重用工作流程驗證說明檢查相應資訊；不要只因工作流程名稱相似，就視為同一個可信建置流程。
另外，生成、證明存取與消費端驗證是不同環節。先按官方資格說明確認目標倉庫能否使用，再分別測試證明是否生成、發布端能否取得，以及驗證端能否針對正確檔案完成核驗。若企業政策要求離線處理，應另依離線驗證指南測試所需資料與流程；不要假定一般線上驗證成功就代表離線流程也已備妥。
區分來源證明、測試與 Apple 簽章
| 驗收選項 | 能回答的問題 | 不能單獨證明的事 |
|---|---|---|
| Artifact Attestations | 產物的證明是否能連回符合驗證條件的來源與建置身分？ | 程式碼是否安全、測試是否通過、交付檔案是否與證明綁定對應 |
| CI 測試與檢查紀錄 | 指定提交與流程執行了哪些測試，結果如何？ | 產物來源是否符合組織信任政策、Apple 簽章是否有效 |
| Apple 簽章與發布檢查 | 應用程式的簽章與發布設定是否符合預定分發流程？ | 建置工作流程是否屬於組織批准的供應鏈來源 |
Apple 說明其程式碼簽署服務用於建立與驗證程式碼簽章。這和 GitHub 的來源證明是不同驗收面向，應各自保存結果。公證也不能與 iOS 簽章混為一談；Apple 的公證說明針對 macOS 軟體發行流程，不能拿公證結果替代 iOS 應用程式的簽章或發布檢查。
注意：若透過 API 取得或消費 attestation，需按端點文件核對回傳與驗證要求。GitHub REST API 的證明文件也提醒，API 取得資料不等於已完成本地信任判斷。
將驗收接入真實 iOS 發布流程
不要只用測試倉庫或無關檔案證明流程「可用」。選一項實際發布任務，從提交到交付檔案完整走查，並留下每個階段的處理紀錄：
- 確認目標：寫下本次發布的倉庫、提交、預期工作流程，以及真正要交付的檔案。
- 確認資格：按 GitHub 官方文件核對倉庫條件及目前可用功能，並在目標倉庫實際測試生成步驟。
- 生成證明：確認建置工作流程將證明綁定到預定產物，不要把中間檔案誤當成發布檔案。
- 核對來源：使用
gh attestation verify檢查候選檔案，並將結果與核准的倉庫、提交及工作流程身分比對。 - 核對檔案：在交付端檢查檔案摘要是否匹配。遇到匯出或重新封裝，就回到該階段重新確認證明對應關係。
- 分別驗收門禁：保存測試結果、簽章檢查與發布核准紀錄，不以來源證明代替其他門禁。
- 測試失敗分支：演練證明缺失、摘要不匹配或來源未核准時的阻擋與複核責任，並記錄誰有權放行例外。
若 Mac 承載 Xcode 建置或簽署工作，還要獨立驗收該建置環境的存取權、憑證處理與工作隔離。Attestation 不是 Mac 環境准入證明，也不會替你驗收 Runner 權限。
團隊要自行管理 Mac 節點時，需承擔硬體採購、維護、擴容及閒置資源等成本；共用節點也須設計帳號權限和憑證隔離。若發布工作確實需要 Mac、但需求會隨專案起伏，可以先比較遠端 Mac 建置資源選項與自購方案，再依工作負載判斷是否適合短期或按需使用。MACCOME 提供遠端 Mac 租用選擇；你仍應先核對實際交付資訊與團隊安全要求。若需要了解服務入口，可查看 MACCOME 的遠端 Mac 服務；長期穩定且持續高負載、或必須直接使用特定實體介面的團隊，則應優先評估自有設備。