AI 科技新聞

GitHub AI Scan 新增 REST API 管理：如何批次控制程式碼掃描？

程式化控制掃描開關，可讓大批儲存庫依組織政策導入。本文整理GitHub AI Scan的更新、適用情境、關鍵數據與限制，並附官方來源及延伸閱讀。

GitHub 更新公告官方識別圖，非掃描結果畫面。來源：官方／原作者頁面。

組織有數百個程式庫時，逐一點開 AI 掃描設定很容易漏掉。把開關放進程式化管理，才比較容易維持一致政策。

GitHub AI Scan 在 11 月 13 日的公告中說明，儲存庫掃描可透過 REST API 在組織與儲存庫層級開關。

REST API 是讓程式用網路請求讀寫設定的介面。這項公開預覽新增 repository_scan，能和既有的合併請求掃描設定一起管理。

最容易誤會的是：開啟設定不會直接開始掃描。實際掃描仍按需執行，也會消耗對應的 AI credits，也就是掃描使用額度。

因此，管理者需要分開追蹤「已允許掃描」和「真的掃過」兩種狀態。

GitHub AI Scan 管理介面新增什麼

管理介面可讀取並修改組織或個別儲存庫的 repository_scan 設定。團隊可以用腳本或基礎設施設定來逐步導入。

同一個請求也能更新 pr_scan，也就是合併請求的 AI 掃描開關。兩者有各自用途，應依現有安全流程決定是否一起調整。

公告還指出，如果同一請求中的任一變更被政策阻擋，會回傳 422，而且兩項都不變。腳本因此需要讀回設定，確認實際結果。

組織關閉時，底下儲存庫不能自行開啟。組織開啟後，儲存庫會繼承設定，並可個別選擇退出。

企業層級若不允許 AI Scan，開啟請求也會失敗。因此，批次腳本仍受上層政策約束，不能把 API 當成繞過管理規則的方法。

組織擁有者與安全管理員可管理組織設定，儲存庫管理員則能個別退出。權限分工也應寫進操作文件。

開啟後，具有寫入權限的使用者仍要按需執行掃描，每次消耗 GitHub Code Security AI credits。預算與執行頻率需要一起安排。

公告列出組織擁有的公開儲存庫，以及具備對應安全方案的私人或內部儲存庫等適用範圍，GHES 不在支援之列。

本文建議報表同時記錄開關、最近掃描時間與結果處理進度。這樣才能分辨政策覆蓋、實際檢查與已修復的差異。

不會。官方說開啟設定不會啟動掃描，使用者仍須按需執行。

本次公告說不支援 GHES。適用方案、儲存庫類型與企業政策也需要一併核對。

對大量程式庫，API 能減少設定遺漏；能否形成有效防線，還要把掃描執行、額度與修補追蹤接起來。

免費訂閱 AI 郵報，持續掌握 AI 工具與科技更新。