静态分析SAST应用安全漏洞扫描代码质量【免费下载链接】codeqlCodeQL: the libraries and queries that power security researchers around the world, as well as code scanning in GitHub Advanced Security项目地址https://gitcode.com/gh_mirrors/co/codeql点击查看免费下载本篇文章以仓库中 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-sinksCompositeActionsSinks.qlactions/composite-action-sourcesCompositeActionsSources.qlactions/composite-action-summariesCompositeActionsSummaries.qlactions/reusable-workflow-sinksReusableWorkflowsSinks.qlactions/reusable-workflow-sourcesReusableWorkflowsSources.qlactions/reusable-workflow-summariesReusableWorkflowsSummaries.ql2.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::ConfigSigisSource/isSink实例化全局污点追踪配置TaintTracking::GlobalMyConfig并约束来源与汇点位于同一文件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-severity0.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应用安全漏洞扫描代码质量【免费下载链接】codeqlCodeQL: the libraries and queries that power security researchers around the world, as well as code scanning in GitHub Advanced Security项目地址https://gitcode.com/gh_mirrors/co/codeql点击查看免费下载相关推荐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应用安全漏洞扫描代码质量上一篇Vue Query 中如何让 queryKey 与 enabled 跟随 ref 响应式变化以触发重新请求下一篇External Secrets Operator 核心 CRD 设计规范与实战解析ExternalSecret 与 SecretStore创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
CodeQL Actions 包 0.6.0 版本解读：模型生成查询退出 security-and-quality 套件与告警元数据修复
静态分析SAST应用安全漏洞扫描代码质量【免费下载链接】codeqlCodeQL: the libraries and queries that power security researchers around the world, as well as code scanning in GitHub Advanced Security项目地址https://gitcode.com/gh_mirrors/co/codeql点击查看免费下载本篇文章以仓库中 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-sinksCompositeActionsSinks.qlactions/composite-action-sourcesCompositeActionsSources.qlactions/composite-action-summariesCompositeActionsSummaries.qlactions/reusable-workflow-sinksReusableWorkflowsSinks.qlactions/reusable-workflow-sourcesReusableWorkflowsSources.qlactions/reusable-workflow-summariesReusableWorkflowsSummaries.ql2.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::ConfigSigisSource/isSink实例化全局污点追踪配置TaintTracking::GlobalMyConfig并约束来源与汇点位于同一文件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-severity0.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应用安全漏洞扫描代码质量【免费下载链接】codeqlCodeQL: the libraries and queries that power security researchers around the world, as well as code scanning in GitHub Advanced Security项目地址https://gitcode.com/gh_mirrors/co/codeql点击查看免费下载相关推荐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应用安全漏洞扫描代码质量上一篇Vue Query 中如何让 queryKey 与 enabled 跟随 ref 响应式变化以触发重新请求下一篇External Secrets Operator 核心 CRD 设计规范与实战解析ExternalSecret 与 SecretStore创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
