AI News HubLIVE
站內改寫3 分鐘閱讀

我們允許AI審查低風險PR,同時不違反SOC 2控制

Mirage Security透過使用AI審查低風險拉取請求,將程式碼變更吞吐量提高了146%,同時保持SOC 2合規性。他們根據風險分類變化,高風險變更仍需人工批准,低風險變更由AI審查,並透過每週人工回顧確保控制有效。所有過程均透過CI/CD指令碼實現可審計性。

來源Hacker News AI作者: rosslazer

在過去一年中,Mirage Security將程式碼變更吞吐量提高了146%(按人頭調整)。這一突破性增長伴隨著架構、開發流程和釋出工具的全面革新。然而,一個瓶頸依然存在:人工審查。

作為SOC 2 CC8.1合規的一部分,公司需要可審計的變更管理流程。變更必須經過授權、測試、批准並以受控方式部署。傳統上,這意味著每項變更都需要人工審查,以確保無人能單方面將高風險變更推送到生產環境。

隨著吞吐量接近翻倍,審批佇列成為瓶頸。工程師需要切換上下文、審查並點選批准按鈕,導致拉取請求(PR)積壓。團隊開始思考:是否存在一種既能保持合規、又不拖慢速度、且讓人放心的更好方法?

在與審計方Richey May協作後,團隊制定了新的策略和技術方案:

  • 定義程式碼庫中的高風險和低風險區域。
  • 低風險變更由AI程式碼審查員審查,無阻塞即可合併。
  • 高風險變更仍需非作者的人工審查員批准。
  • 所有AI批准的合併每週由人工進行全面(非抽樣)回顧,作為兜底機制,並將發現反饋到工具迭代中。
  • 所有流程編碼在CI/CD指令碼中,確保可審計且減少人為錯誤。

風險分類的工作原理

核心思想:並非所有程式碼變更風險相同。儀表板標籤的文本修改與認證中介軟體或網路基礎設施的修改風險截然不同。

團隊使用dorny/paths-filter操作在PR開啟時和演進過程中進行分類。如果變更檔案觸及高風險路徑列表中的任何一項,整個PR被標記為高風險,需要人工批准。其他情況為低風險。

高風險路徑示例包括:基礎設施程式碼(*.tf)、CI/CD流水線、訪問控制、容器定義、環境配置、認證令牌、API合約、資料庫遷移、請求中介軟體、租戶邊界、加密服務、身份服務、依賴檔案等。

分類標準指令碼和工作流本身也被歸為高風險,修改它們需要人工批准。

SDLC門控

分類後,一個名為sdlc-gate的CI工作流在合併前強制執行審批策略。邏輯如下:

  • 對於高風險PR:要求非作者的人工審查員批准(透過分支保護強制執行),標記human-review標籤,移除之前的ai-approved標籤。
  • 對於低風險PR:要求至少一個批准(人工或AI)。如果AI批准,標記ai-approved標籤。標籤用於建立審計跟蹤,供每週回顧使用。

AI程式碼審查

團隊使用Claude Code Action(執行Claude Opus)作為AI審查員。AI讀取差異,留下內聯評論,併發布帶有推薦(✅批准或🚫請求變更)的摘要評論。隨後一個步驟讀取摘要,由專門的審查機器人提交正式的GitHub審查。這對於SOC 2非常重要:批准必須是正式的GitHub審查事件,而不僅僅是評論。如果AI的推薦不明確(例如“有條件的批准”),系統預設請求變更。寧可要求人工複查乾淨的PR,也不讓有問題的PR透過。

每週回顧

這是驗證所有其他控制的兜底機制。每週五,一個定時GitHub Action查詢所有在過去一週內合併且帶有ai-approved標籤的PR,生成一個列出所有PR的GitHub問題。人工審查員逐一檢查,確認是否有變更本應被分類為高風險,記錄任何異常,並透過關閉問題來簽收。審查視窗錨定到上一個回顧問題的建立時間戳,確保無空白期。每個生成的問題都包含生成它的指令碼的精確提交連結,確保可追溯性。

回顧問題示例包括:回顧週期、AI批准的合併總數、查詢方法、完整列表(含PR連結、標題、作者、合併時間),以及審查步驟清單。

GitHub Actions工作流

三個工作流協同工作:

  • claude-pr-review.yml:在每個PR上執行Claude Code Action,然後透過機器人提交正式審查。
  • sdlc-gate.yml:在每個PR事件(開啟、同步、審查提交)上執行,分類檔案並執行審批策略。
  • sdlc-weekly-review.yml:定時每週五執行,生成回顧問題。

所有工作流、分類標準、強制執行指令碼以及限制誰可以修改它們的CODEOWNERS檔案,都受程式碼所有權規則保護,需要CTO批准。

變更管理策略

更新後的策略文件定義了變更風險分類:高風險變更涉及安全控制、處理完整性、可用性或機密性,必須由非作者的人工審查員批准。低風險變更為不影響上述方面的變更,可由AI程式碼審查系統審查和批准,但需滿足條件:分類標準正式記錄、版本控制、修改本身視為高風險;修改訪問受限制;每週進行全面回顧。

能否信任流程?

AI審查程式碼聽起來令人擔憂,但人類也並非完美。大量低風險變更(如文案、移動元件、測試、小型重構)的人工審查會導致審查疲勞,使人類更容易遺漏關鍵問題。現有證據表明,AI模型在發現安全漏洞方面至少與大多數工程師相當,甚至更優。對於低風險變更,AI審查是合理的門控。對於影響安全態勢和供應鏈的變更(基礎設施、認證、租戶邊界、加密、CI/CD、依賴、關鍵工作流),仍需人工參與。

流程並非盲目信任AI,而是在最合理的地方使用AI,在最重要的地方保留人類。也許有一天,人類將不被允許在未經AI審查的情況下編寫程式碼。