CodeQL 2.26.4 为 Actions 工作流增加了哪些检测

如果你的代码扫描最近在 GitHub Actions 相关查询上多出几条告警，先别急着把它当成代码突然变差。CodeQL 2.26.4 的变化，主要是把事件载荷中的 actor 字段判断做得更严格、让 actions/unpinned-tag 覆盖可变的 reusable workflow 引用，并为 EnvironmentCheck 增加 models-as-data 配置入口。前两项可能直接改变告警结果，第三项在没有新增模型时保持原有行为。

这次更新为什么值得单独看 Actions

GitHub 官方在 2026 年 9 月 3 日的变更说明中，把 2.26.4 的 Actions 影响拆成三条。它们不是“新增一个扫描器”这么简单，而是分别触及事件语义、工作流供应链和部署环境建模。

为什么 actor 字段判断会让告警数量变化

旧的危险点在于：工作流条件写了一个看似合理的字段比较，但触发事件根本不会填充这个字段。例如工作流由 issues 事件触发，却使用 github.event.pull_request.user.login 做保护条件。字段不存在时，这个条件并不能约束实际输入。

2.26.4 将事件载荷中的 actor 字段检查从原来的 ActorIfCheck 拆出 EventActorIfCheck，而 ActorIfCheck 只继续覆盖 github.actor 和 github.triggering_actor。因此，同一份工作流在新版本下可能被认为缺少有效保护，扫描结果增加是分析口径变化，不代表每条新增告警都已经构成线上漏洞。

排查时按这条顺序走：先看 on: 下的事件，再看条件引用的字段，最后确认该字段是否由该事件填充。不要只改成另一个同义字段，也不要用一个永远为真的比较来压掉告警。

可变 reusable workflow 与 EnvironmentCheck 要分开处理

actions/unpinned-tag 的新增覆盖点是可变的 reusable workflow 引用。工作流依赖如果指向会移动的 tag 或其他可变引用，调用方实际执行的内容可能随上游变化。对生产流水线，更稳妥的做法是固定到明确版本或提交，并保留定期升级动作，避免“固定后永不更新”。

另一条是 EnvironmentCheck。官方说明允许通过 models-as-data 指定它；如果不向 actions/ql/lib/ext/config/deployment_environment.yml 增加模型，查询行为保持之前的默认状态。换句话说，这不是升级后所有仓库都会突然套用一套新的环境规则，而是给有部署环境语义的团队增加了建模入口。

在仓库里可以先做一轮人工清单，再决定是否扩大模型：

# 只做静态盘点：找出工作流引用和可能的环境条件
rg -n "uses:|environment:|github\.event\.|github\.actor" .github/workflows

# 对每个可复用工作流记录：引用是否不可变、升级由谁负责
# 对每个 environment 条件记录：事件是否真的提供了对应字段

这段命令不会替代 CodeQL 分析，它的作用是把扫描结果放回工作流上下文：哪个引用需要锁定、哪个条件需要重写、哪个环境模型值得进入试验。

升级后怎样做一次低风险复查

第一步，挑选一组包含 pull_request、issues、可复用工作流和部署环境的代表性仓库。第二步，记录升级前后的告警类型、文件位置和查询编号，尤其标记 actor 条件导致的变化。第三步，对新增告警做两类处理：确实缺少约束的，修工作流；只是事件不匹配造成的误读，修条件并补测试。

如果团队维护自定义 Actions 模型，先在分支中加入 EnvironmentCheck 配置，再观察 ControlCheck 结果是否符合团队对部署环境的定义。模型越具体，分析越有价值；把所有环境都粗暴标成可信，反而会削弱判断。

相关问题

CodeQL 2.26.4 会让所有 Actions 仓库多出告警吗？

不会。只有相关查询命中、事件字段保护判断发生变化，或工作流存在可变 reusable workflow 引用时，结果才可能变化。

EnvironmentCheck 启用后是不是默认规则被替换了？

不是。不增加 models-as-data 模型时，官方说明默认行为保持不变；启用后要用代表性工作流做回归。

发现 unpinned reusable workflow 后该怎么改？

将引用固定到明确版本或提交，并建立可追踪的升级节奏；固定引用解决可变性，不能替代对新版本的安全评估。

完整变更可查看 GitHub 官方变更说明 与 CodeQL 2.26.4 changelog。真正需要关注的不是版本号本身，而是你的工作流条件是否与触发事件、引用来源和部署环境语义一致。