摘要： GitHub 在 2026 年 11 月 2 日更新其 code security risk assessment 與 secret risk assessment，報告現在會標示每個發現項目所在儲存庫是受保護還是未受保護。對管理組織安全的人來說，這把「哪些儲存庫還沒被安全功能覆蓋」從需要自己盤點的功課，變成評估報告裡直接可見的結果。
改動本身是什麼
根據 GitHub Changelog 的公告，兩項風險評估現在都會顯示發現項目位於 protected 或 unprotected 儲存庫，用意是幫助團隊找出該延伸安全覆蓋的地方。組織管理員和 security manager 可以從組織 Security 分頁下的 Assessments 開始執行評估。
這項改動已在 GitHub Enterprise Cloud 和 GitHub Team 上線；secret risk assessment 在 GitHub Enterprise Server 則預計於 3.24 版提供。
為什麼「保護狀態」值得單獨標出
看官方文件的說明，這個評估本來就是免費、自助式的掃描：預設依過去 90 天的 commit 活動預選最多 20 個私有與內部儲存庫，產出漏洞清單、嚴重程度，以及多少項目能用 Copilot Autofix 修復，每 90 天可重跑一次。
在此之前，報告回答的是「你的儲存庫裡有哪些風險」；現在多回答一層：「這些風險所在的地方，安全功能到底開了沒」。這個區分很實際。一個嚴重度高的漏洞落在已啟用保護的儲存庫，代表現有機制有機會攔到它；落在未受保護的儲存庫，則代表它目前是完全暴露的。修補優先順序自然不同。
我先前寫過 GitHub 把 AI Scan 的成效做成指標，當時的重點是安全投資終於可以量化。這次改動是同一個方向：把「覆蓋範圍」也變成產品裡看得見的資訊，而不是靠各團隊自己記得去開。
實際使用上的幾個限制
文件裡有幾點值得在規劃時留意。首先，單次評估最多掃 20 個儲存庫，且只涵蓋支援 code scanning 語言的儲存庫；大型組織的覆蓋是取樣而非全量。其次，掃描有一小時逾時，若儲存庫內所有語言都掃描失敗，該儲存庫會計為失敗。最後，每 90 天才能重跑一次，雖然每次可以更換掃描的儲存庫組合。
換句話說，這個工具適合做週期性的體檢與覆蓋盤點，不適合當成即時監控的替代品。
對產品團隊的啟發
如果你正在做開發者或安全相關的產品，這次更新有個可以借鏡的設計決策：把「配置狀態」這個後設資訊直接放進風險報告，而不是讓使用者自己對照兩份清單。風險本身和防護覆蓋是兩個維度，合在一起看才有行動意義。
實際的下一步很簡單：如果你的組織在 GitHub Team 或 Enterprise Cloud 上，還沒跑過這個免費評估，可以先從 Assessments 入口跑一輪，特別看報告裡標為 unprotected 的儲存庫——那通常就是最容易漏掉基本防護的地方。
參考來源
- Security risk assessments include repository protection status - GitHub Changelog
- Code security risk assessment - GitHub Docs
在 X 上查看原貼文