GitHub 对其进行了重大更新的CodeQL引擎，开发者现在可以通过"models-as-data"直接定义自定义的净化器（sanitizer）和验证器（validator），这一变化简化了团队在代码库中扩展安全分析的方式。此次更新使工程师无需编写自定义 CodeQL 查询，就能配置受信任数据和已验证数据的处理方式，标志着应用安全实践正转向更易用、更可扩展的方向。
这项增强解决了传统静态分析流程中的一个关键限制：扩展检测逻辑往往需要对查询语言具有深度的专业知识。借助新方法，团队可以通过基于 YAML 的数据扩展以声明式方式定义这些行为，更容易让 CodeQL 适配项目的特定框架、内部库和自定义校验逻辑。
此次更新的核心是对污点跟踪（taint tracking）控制能力的提升。污点跟踪用于追踪不受信数据在应用中的流动路径。CodeQL 现在允许开发者将净化器（清洗或中和数据的函数）和验证器（确认数据安全性的检查）定义为"barriers"与"barrier guards"。这些结构决定了潜在不安全的数据应在系统中的何处停止传播。
两项新的可扩展谓词 barrierModel 和 barrierGuardModel 提供了这一能力。前者在函数被识别为可净化输入时会阻断污点数据流，后者在满足验证条件时停止传播。过去实现这一点通常需要编写自定义 CodeQL 逻辑；如今可通过声明式配置完成，从而降低了复杂度，也降低了团队采用高级安全分析的门槛。
该更新覆盖广泛语言，包括 C/C++、C#、Go、Java/Kotlin、JavaScript/TypeScript、Python、Ruby 和 Rust。如此广泛的支持确保拥有多语言代码库的组织能够统一安全规则的建模与执行方式，而无需在不同工具链或语言之间重复投入。
通过让团队把自身的系统知识（比如，内部净化函数或验证模式）编码进模型，CodeQL 可以给出更准确且具上下文感知的结果，减少误报并提升真实漏洞检出率。这在现代开发环境中尤为重要，因为自定义框架和抽象层常常会遮蔽传统分析的有效性。
models-as-data的引入反映了应用安全中的一个更大趋势：从以代码为中心的定制，转向以数据驱动的配置。团队不再需要编写并维护复杂查询，而是可将安全逻辑作为结构化数据管理，从而更易于版本化、共享和在组织内规模化落地。
这也契合 GitHub 持续推进的方向：将安全能力更深地融入开发者工作流，让团队基于内置工具扩展能力，而不是依赖外部或定制化方案。同时，这也加快了安全实践的上手速度，因为开发者无需接受 CodeQL 查询语言的专项培训，就能采用并调整模型。
归根结底，这次更新旨在让高级安全分析更易用、更灵活且更易维护。通过减少对自定义查询开发的依赖，GitHub 让更多团队能够按自身环境定制 CodeQL，弥补覆盖空白并提高漏洞检测准确性。
其他平台也在应对与 GitHub 此次 CodeQL 更新类似的挑战，即让安全建模更易用、更集成且更开发者友好，但它们在灵活性、易用性和分析深度之间的权衡方式各不相同。
例如，GitLab采用更以流水线为中心的方法，将静态应用安全测试（SAST）、依赖扫描和密钥泄露检测直接嵌入 CI/CD 流程。与通过查询语言暴露深度定制能力不同，GitLab 更强调预置规则和策略驱动执行，使团队无需专项专家能力也能更容易地落地安全检查。类似地，Snyk聚焦开发者优先安全，自动识别代码和依赖中的漏洞并提供内联的修复建议，在易用性和深度定制之间更偏向前者。
在更灵活、可定制方面，Semgrep等工具提供了更接近 GitHub 演进方向的替代模式。Semgrep 允许团队以类代码的模式定义自定义安全规则，避免完整查询语言的复杂度，同时保留按需定制的分析能力，从而更便于开发者扩展检测逻辑。与此同时，SonarQube等平台提供持续的代码检查，把安全、质量与可维护性检查整合到统一看板，更强调持续可见性，而非深度查询驱动建模。
综观这些路径，一个清晰的趋势正在形成，那就是 GitHub 的 CodeQL 更新正走向数据驱动、声明式安全建模，而更广泛生态也在收敛到“降低使用摩擦”这一目标，无论是通过更简化的规则定义、内置策略，还是更紧密的 CI/CD 集成。关键的权衡始终是一致的，平台必须在分析深度与精度、日常开发者可用性与可扩展性之间取得平衡，而各工具正在这条谱系上以不同的方式演进。
查看英文原文：GitHub Enhances CodeQL with Declarative Security Modeling for Faster, More Flexible Analysis