
静态分析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点击查看免费下载本篇技术指南以 C 查询库 7.0.0 发布说明 为骨架逐条拆解该版本引入的破坏性变更、API 弃用与新增能力、常量分析行为调整以及数据流屏障谓词的缺陷修复并结合 Call.qll、Access.qll、Ssa.qll 等源码给出实现级佐证。读完本文你将掌握 7.0.0 中各 API 的准确迁移路径如何替换被弃用的谓词、如何适配屏障节点语义变化并能据此评估升级对既有 C/C 查询的影响。版本发布说明在仓库中的位置与阅读方式该文档位于cpp/ql/lib/change-notes/released/目录与 0.0.x、6.x、8.x、9.x 等历代版本的说明并列存放完整记录了 C/C 查询库 qlpack 自发布以来的每一次 API 变化。7.0.0 的变更条目按 CodeQL 变更说明的惯例分为五类Breaking Changes破坏性变更升级后可能影响既有查询的编译或结果Deprecated APIs已弃用但仍可使用的 API应尽快迁移New Features新增的类、谓词与内建操作支持Minor Analysis Improvements分析精度的细微调整Bug Fixes缺陷修复可能改变查询结果。这些条目同样被汇总进了 cpp/ql/lib/CHANGELOG.md便于按版本号检索。下面逐类展开。Breaking Changes_Decimal32/64/128不再作为内建类型暴露7.0.0 最直接的破坏性变更是_Decimal32、_Decimal64、_Decimal128这三个 GCC 特有的十进制浮点类型不再被 CodeQL 暴露为内建类型builtin types。文档给出的理由有两层对这些类型的支持本身不完整Support for these gcc-specific types was incomplete即此前的建模存在缺口这类类型在真实 C/C 代码库中很少使用generally not used in C/C codebases投入产出比低。对查询作者的实际影响任何在查询中直接引用这三个类型名例如在类型模式、instanceof判断或getType().getName()比较中匹配_Decimal32等字符串的既有查询升级后可能不再命中或无法解析对应类型实体。如果确实需要处理这类代码建议改用更通用的数值类型建模路径或基于类型特征的间接匹配方式而不是依赖内建类型名的直接引用。Deprecated APIsOverloadedArrayExpr::getArrayOffset/0弃用与迁移背景OverloadedArrayExpr是什么在 Call.qll 中OverloadedArrayExpr被定义为用户自定义二元operator[]作用于其参数的一次实例即重载下标运算符的调用表达式。典型场景struct T2 { T1 operator[](const T3 ); }; T1 a; T2 b; T3 c; a b[c]; // 这里 b[c] 就是一个 OverloadedArrayExpr源码中该类通过this.getTarget().hasName(operator[])识别目标函数并提供两个基础访问器getArrayBase()被下标的对象表达式优先取限定符getQualifier()否则取第 0 个子节点下标索引相关的getArrayOffset系列谓词。弃用细节与推荐替代7.0.0 将无参版本getArrayOffset/0标记为deprecated见 Call.qll#L388-L393其旧实现等价于getArrayOffset(0)即取第一个第 0 个下标。弃用后的推荐写法OverloadedArrayExpr::getArrayOffset/1按索引取第 n 个下标表达式OverloadedArrayExpr::getAnArrayOffset取任意一个下标表达式数量不限。从实现看getArrayOffset(int n)在存在限定符时返回this.getChild(n)否则返回this.getChild(n 1)因为此时第 0 个子节点是被下标对象本身而getAnArrayOffset只是对getArrayOffset(_)的存在量化封装。也就是说只要你的查询需要访问第一个下标的语义把getArrayOffset()替换成getArrayOffset(0)即可获得完全一致的行为需要遍历全部下标时则改用getAnArrayOffset。被弃用的谓词在本版本中仍可用但会在后续版本移除建议尽早迁移。New Features三项新增能力1.__is_bitwise_cloneable、__is_invocable、__is_nothrow_invocable内建操作子类7.0.0 为BuiltInOperations增加了三个新的子类对应三种编译器内建操作见 BuiltInOperations.qll新增类对应内建语义位可克隆性检查__is_bitwise_cloneable判断类型是否可按位复制常用于is_bitwise_cloneable这类 traits 的实现可调用性检查__is_invocable判断函数类型/参数包是否可被调用std::is_invocable的底层实现无异常可调用性检查__is_nothrow_invocable判断调用是否保证不抛异常std::is_nothrow_invocable的底层实现在此之前这类表达式可能只能被当作泛化的内建调用处理无法用具体子类精确匹配。新增子类后查询作者可以直接按instanceof分支或在BuiltInOperations的getAPrimaryQlClass分派中区分这三种操作便于围绕 C 类型特征traits展开更精细的分析。2.ParamAccessForType::isThisAccess识别隐式对象参数访问ParamAccessForType表示为decltype目的而对函数签名参数进行的访问。典型场景template typename L, typename R auto add(L lhs, R rhs) - decltype(lhs rhs) { return lhs rhs; }这里返回类型decltype(lhs rhs)内部是一个加法表达式其两个子节点都是ParamAccessForType见 Access.qll#L382-L402。新谓词isThisAccess在该访问指向函数的隐式对象参数即成员函数的this时成立实现上依赖param_ref_to_this(underlyingElement(this))这一底层关系。对分析decltype上下文中的this引用、以及在类型层面建模成员函数签名时这个谓词提供了直接、可判定的判断入口无需再自行推导该参数引用是否为 this。3.getArrayOffset/1与getAnArrayOffset支撑 C23 多维下标运算符C23 允许用户为类类型重载多维下标运算符例如a[i, j, k]。这意味着一个OverloadedArrayExpr可能携带多个下标表达式而旧版getArrayOffset/0只能取到第一个下标信息不完整。7.0.0 通过新增两个谓词补齐这一能力getArrayOffset(int n)按位序取第 n 个下标n 0支持访问任意维度getAnArrayOffset不限定维度地枚举所有下标表达式。两者已在 Call.qll#L395-L406 落地。配套地原getArrayOffset/0被弃用见上文避免查询作者继续使用只能取第一个下标的旧语义而漏掉多维场景。对于编写数组越界、下标污染taint等与下标相关的 C/C 安全查询这是一个需要同步跟进的重要 API 变化。Minor Analysis Improvements常量改为展开的表达式树表示7.0.0 调整了常量的表示方式部分常量不再以折叠后的单值形式存在而改用其展开的表达式树unfolded expression trees来表示。由此带来一个直接后果Expr的isConstant谓词对这些常量不再成立不再返回结果。结合 Expr.qll#L188-L195 的实现来看isConstant目前由三类来源支撑valuebind(_, underlyingElement(this))与提取器写入的值绑定表关联的常量addressConstantExpression(this)地址常量表达式如函数地址、constexpr 变量地址、lvalue 地址及其加减常量constantTemplateLiteral(this)未实例化模板中的常量模板字面量。展开的表达式树表示意味着某些常量在 AST 中保留了完整的运算结构例如1 2不再直接折叠成字面量3因此无法再从值绑定中直接命中isConstant也就不再成立。影响评估依赖isConstant判断表达式是否为编译期常量的查询如 RangeAnalysisUtils.qll、Scanf.qll 中对常量操作数的依赖可能观察到行为变化。如果你的查询需要同时覆盖折叠常量与展开表达式应结合 AST 结构如Constant字面量、FoldExpr等与isConstant共同判断而不是单独依赖单一谓词。Bug FixesBarrierGuard::getABarrierNode的间接寻址缺陷修复缺陷本质7.0.0 修复了DataFlow::BarrierGuard...::getABarrierNode中的一个 bug该谓词此前会返回带有错误间接层级indirections的DataFlow::Node。也就是说屏障节点所对应的数据流值层级与实际守卫对象不符可能导致isBarrier/isSanitizer中基于getABarrierNode实现的屏障未能正确拦截污点传播。从 Ssa.qll#L2079-L2090 的实现脉络看BarrierGuard模块通过BarrierGuardWithState把守卫检查谓词guardChecks(g, e, val)与 SSA 定义/读取关联起来getABarrierNode最终聚合出被该守卫安全检查的节点。间接层级错误意味着聚合出的节点在其指针/引用层级上与守卫表达式不一致。对你的查询的影响修复后如果你用getABarrierNode实现 dataflow/taint-tracking 查询的屏障可能会看到更多的查询结果更多告警——因为此前错误层级掩盖了部分本应被判定为受污染数据仍可达的路径。文档给出的应对方案若新增结果属于误报可使用DataFlow::BarrierGuard...::getAnIndirectBarrierNode来移除这些额外结果换言之getABarrierNode现在只应匹配恰好与该守卫值层级一致的节点而getAnIndirectBarrierNode用于覆盖经间接访问如指针解引用、成员访问后仍受守卫保护的情况。迁移建议升级到 7.0.0 后请重新跑一遍依赖屏障机制的 dataflow/taint 查询对比结果集变化在isBarrier/isSanitizer中按需将getABarrierNode替换为getAnIndirectBarrierNode并根据告警的增减判断取舍。该谓词定义于共享模块 shared/ssa/codeql/ssa/Ssa.qll被各语言查询库的数据流库复用因此这一修复的影响面不限于 C/C 查询。升级核对清单综合以上五类变更从 6.x 升级到 7.0.0 时建议逐项核对搜索弃用调用检查查询中所有OverloadedArrayExpr的.getArrayOffset()无参调用替换为getArrayOffset(0)或getAnArrayOffset复查类型引用确认没有查询依赖_Decimal32/64/128内建类型名重跑屏障相关查询对使用BarrierGuard的 dataflow/taint 查询做结果对比按需改用getAnIndirectBarrierNode复核常量判断对依赖isConstant的查询补充 AST 结构判断避免常量展开表示带来的漏报新能力接入如需处理 C23 多维下标或decltype中的this访问直接使用新增的getArrayOffset/1、getAnArrayOffset与isThisAccess。各变更条目的官方记录以 7.0.0 发布说明 为准并可在 cpp/ql/lib/CHANGELOG.md 中按版本检索到完整演进历史。升级前建议在目标查询集上运行一次全量回归测试以量化结果集变化。赞分享静态分析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点击查看免费下载相关推荐CodeQL C/C 库 3.2.0 变更深度解析数据流屏障、C20/23 语法建模与模板分析增强CodeQL C/C 库 3.2.0 变更深度解析数据流屏障、C20/23 语法建模与模板分析增强 本篇文章聚焦 CodeQL 开源仓库中 C/C静态分析SAST应用安全漏洞扫描代码质量CodeQL C 数据流库 6.1.1FieldContent 全面支持 union 字段访问与 API 变更解析CodeQL C 数据流库 6.1.1 FieldContent 全面支持 union 字段访问与 API 变更解析 本文以 CodeQL 仓库中 C静态分析SAST应用安全漏洞扫描代码质量CodeQL C 查询库 5.2.0 变更解读SEH 建模重构、__leave 语句支持与类型解析修复CodeQL C 查询库 5.2.0 变更解读SEH 建模重构、 __leave 语句支持与类型解析修复 导读 本文基于 CodeQL 仓库中 C 查静态分析SAST应用安全漏洞扫描代码质量创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考