你以为检测依赖漏洞只能靠安全扫描？今天 GitHub 用一个权限把这件事彻底最小化了
写过 CI 的人都踩过这个坑——Dependabot 告警每次都要开 security-events 写权限才能读，今天 GitHub 用一个权限把这件事彻底最小化了。
这个问题困扰了团队很久
你写了一个 CI workflow，想在每次构建时顺便检查一下项目有没有已知漏洞。按理说这是一件纯读的操作——Dependabot 告诉你哪里有风险，你只需要知道就够了。
但以前不是这样的。
以前你只能给 GITHUB_TOKEN 加上 security-events: write 权限。不是 read，是 write。这意味着这个 workflow 不仅能读漏洞数据，还能写、关闭、甚至忽略安全事件。
write 权限的 workflow token 理论上可以被攻击者利用来做更多事情。GitHub 自己都建议能用 read 就不要用 write，但以前你没得选。
今天这件事变了
GitHub 给 GITHUB_TOKEN 新增了一个 vulnerability-alerts 权限，read 值，2026-09-03 正式公告。
现在你可以这样写：
permissions:
vulnerability-alerts: readworkflow 就可以读 Dependabot 的漏洞数据，但不能写入任何安全事件。写权限？那不存在了。
实际影响
最直接受益的是做依赖安全检查的 workflow。
以前最小权限配置大概是：
permissions:
security-events: write # 过大了现在可以精确到：
permissions:
vulnerability-alerts: read只拿你需要的那一个，读完就走。GitHub 官方文档明确说，这个权限就是给只关心是否存在漏洞、但不关心如何处理的 workflow 准备的。
另外，vulnerability-alerts: none 也是一个合法值。如果你的 workflow 根本不需要碰 Dependabot 数据，显式声明 none 比什么都不写更安全。
企业视角：这个改动说明什么
GitHub 一直在推最小权限原则，从 actions: write 到 id-token: write 再到现在的 vulnerability-alerts。趋势很明显：安全策略正在往更细粒度的 token 级别收敛，不再是二选一的局面。
下一步
- 打开你的
.github/workflows/目录 - 搜索
security-events: write的 workflow 文件 - 判断这个 workflow 是否只是读漏洞数据、但不修改任何安全事件
- 如果是，替换成
vulnerability-alerts: read
官方公告：github.blog/changelog/2026-09-03
评论区
登录后可评论。