静态分析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 仓库 change-notes/1.23/extractor-javascript.md 展开系统梳理 CodeQL 1.23 版本中对 JavaScript 代码提取code extraction环节的全部改进包括node_modules与bower_components目录的默认排除策略及其反向配置方法、异步生成器方法与顶层await的语法解析支持、Flow 语法的扩充、CommonJS 模块识别精度的提升以及 TypeScript 提取器的两项缺陷修复。读完本文你将理解这些变更对 CodeQL 数据库构建database creation的影响掌握如何通过lgtm.yml过滤器重新纳入依赖目录并能结合仓库源码定位模块判定与默认排除的具体实现位置。一、1.23 版本 JavaScript 分析变更总览CodeQL 1.23 的 JavaScript 分析改进全部集中在代码提取Changes to code extraction阶段即从源代码构建 CodeQL 数据库时解析器如何识别文件、如何判定脚本与模块、以及支持哪些语法。共包含六项变更异步生成器方法async generator methods不再产生虚假语法错误node_modules和bower_components目录默认不再提取可通过lgtm.yml过滤器重新纳入支持更多 Flow 语法CommonJS 模块识别改进部分此前被提取为全局脚本global script的文件现在被正确提取为模块支持顶层awaittop-levelawait修复 TypeScript 提取器对默认导出匿名类default-exported anonymous classes与计算实例字段名computed-instance field names的处理缺陷。前五项影响 JavaScript 文件的提取第六项仅影响 TypeScript 文件。下面逐项深入解析并给出仓库内的源码依据。二、node_modules与bower_components默认不再提取2.1 变更内容自 1.23 起位于node_modules和bower_components目录内的文件默认不再被提取。这两类目录分别存放 npm 与 Bower 的第三方依赖通常体量巨大、包含大量压缩与生成代码且不属于项目自身源码。默认排除它们可以显著缩短数据库构建时间、减小数据库体积并避免第三方代码干扰分析结果。2.2 源码层面的默认排除实现该行为在 JavaScript 提取器的自动构建逻辑中有明确实现。在 javascript/extractor/src/com/semmle/js/extractor/AutoBuild.java#L419-L421 中默认提取模式default extraction patterns的构建末尾显式追加了这两条排除规则// exclude node_modules and bower_components patterns.add(-**/node_modules); patterns.add(-**/bower_components);这些模式随后被组装为ProjectLayout见 AutoBuild.java#L436用于决定哪些文件进入提取流程。同一段代码还展示了该默认模式集合的完整构成AutoBuild.java#L388-L421默认提取 HTML、JS、YAML、TypeScript 四类文件按其扩展名匹配显式包含与分析和构建相关的 JSON 文件.eslintrc*、.xsaccess、xs-app.json、*.view.jsonSAP UI5、manifest.json、package.json、*tsconfig*.json、codeql-javascript-*.json默认排除*.lock锁文件除非显式允许否则排除*.min.js与*-min.js压缩文件对应EnvironmentVariables.allowMinifiedFiles()开关。node_modules与bower_components的排除与上述规则同属默认模式层用户可以通过过滤器显式覆盖。2.3 如何重新提取依赖目录lgtm.yml 过滤器如果确实需要提取这两类目录中的文件可在项目的lgtm.yml中为 JavaScript 提取配置添加如下过滤器也可追加到已有 filters 列表中extraction: javascript: index: filters: - include: **/node_modules - include: **/bower_components配置说明filters列表中的每条规则是一个include:或exclude:映射值为相对于项目根目录的路径模式include规则会把匹配的文件重新纳入提取范围从而覆盖默认的排除模式规则按顺序生效因此更具体的include应放在相应exclude之前以保证覆盖关系符合预期若不希望整体纳入整个依赖目录也可以按子路径精确控制例如include: **/node_modules/my-lib/src。需要强调的是默认排除依赖目录是推荐做法依赖代码通常不应参与安全查询的命中范围重新纳入前请评估其对构建时间与分析结果的影响。在自动化构建层面AutoBuild.java#L424-L434 展示了提取模式还支持通过环境变量LGTM_INDEX_FILTERS注入额外过滤器include:pattern形式直接加入模式集合exclude:pattern形式则被加上-前缀变为排除模式。这与lgtm.yml中filters的语义一致可供脚本化构建场景参考。三、异步生成器方法解析修复异步生成器方法async generator methods即同时使用async与生成器语法的方法例如const obj { async *generate() { yield 1; await something(); yield 2; } };在 1.23 之前此类方法可能触发虚假的语法错误spurious syntax error导致包含它们的文件无法被正确解析和提取。1.23 修复了该问题异步生成器方法现在可以被正确解析。JavaScript 提取器的语法解析由自研的 jcorn 解析器完成。如 javascript/extractor/README.md#L5 所述该提取器内置了最新版本 ECMAScript 的解析器以及少量提案阶段与历史扩展seesrc/com/semmle/jcorn。异步生成器属于 ES2018 正式语法随解析器对现代语法的持续跟进其方法形式同时包含async与*得到了正确识别不再被误判为语法错误。四、Flow 语法支持扩充Flow 是 Facebook 出品的 JavaScript 静态类型检查器其类型注解语法如type、interface、泛型、?可空类型、|联合类型等在大量 JS 项目中广泛使用。1.23 为 Flow 语法提供了更多支持使包含这些注解的源码能够被提取器完整解析而不是被当作非法语法丢弃。仓库中的 Flow 支持集中在 jcorn 解析器的 Flow 模块javascript/extractor/src/com/semmle/jcorn/flow/FlowParser.java 实现了 Flow 语法扩展的解析逻辑例如其中 FlowParser.java#L463 还处理了iterator这类非标准 Flow 属性名javascript/extractor/src/com/semmle/jcorn/Options.java#L43 定义了allowFlowTypes解析选项其取值决定解析器是否启用 Flow 类型语法见 Options.java#L135-L136 与 Options.java#L211-L212FlowParser.java#L833-L835 中shouldFlowSyntaxBeAllowed直接读取该选项。这意味着启用 Flow 支持后Flow 类型注解会作为语法结构进入 AST并被 CodeQL 查询库所覆盖从而避免因解析失败导致整文件无法分析。五、CommonJS 模块识别改进5.1 变更内容1.23 改进了对 CommonJS 模块的识别。此前部分使用require/module.exports的 CommonJS 文件会被提取为全局脚本global script而现在会被正确识别为模块module。这一判定直接影响变量作用域与顶层绑定的建模模块内顶层变量不应成为全局变量依赖关系与调用图的构建精度数据流分析taint tracking 等的准确性。5.2 模块判定的源码实现文件类型脚本 / ES 模块 / CommonJS 模块的判定逻辑位于 javascript/extractor/src/com/semmle/js/extractor/ScriptExtractor.java#L28-L39/** True if files with the given extension and type (from package.json) should always be treated as ES2015 modules. */ private boolean isAlwaysModule(String extension, String packageType) { if (extension.equals(.mjs) || extension.equals(.es6) || extension.equals(.es)) { return true; } return module.equals(packageType) extension.equals(.js); } /** True if files with the given extension and type (from package.json) should always be treated as CommonJS modules. */ private boolean isAlwaysCommonJSModule(String extension, String packageType) { return extension.equals(.cjs) || (extension.equals(.js) commonjs.equals(packageType)); }判定规则可以概括为.mjs、.es6、.es扩展名始终作为 ES2015 模块.js文件且所在package.json声明type: module作为 ES2015 模块.cjs扩展名始终作为 CommonJS 模块.js文件且所在package.json声明type: commonjs作为 CommonJS 模块其余文件在SourceType.AUTO模式下见 ScriptExtractor.java#L93-L101由解析器按源码内容动态判定而.cjs等确定性规则则为判定提供了强约束。被识别为模块的文件在提取产物TRAP 文件中会以is_module等关系标记例如仓库测试输出 javascript/extractor/tests/closure/output/trap/googDotModule.js.trap#L109-L110 中可以看到is_module与is_es2015_module的标记。仓库还包含.cjs文件提取的专门测试输入javascript/extractor/tests/extensions/input/tst4.cjs 及其对应输出 javascript/extractor/tests/extensions/output/trap/tst4.cjs.trap。5.3 对既有数据库的影响由于判定结果发生变化升级到 1.23 后某些此前被建模为全局脚本的 CommonJS 文件会被重新建模为模块。对于依赖文件级分析结果如全局变量清单、模块依赖图的查询其输出可能随之变化这是预期行为。六、顶层await支持顶层awaittop-levelawait允许在 ES 模块的顶层作用域直接使用await而无需包在async函数中例如// module.mjs const data await fetch(/api/data); export default data;1.23 起该语法得到支持包含顶层await的模块文件不再因解析失败而被跳过。从源码看顶层await位于提取器实验性 ECMAScript 提案支持的清单之中。在 javascript/extractor/src/com/semmle/js/extractor/Main.java#L318-L323 中--experimental标志的说明列出了所支持的提案特性Enable experimental support for pending ECMAScript proposals (public class fields, function.sent, decorators, export extensions, function bind, parameter-less catch, dynamic import, numeric separators, bigints, top-level await), as well as other language extensions (E4X, JScript, Mozilla and v8-specific extensions) and full HTML extraction.同时需要注意提取目标语法的基线同一文件中 Main.java#L312-L313 显示--ecma-version参数已被标记为废弃说明文件现在总是按 ECMAScript 2017 提取——即解析基线固定为 ES2017更高版本的新语法依赖解析器自身的扩展能力来覆盖。顶层await等提案特性通过解析器扩展进入支持范围。七、TypeScript 提取器缺陷修复最后一项变更针对 TypeScript 文件修复了两个已知缺陷默认导出的匿名类default-exported anonymous classes此前对export default class { ... }这类匿名类默认导出的处理存在缺陷可能产生错误的导出与类绑定信息计算实例字段名computed-instance field names此前对class C { [expr]() {} }这类使用计算表达式的实例字段/方法名的处理存在缺陷。TypeScript 的提取由独立的解析器包装程序完成。如 javascript/extractor/lib/typescript/README.md#L1-L4 所述该目录是一个 Node.js 程序TypeScript parser wrapper由 JavaScript 提取器调用以解析 TypeScript 代码其核心入口为 javascript/extractor/lib/typescript/src/main.ts在收到parse请求后调用 TypeScript 编译器解析源文件并把 AST 序列化回提取器main.ts#L16-L23。1.23 针对上述两类 AST 场景修正了提取逻辑使 TypeScript 文件的模块导出与类成员建模与 TypeScript 编译器语义保持一致。八、升级验证建议升级到 1.23 后可以从以下角度验证提取行为的变化对比数据库大小与构建时间若项目包含大量node_modules/bower_components数据库体积与构建耗时通常会有明显下降检查文件覆盖率确认依赖目录中的文件已不在提取范围内若分析结果异常如某些查询突然不再命中依赖相关代码请检查是否被默认排除策略影响复核模块判定对同时包含脚本与 CommonJS/ES 模块的项目抽查.cjs、.mjs以及声明了type: module/type: commonjs的包确认文件被正确建模语法兼容性回归对使用了异步生成器、顶层await、Flow 类型注解的项目确认这些文件能正常解析并进入分析流程不再出现因虚假语法错误而整文件跳过的情况。上述改进的完整官方说明见 change-notes/1.23/extractor-javascript.md提取器整体架构概览可参考 javascript/extractor/README.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 1.24 JavaScript 分析改进全解析查询、库与框架支持深度指南CodeQL 1.24 JavaScript 分析改进全解析查询、库与框架支持深度指南 导读 本文围绕 CodeQL 1.24 版本对 JavaScript/静态分析SAST应用安全漏洞扫描代码质量Renovate 对 Conanconanfile.txt / conanfile.py依赖管理支持详解提取、Conan v2 API 解析与 conan.lock 更新Renovate 对 Conanconanfile.txt / conanfile.py依赖管理支持详解提取、Conan v2 API 解析与 conan可观测性AI 评测LLMOpsAI 应用人工智能dynamic-datasource多模块依赖冲突终极排除依赖指南dynamic datasource多模块依赖冲突终极排除依赖指南 dynamic datasource spring boot starter 是一个强大的后端数据库上一篇终极指南Context Engineering量子语义框架如何彻底改变AI理解能力的3个核心视角下一篇js2flowchart与RustWebAssembly后端代码可视化创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
