GitHub Actions 保留策略變更後，Mac CI 審計證據怎麼留？2026

GitHub Actions 保留策略下，Mac CI 審計證據涵蓋哪些資料

GitHub 已確認，自 2026 年 10 月 1 日起，檢查、工作流程執行及提交狀態也受 Actions 保留設定約束；該公告涵蓋 Actions 與第三方整合建立的相關檢查和狀態。這項變更不代表不同類型的證據會以相同形式保存，也不表示平台上的狀態仍在，相關檔案就一定能下載。(官方公告)

核對時應先把記錄分成不同對象，而不是用單一「CI 留存」標籤概括：

• 檢查與提交狀態：可用來識別檢查結論及狀態來源。GitHub 的檢查執行與提交狀態 API 說明了各自的記錄對象，兩者不應被當成日誌或構建檔案。可分別參照檢查執行記錄文件與提交狀態文件核對欄位和來源。
• 工作流程執行記錄：用來把一次執行與提交、工作流程及結果連起來。保存狀態欄位不一定等於保留完整執行脈絡，應在流程中確認相關記錄可查。
• 日誌：可協助說明執行過程，應確認下載、外部保存及存取權限。GitHub 提供工作流程日誌下載說明，但下載過日誌不等於已建立企業自己的長期索引。
• 工作流程產物：測試報告、歸檔檔案及符號檔案等屬於檔案留存範圍，需與狀態和執行記錄分開驗證。GitHub 對工作流程產物的說明有助辨認其與執行資訊的差異。

發布結論必須能反查到來源與執行脈絡

審計證據的重點不是「某個頁面曾顯示成功」，而是發布批准或建置結論能否連回其來源。每項需要留存的結論，至少應能在團隊定義的證據鏈中找到提交識別、工作流程執行、檢查結果和狀態來源；若檢查或狀態由第三方整合建立，也要記錄建立者及其來源，不能只盤點由 Actions 自身產生的資料。第三方相關記錄也在公告所述範圍內，細節應以官方公告及實際組織記錄交叉核對。

可先在發布流程中建立一份證據索引，欄位以團隊能長期查閱為準：

commit:
workflow_run:
check_or_status_source:
result:
log_archive:
artifact_archive:
archive_location:
access_owner:

這是索引欄位範本，不代表平台會自動提供全部資料，也不應把範本欄位當成已驗證的來源。每次演練時，請由發布版本或提交反向查找工作流程記錄，再確認索引中的日誌與產物位置確實可讀。若第三方檢查無法與提交或執行記錄建立明確關聯，應將缺口列為未滿足的審計要求，而不是以狀態文字補足證據鏈。

保留設定要對照企業的調查窗口

組織層級的 Actions 設定會影響其涵蓋範圍；倉庫管理員不能只看倉庫頁面，就推定它可以突破企業或組織層級的上限。應將企業、組織和倉庫實際設定逐項記錄，再對照組織政策判斷生效值。GitHub 的組織保留設定文件是核對設定行為的依據，目標組織畫面與管理記錄才是此次審核的實際證據。

不要自行指定一個所有團隊共用的保留期限。平台負責人應先向安全、法務或合規負責人確認審計窗口、事件調查需求及例外核准方式，再比較現有設定能否涵蓋這些要求。若平台設定短於企業要求，就需設計獨立匯出，而不是假設日後延長平台期限便能補回歷史資料。

這也回答了 GitHub Actions checks retention 的治理重點：檢查狀態受保留規則約束後，平台團隊要確認其可查期間是否符合內部需求，並將超出該範圍仍須留存的證據另行保存。

Mac CI 歸檔要分清楚來源、責任與可恢復性

Mac CI 審計留存至少要把狀態與執行資訊、日誌、測試報告及構建檔案分別指定保存責任。這些資料可能由不同流程產生，保存於不同位置，也可能有不同存取權限；若全部放進一個未分類的壓縮檔，事後難以判定來源與完整性。

外部歸檔應建立索引，讓調查人員能依提交、工作流程執行或發布版本查找相應證據。索引應說明來源、存放位置、負責角色，以及可用來核對檔案的資訊；若需要外部匯出，須留存實際匯出紀錄及歸檔結果，而不是只保存一份「已執行匯出」的操作截圖。工作流程產物的生成與保存機制，可參照官方產物文件；下載後則須按企業自己的歸檔規範管理。

恢復驗收應實際取回代表性的記錄和檔案，確認內容能開啟、索引能解釋來源，而且存取權限符合團隊要求。若只確認檔案存在，卻無法從發布結論追溯到來源；或能找到索引，卻無法讀取檔案，都不能視為完成恢復驗收。GitHub 也說明了移除工作流程產物的操作，因此平台內的產物不可用性與外部歸檔可恢復性必須分開判定。

設定複核與恢復驗收的執行步驟

第一步：列出需要證明的發布結論

由安全或合規負責人列出審計及事件調查所需的結論類型，並逐項指定要反查的提交、工作流程、檢查結果、日誌或產物。範圍以實際政策為準，不要把某類證據的保存要求推定成所有資料的共同要求。

第二步：檢查各層級的有效設定

由企業或組織管理員核對上層策略與組織設定，再由倉庫管理員確認倉庫實際採用的設定。記下設定來源、核對日期及核准者；遇到上層限制時，將它記錄為有效邊界，而不是只修改倉庫設定後便結案。

第三步：抽查狀態、執行及第三方來源

選取實際發布或建置記錄，確認提交、執行、檢查及狀態來源之間可以互相追溯。由第三方整合建立的檢查和狀態也應納入來源盤點；若資料不完整，標示缺口並確認是否需要另行保存。

第四步：分別匯出日誌和構建產物

按照企業留存要求匯出需要長期保存的日誌、測試報告與構建檔案，並記錄來源和歸檔位置。GitHub 的工作流程日誌下載指南可作為平台下載操作的參考，但企業仍需自行確認檔案是否已進入指定的外部保存流程。

第五步：以索引執行取回測試

由負責審計或平台驗收的人員依索引，以提交、執行或發布版本查找記錄，實際取回需要的資料。檢查檔案是否可讀、來源能否說明、索引與檔案是否相符，以及使用者權限是否符合規範；只看見匯出完成訊息，不足以證明可恢復。

第六步：整理可複核的驗收包

將有效設定的截圖或配置記錄、歸檔索引、來源對照及恢復演練結果放入受控位置，並標明各項內容的責任人和例外核准人。企業管理員負責設定及上限，倉庫管理員負責流程盤點，安全審計人員檢查證據充分性，Mac CI 平台團隊負責匯出、索引及取回測試；實際分工應由企業正式核准。

以證據矩陣判斷現行方案是否足夠

下表用來對照各類資料的來源、保存責任與恢復驗證。若團隊目前的流程無法填妥任一欄，先將該項列為待處理缺口，再決定是否需要外部歸檔或調整權限。

長期依賴臨時下載、個人保存或未分類共享目錄，會使檔案責任與存取審查變得不清楚，也難以證明歸檔能否取回。對照之下，專用 Mac 構建環境可以處理團隊的 macOS 建置工作，但證據保存仍須由獨立索引、匯出流程和恢復驗收負責；租用遠端 Mac 不會自動替代企業的歸檔政策。

若團隊需要專用 macOS 構建節點，可先查看 NodeMini 遠端 Mac 建置環境選項，再依存取方式、權限和內部控制要求評估是否適用。若還要比對不同地區的遠端 Mac 資源，可參考 NodeMini 香港遠端 Mac 選項，並按團隊的連線與管理要求評估。NodeMini 提供遠端 Mac 使用方式的選擇，適合需要按需取得建置環境的團隊；若工作負載長期固定、需要自行掌握實體介面，或企業政策要求完全自主管理硬體，自購設備也可能更合適。無論採哪種方案，審計證據都應由企業另行歸檔並完成恢復驗收。

常見問題

保留規則變更後，哪些記錄可能受影響？
依 GitHub 公告，檢查、工作流程執行與提交狀態納入 Actions 保留設定約束，包含第三方整合建立的相關檢查和狀態。日誌與構建產物仍需分開核對。

狀態記錄及工作流程執行記錄如何留作審計證據？
為發布結論建立索引，保存可反查的提交、執行、檢查結果和狀態來源；再分別核對日誌與產物的外部保存位置。也要檢查第三方來源是否能追溯。

延長期限能否恢復已刪除的檢查記錄？
不能。GitHub 說明，調整保留設定不會恢復已刪除資料。應檢查是否存在可取回的外部歸檔，並以實際恢復驗收判斷證據是否仍可用。

Mac CI 日誌、狀態與構建檔案應如何分開歸檔？
依資料類型指定來源、責任人、保存位置和索引方式；分別取回狀態、執行記錄、日誌與構建檔案，確認內容可讀且關聯清楚，不要將「已匯出」等同於「可恢復」。

請先用證據矩陣核對現有流程，將缺失的來源、責任、保存位置或取回測試列為整改項目。若團隊還需要規劃 Mac CI 節點，可評估 NodeMini 的遠端 Mac 環境與存取控制是否符合建置需求；證據留存與合規責任仍須由企業自己的歸檔及審核流程承擔。