GitHub Actions 新增 vulnerability-alerts 權限：終於不用為了讀 Dependabot 警告而開大權限（2026-09 實查）

文章最後更新：2026-09-07

GitHub 在 2026-09-03 的 changelog 一次公布了 GitHub Actions 的三項更新。其中兩項在中文圈幾乎沒人提，但對安全設定的影響比看起來大——特別是新的 vulnerability-alerts 權限。查核日 2026-09-07。

一、`GITHUB_TOKEN` 新增 vulnerability-alerts 唯讀權限

官方原文：你現在可以用新的 vulnerability-alerts 權限，給工作流程唯讀存取 Dependabot 警告。這個權限支援 read 與 none 兩個值。

公告接著寫出重點：這讓你可以遵守最小權限原則，而不必依賴更寬的權限範圍。

為什麼這是好事（白話版）

很多團隊有這種需求：跑一個排程工作流程，把 Dependabot 找到的漏洞整理成報告，丟到 Slack 或開成 issue。

過去要讀到那些警告，你的 token 必須拿到更大的權限範圍——也就是說，一個「只想讀警告」的工作流程，實際上被授予了遠超過它需要的能力。萬一那個工作流程被人動了手腳（例如引用了不安全的第三方 action），攻擊者拿到的就是那個過大的權限。

現在你可以在工作流程裡明確寫：

permissions:
  vulnerability-alerts: read

其餘一律不給。 這是典型的「權限收斂」改動：功能沒變，但出事時的爆炸半徑小很多。

二、可重複使用工作流程可以認出「自己是誰」了

第二項更新是四個新的 job context 屬性：

屬性	內容
`job.workflow_ref`	定義目前這個 job 的工作流程檔完整 ref
`job.workflow_sha`	該工作流程檔的 commit SHA
`job.workflow_repository`	該工作流程檔所屬的 owner/repo
`job.workflow_file_path`	相對於 repo 根目錄的檔案路徑

官方解釋了它跟舊屬性的差別：這些 job. 開頭的值反映「定義目前這個 job 的那個工作流程」，而既有的 github.workflow_ref 與 github.workflow_sha 指的是外層。對直接寫在工作流程裡的 job 來說兩者相同，只有在可重複使用工作流程的情況才會分岔。

白話：如果你維護一個被十幾個 repo 共用的中央工作流程，過去它很難在執行期知道「我這份檔案是哪個 repo、哪個 commit 的版本」。現在可以了——這對稽核、對簽章驗證、對「確認呼叫方用的是我核可的版本」都有用。

限制：官方明寫 這些屬性在 GitHub Enterprise Server 上不可用。 自架的團隊先別排進計畫。

三、第三項是 runner 淘汰查詢 API

同一篇公告的第三項，是新的 REST API，可以查詢某個 runner 版本何時停止註冊與停止執行支援：GET /actions/runners/deprecations/{version}，回應含 runner_version、runtime_deprecates_at、registration_deprecates_at，可在 repo、組織、企業層級呼叫。

這一項我們先前已經單獨寫過完整用法，見 GitHub Actions runner 淘汰查詢 API 怎麼用。

四、這週該做的一件事

如果你手上有工作流程會碰到 Dependabot 資料，去把它的 permissions: 區塊翻出來看一眼。多數專案是幾年前設好就沒再動過，很可能還掛著遠比需要更寬的權限。

這次的改動讓「把它縮小」變成一行設定的事——這種便宜的安全收斂，比大多數需要重構的方案划算得多。

同一週 GitHub 還讓 CodeQL 的 Actions 檢查變嚴，可能會讓你的 repo 多冒警告，我們整理在 CodeQL 2.26.4 會挑出更多 Actions 問題。

本文依據 GitHub 官方 changelog（2026-09-03，GitHub Actions: Early September 2026 updates）直讀整理，查核日 2026-09-07。權限鍵的完整語法請以 GitHub 工作流程語法官方文件為準。GitHub 相關方案價格整理見 GitHub Copilot 工具頁。