CodeQL 2.27.3 新增 Python 3.15 特性支持与 JSON 数据扩展
GitHub 代码扫描背后的静态分析引擎 CodeQL 发布 2.27.3：支持 Python 3.15 语法与 frozendict、sentinel 内置对象，新增 C23 位精确整数与 JSON 格式数据扩展，并引入可选的 LLM 生成数据威胁模型，同时多语言查询误报率下降。
原贴
查看原文原文
中文翻译
CodeQL 是 GitHub 代码扫描背后的静态分析引擎，用于发现并修复你代码中的安全问题。我们最近发布了 CodeQL 2.27.3。它支持新的 Python 3.15 语言特性，为数据扩展新增 JSON 语法，新增 C23 位精确整数，并包含跨语言的准确性改进。
数据扩展文件现在支持 JSON 语法，使用与 YAML 数据扩展相同的结构。Java 风格注释（// ... 和 /* ... */）同样可用。CodeQL 将 .json 扩展名的文件作为 JSON 解析，并继续将所有其他文件作为 YAML 解析。
我们新增了一个可选的、针对 LLM 生成数据的 AI 威胁模型。它不包含任何内置的 source 模型，因此你可以用数据扩展定义自己的 source。
Python 提取器现在支持 Python 3.15 语法，包括 match 字面量模式中的一元加号和 Unicode 17 标识符。我们新增了对 Python 3.15 引入的新内置对象 frozendict 和 sentinel 的支持，包括对 frozendict 构造的数据流建模。
我们新增了对 C23 位精确整数（_BitInt(N)）的支持。我们新增了 BlazingMQ 的 BloombergLP::bmqa::Message 和 MessageProperties 类及其迭代器的流摘要。我们新增了对 is 表达式和 switch 分支中位置模式的数据流支持。
配置私有注册表时，CodeQL 现在会向 NuGet CLI 传递所需的代理和证书环境变量。
CodeQL 现在将 Grape::API 的请求子访问器视为远程流源。这些包括 body.read、body.string、params、GET、POST、cookies、env、query_string 和 path_info。
cpp/resource-not-released-in-destructor 查询现在能识别通过本地别名释放的资源，从而减少误报。当类型信息不完整时，cs/simplifiable-boolean-expression 查询现在产生的误报更少。
核心信息
GitHub 代码扫描背后的静态分析引擎 CodeQL 发布 2.27.3：支持 Python 3.15 语法与 frozendict、sentinel 内置对象，新增 C23 位精确整数与 JSON 格式数据扩展，并引入可选的 LLM 生成数据威胁模型，同时多语言查询误报率下降。
- GitHub 代码扫描背后的静态分析引擎 CodeQL 发布 2.27.3：支持 Python 3.15 语法与 frozendict、sentinel 内置对象，新增 C23 位精确整数与 JSON 格式数据扩展，并引入可选的 LLM 生成数据威胁模型，同时多语言查询误报率下降。
- 原贴提到：CodeQL is the static analysis engine behind GitHub code scanning, which
- 来源：github.blog
详细解读
这是什么信号
这是一次静态分析引擎的版本更新，但信息量不在“版本号”，而在两个方向上的推进：一是语言与生态的跟进速度，二是告警噪音的控制。CodeQL 2.27.3 覆盖了 Python 3.15 的新语法（match 字面量模式中的一元加号、Unicode 17 标识符）以及新内置对象 frozendict、sentinel，并为 frozendict 构造补上了数据流建模；C/C++ 侧增加了对 C23 位精确整数 _BitInt(N) 的支持；Java/Kotlin 生态外，还补了 BlazingMQ 的 BloombergLP::bmqa::Message、MessageProperties 及其迭代器的流摘要。配置层面，数据扩展文件现在可以用 JSON 写，结构与 YAML 版一致，并支持 Java 风格注释，解析按扩展名区分——.json 走 JSON，其余仍走 YAML。
更值得单独拎出来的是那个“针对 LLM 生成数据的可选 AI 威胁模型”。它刻意不自带任何内置 source 模型，要求团队用数据扩展自己定义 source。这不是能力缺失，而是产品取向：把“哪些数据算 AI 生成、从哪流入”这件判断交还给使用者，默认不打开。
为什么重要
静态分析工具的真实价值由两件事决定：能不能跟上语言演进，以及告警里有多少是噪音。语言新特性一旦不被解析器识别，整段代码可能解析失败或数据流断裂，形成静默漏报；误报率则直接决定开发者还愿不愿意点开告警。这次更新两边都动了——一边补 Python 3.15、C23 这些前沿语法，一边明确点名 cpp/resource-not-released-in-destructor（识别通过本地别名释放的资源）和 cs/simplifiable-boolean-expression（类型信息不完整时）两处误报下降。另外 Grape::API 的请求子访问器（body.read、params、GET、POST、cookies、env、query_string、path_info 等）被纳入远程流源，对 Ruby 服务端的注入类检测是实打实的覆盖面扩展。
对谁有价值
直接受益的是应用安全与安全工程团队：把 CodeQL 作为 CI 门禁的组织，会直接看到告警基线变化。其次是 Python 3.15 早期采用者——在语言发布前就让扫描链路不失效，比事后补洞便宜得多。C/C++ 代码库维护者获得了 _BitInt(N) 支持；使用 NuGet 私有源的 .NET 团队会受惠于代理与证书环境变量被正确传给 NuGet CLI 这一修复；Ruby/Grape 服务端团队则获得新的远程流源覆盖。
可以怎么行动
- 对齐 CI 中使用的 CodeQL 版本，并记录升级前后的告警数量差异，作为误报治理的基线。
- 评估把数据扩展从 YAML 迁到 JSON 的收益：可带注释、结构一致、迁移成本低，但要注意按扩展名分流解析的行为。
- 如果代码库中确有 LLM 生成或 LLM 加工的数据进入敏感路径，先用数据扩展定义自有 source，再决定是否启用该威胁模型 —— 它默认不会覆盖任何东西。
- 复核那两类误报下降的查询：噪音变少的同时，确认没有把原本正确的告警一并压掉。
风险与限制
第一，AI 威胁模型不自带内置 source 模型，意味着不配置就等于不存在，容易形成“以为开了其实没开”的错觉。第二，解析规则按扩展名区分，.json 文件将不再按 YAML 解析，如果既有配置里存在扩展名与实际内容不一致的历史文件，升级后可能行为变化。第三，误报减少永远伴随一个需要人工确认的问题：减少的是不是只有误报。第四，语言特性支持是渐进式的，Python 3.15 与 C23 的边缘语法仍可能存在解析盲区，不能默认“支持了就等于全覆盖”。
信息差价值
这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。
如果把《CodeQL 2.27.3 新增 Python 3.15 特性支持与 JSON 数据扩展》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。
参考来源
TOPIC HUBS
延伸专题
AI SUMMARY
这篇文章回答了什么
CodeQL 2.27.3 新增 Python 3.15 特性支持与 JSON 数据扩展主要讲什么？
GitHub 代码扫描背后的静态分析引擎 CodeQL 发布 2.27.3：支持 Python 3.15 语法与 frozendict、sentinel 内置对象，新增 C23 位精确整数与 JSON 格式数据扩展，并引入可选的 LLM 生成数据威胁模型，同时多语言查询误报率下降。
这篇文章最值得关注的要点是什么？
GitHub 代码扫描背后的静态分析引擎 CodeQL 发布 2.27.3：支持 Python 3.15 语法与 frozendict、sentinel 内置对象，新增 C23 位精确整数与 JSON 格式数据扩展，并引入可选的 LLM…；原贴提到：CodeQL is the static analysis engine behind GitHub code scanning, which；来源：github.blog
这篇文章和哪些AI专题相关？
它适合放在Agent工作流、AI工具、AI超级个体专题里阅读。 关联原因：这篇内容命中「Agent、工作流」等主题信号。；这篇内容命中「模型」等主题信号。；这篇内容命中「技能」等主题信号。
阅读这篇文章建议先理解哪些关键词？
建议先理解AI工具、工具、自动化、模型、Cursor这些关键词，再结合正文判断工具、机会或风险是否值得进入自己的工作流。