- 静态分析
- SAST
- 应用安全
- 漏洞扫描
- 代码质量
【免费下载链接】codeql
CodeQL: the libraries and queries that power security researchers around the world, as well as code scanning in GitHub Advanced Security
本篇文章以仓库中 actions/ql/src/change-notes/released/0.6.0.md 版本变更记录为骨架，系统梳理 GitHub Actions 数据流模型生成查询（model-generator）被移出security-and-quality套件的前因后果，并结合 actions/ql/src/Models 下六条查询与 ExcessiveSecretsExposure.ql 的源码，解释这些变更对实际告警行为的影响。读完本文，你将理解：为什么模型生成查询不适合面向用户产生漏洞告警、被移除后已有告警如何处理，以及security-severity元数据在查询结果中的角色。
一、版本背景：GitHub Actions 专用 CodeQL 包
CodeQL 仓库中的actions目录承载了一套专门分析 GitHub Actions 工作流（.github/workflows/*.yml）的查询集，其查询代码位于 actions/ql/src，按功能划分为：
- Security：面向漏洞的安全查询，按 CWE 分类组织，例如 CWE-312（敏感信息泄露）、CWE-094（代码注入）、CWE-829（不可信资源加载）等；
- Models：数据流模型生成查询（model-generator），用于分析复合操作（composite actions）与可复用工作流（reusable workflows）的输入输出数据流；
- Debug 与 Diagnostics：调试与诊断辅助查询。
版本 0.6.0 的变更核心集中在两点：一是从security-and-quality套件中移除六个模型生成查询；二是为actions/excessive-secrets-exposure查询补齐security-severity元数据。前者属于 Breaking Changes，后者属于 Bug Fixes。
二、Breaking Changes：六个模型生成查询退出 security-and-quality 套件
变更记录明确列出以下六个查询从security-and-quality套件中移除：
| 查询 ID | 对应源码文件 |
|---|---|
actions/composite-action-sinks | CompositeActionsSinks.ql |
actions/composite-action-sources | CompositeActionsSources.ql |
actions/composite-action-summaries | CompositeActionsSummaries.ql |
actions/reusable-workflow-sinks | ReusableWorkflowsSinks.ql |
actions/reusable-workflow-sources | ReusableWorkflowsSources.ql |
actions/reusable-workflow-summaries | ReusableWorkflowsSummaries.ql |
2.1 为什么移除：模型生成查询不面向用户告警
变更记录给出的理由非常明确：这些查询不是用来产生面向用户的漏洞告警的，而是服务于数据流模型生成。因此将它们从security-and-quality套件中移出，可以避免在代码扫描结果中引入一批"模型生成"性质的噪音告警。
从六条查询的元数据（@tags）中可以印证这一点，例如 CompositeActionsSinks.ql 的声明：
/** * @name Composite Action Sinks * @description Actions passing input variables to expression injection sinks. * @kind path-problem * @problem.severity warning * @security-severity 9.3 * @precision high * @id actions/composite-action-sinks * @tags actions * model-generator * external/cwe/cwe-020 */model-generator标签表明这些查询的真正用途：它们分析工作流中不可信数据如何流入流出，其结果用于构建其他查询所需的数据流模型（即"模型生成"），而不是直接判定某个位置存在漏洞。将这类内部工具性质的查询与真正的安全查询混在同一套件中，会造成告警含义模糊。
2.2 六条查询的职责分工
六条查询按"复合操作"与"可复用工作流"两类实体、以及"来源（Source）/ 汇点（Sink）/ 摘要（Summary）"三种角色两两组合而成：
复合操作（Composite Action）相关
- CompositeActionsSinks.ql：以
CompositeAction的输入（c.getAnInput()）为来源，以CodeInjectionSink为汇点，检测"输入变量流入表达式注入汇点"的数据流； - CompositeActionsSources.ql：以
RemoteFlowSource（并排除DataFlow::ParameterNode）为来源，以复合操作的输出表达式（c.getAnOutputExpr()）为汇点，检测"用户可控数据流入输出变量"； - CompositeActionsSummaries.ql：以复合操作输入为来源、输出表达式为汇点，刻画"输入直接透传至输出"的摘要路径。
可复用工作流（Reusable Workflow）相关
- ReusableWorkflowsSinks.ql：以
ReusableWorkflow的参数（w.getAnInput()）为来源，以CodeInjectionSink为汇点； - ReusableWorkflowsSources.ql：以
RemoteFlowSource为来源、可复用工作流的输出表达式为汇点； - ReusableWorkflowsSummaries.ql：刻画可复用工作流"参数透传至输出"的摘要路径。
从实现上看，这六条查询都采用同一套 CodeQL 数据流框架模式：定义DataFlow::ConfigSig（isSource/isSink），实例化全局污点追踪配置TaintTracking::Global<MyConfig>，并约束来源与汇点位于同一文件（source.getNode().getLocation().getFile() = sink.getNode().getLocation().getFile()），最后以select sink.getNode(), source, sink, ...输出路径图（kind: path-problem）。这种结构清晰说明它们是"为建模而扫描"，与security-and-quality套件中面向漏洞判定的查询定位完全不同。
2.3 已有告警会自动关闭
变更记录特别说明：对于这些查询已经产生的告警，升级到 0.6.0 后会自动关闭（"Any existing alerts for these queries will be closed automatically"）。这是因为查询从套件中移除后，后续扫描不再产生对应结果，CodeQL 的告警管理系统会将历史告警标记为已关闭，无需人工干预。如果读者此前在扫描结果中看到过actions/composite-action-sources之类的条目，可以放心地将其视为查询集结构调整的结果，而非漏洞状态变化。
三、顺带修复：查询 ID 拼写错误
变更记录中有一处容易被忽略但值得注意的细节：actions/reusable-workflow-sinks是从actions/reusable-wokflow-sinks改名而来（"renamed fromactions/reusable-wokflow-sinks"）。原 ID 中workflow拼写为wokflow，属于历史遗留的拼写错误。改名意味着：
- 该查询在扫描结果、API 中的标识符发生变化；
- 旧 ID 下的历史告警因 ID 不再匹配而关闭，新 ID 下会重新产生告警（如果需要）。
这一改动同时也在代码中落地：仓库内模型查询文件的@id均使用正确拼写actions/reusable-workflow-sinks（见 ReusableWorkflowsSinks.ql），与变更记录一致。
四、Bug Fixes：为 excessive-secrets-exposure 补齐 security-severity
0.6.0 的另一项变更为查询actions/excessive-secrets-exposure分配了security-severity元数据。对应源码 ExcessiveSecretsExposure.ql 的完整元数据如下：
/** * @name Excessive Secrets Exposure * @description All organization and repository secrets are passed to the workflow runner. * @kind problem * @precision high * @security-severity 5.0 * @problem.severity warning * @id actions/excessive-secrets-exposure * @tags actions * security * external/cwe/cwe-312 */4.1 该查询检测什么
从源码主体看，它定位工作流表达式中直接引用secrets上下文的情况：
from Expression expr where getAToJsonReferenceExpression(expr.getExpression(), _).matches("secrets%") or expr.getExpression().matches("secrets[%") and not expr.getExpression().matches("secrets[\"%") and not expr.getExpression().matches("secrets['%") select expr, "All organization and repository secrets are passed to the workflow runner in $@", expr, expr.getExpression()其告警消息为 "All organization and repository secrets are passed to the workflow runner"，即当某个步骤把全部组织级与仓库级密钥一次性传给工作流运行时（典型如${{ secrets }}整体展开、而非精确引用单个密钥）时触发，属于 CWE-312（敏感信息泄露）范畴。
4.2 security-severity 的作用
security-severity是 CodeQL 查询元数据中用于映射安全严重性分值的字段（此处为5.0，属于中等偏高的 CVSS 风格分值），它与@problem.severity warning配合，供 GitHub Code Scanning 等前端将查询结果归类到对应的安全严重性级别。
在 0.6.0 之前，该查询缺少这一字段，导致其在扫描结果界面中无法获得标准化的严重性分级展示；本次变更补齐了它，属于典型的"查询元数据修复"类 Bug Fix——不改变查询的检测逻辑，但改善结果呈现的规范性。从仓库中的 CHANGELOG.md 可以看到，后续版本（如 0.6.33、0.6.34 等）继续大量沿用"Query Metadata Changes"这类变更类型，说明元数据规范化是 actions 包持续演进的重要方向之一。
五、如何在套件层面验证与复现
security-and-quality套件的定义位于 actions/ql/src/codeql-suites/actions-security-and-quality.qls：
- description: Security-and-quality queries for GitHub Actions - queries: . - apply: security-and-quality-selectors.yml from: codeql/suite-helpers该套件通过apply复用codeql/suite-helpers中的security-and-quality-selectors.yml选择器来决定哪些查询纳入扫描。0.6.0 的变更正是通过调整选择器规则，将model-generator标签的六条查询排除在外。
读者可在本地验证：
- 打开 actions/ql/src/codeql-suites，对比
actions-security-and-quality.qls与actions-all.qls、actions-security-extended.qls等套件的查询集合差异； - 在 actions/ql/src/Models 下确认六条查询仍保留在仓库中——移除的是"套件收录关系"，而非删除源码，模型生成能力并未消失；
- 结合 qlpack.yml 与 codeql-pack.lock.yml 了解该包的版本组织方式。
六、总结：本次变更的三层含义
回顾 0.6.0，可以提炼出三层信息：
- 职责边界：模型生成查询（
model-generator）与面向用户的漏洞查询在定位上截然不同，前者不应出现在security-and-quality套件的用户告警流中；本次移除是 CodeQL actions 查询体系自我净化的体现。 - 版本迁移影响：六个查询 ID 中有五个直接移除、一个改名（修正拼写），所有相关历史告警会自动关闭，用户无需手工处理。
- 元数据完整性：
actions/excessive-secrets-exposure补齐security-severity后，其告警可按标准化严重性分级呈现，后续维护者可以此类元数据修复模式为参照，持续完善其余查询的元数据质量。
- 静态分析
- SAST
- 应用安全
- 漏洞扫描
- 代码质量
【免费下载链接】codeql
CodeQL: the libraries and queries that power security researchers around the world, as well as code scanning in GitHub Advanced Security
相关推荐
OpenSRE 实战：用 fix_github_security_alert 自动修复 Dependabot、CodeQL 与 Code Quality 告警
OpenSRE 实战：用 fix_github_security_alert 自动修复 Dependabot、CodeQL 与 Code Quality 告警
人工智能AI Agent运维可观测性根因分析工具调用后端MCP ClientsCodeQL查询元数据与告警信息编写规范指南
CodeQL查询元数据与告警信息编写规范指南 引言 在静态代码分析工具CodeQL中，查询文件 .ql 是核心组成部分。本文将深入解析如何规范编写CodeQL查
静态分析SAST应用安全漏洞扫描代码质量CodeQL Actions 包 0.4.2 变更深度解析：gh 命令污点建模增强与 vulnerable Actions 数据修复
CodeQL Actions 包 0.4.2 变更深度解析：gh 命令污点建模增强与 vulnerable Actions 数据修复 导读 本文以 CodeQL
静态分析SAST应用安全漏洞扫描代码质量
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
