CodeQL 2.27.2 于10月7日发布。在发布记录中,最可能影响现有查询的是 Go 库的变更。
此次发布基于共享 CFG 库重新实现了 Go 的控制流图(CFG)。CFG 用节点和边表示代码可能的执行顺序。
新增了表示赋值、函数参数与结果、range 语句和延迟调用(defer)的节点。从入口点不可达的节点被排除,基本块也直接由共享 CFG 构建。
依赖特定节点、边、位置、文本表示或基本块边界的现有代码可能需要修改。
需要在自定义查询包中查找的 API 变化
BasicBlocks::Cfg 已被移除,新增了 ControlFlow::EntryNode 和 ControlFlow::ExitNode。
IfStmt.getCond 已被弃用,改为推荐 IfStmt.getCondition。IfStmt.getThen 和 LoopStmt.getBody 的返回类型从 BlockStmt 放宽为 Stmt。
ReadArgumentInstruction、SelectInstruction 等多个 IR 指令类也被移除或合并。
只改 API 名称可以消除编译错误,但关于图结构或返回语句类型的更深层假设可能依然存在。
macOS 27 与 Xcode 27 下的构建模式限制
GitHub 10月9日的说明补充了另一项环境限制。自 macOS 27 和 Xcode 27 起,Apple 不再提供追踪分析所需的 x86-64/arm64 多架构二进制文件。
因此,编译型语言的 autobuild 和 manual 模式在任何 Xcode 版本的 macOS 27 上、以及选择 Xcode 27 的 macOS 26 上都不受支持。使用这些模式时,推荐 macOS 26 和 Xcode 26 或更早版本。
改进 macOS 上 build mode none 的支持仍在进行中。它不是当下可用的通用替代方案,这一限制也不意味着所有 Mac 上的所有 CodeQL 检查都无法进行。
区分数据库生成与查询含义的两道关口
把迁移分成两道关口更容易处理。第一道是所选的运行器、操作系统、Xcode 和构建模式能否生成预期的数据库。
记录实际应用的版本,比相信熟悉的运行器名称更准确。
第二道是用代表性测试输入和已知检出结果评估查询包。把两者分开,可以避免调试连提取都未完成的查询,或因为运行器受支持就误以为查询含义得以保留。
触及查询前提的 Go 输入
Go 审查适合使用触及查询实际前提的输入。对于沿语句边界工作的查询,要加入变更后的 API 返回普通 Stmt 而非 BlockStmt 的情况。
对于遍历路径的查询,要同时查看预期的可达路径和有意设为不可达的代码。
只看告警总数并不够。在相同数量下可能一个结果消失、另一个出现,数量变化也可能是有意的修复。
注意事项:未执行的验证与提取失败
发布记录和后续公告是这一迁移计划的依据,但本文并未运行查询、提取器或 CI 运行器。
提取失败就是失败的安全检查,不能因为没有发现结果就当作安全代码。
查询编译成功也只是兼容性验证的一个步骤。
升级结果只有在能够说明哪些检测在哪个数据库上保持了原有含义时才可接受,而不是看告警数量。
