Semgrep 规则引擎

要解决什么问题

代码安全审查常常停留在「跑一遍默认规则」的层面：通用规则集要么漏掉项目特有的危险数据流，要么报出大量与业务无关的噪音。团队真正需要的，是把「本项目独有的注入路径、越权点和配置误用」写成可复用、可版本化、可评审的检查逻辑，而不是每次评审都靠人肉翻代码。这个技能要消除的，正是从「想写一条检查规则」到「规则在 CI 里真正跑起来并给出结论」之间的摩擦。

它如何工作

技能围绕 Semgrep CLI 组织，核心输入是一份自定义 YAML 规则文件，每条规则声明目标语言、匹配模式和作用范围：

• 声明式规则：用 rules: 结构描述要匹配的代码形状，比如 exec($ARGS) 或拼接进 SQL 的字符串变量，语言覆盖 Semgrep 支持的 30+ 种。
• 污点追踪：把外部输入标记为污点，验证它是否未经净化就流到 eval、命令执行、SQL 拼接等危险汇点，用于定位注入类漏洞的数据流。
• 元变量比较：通过 $X 这类 metavariable 要求模式中两处标识符必须相同，例如要求调用与参数位置上的 $X 一致，从而减少误报。
• 排除式匹配：利用 pattern-not-inside 精确划掉白名单区域，比如 // nosemgrep 注释或测试目录中的调用，让规则聚焦真正关心的位置。

实际执行时，技能先校验规则文件的结构与语言声明，再把规则交给 semgrep 命令在源码目录上运行，最后以 Semgrep 的标准输出汇总命中位置和修复建议。规则文件本身纳入代码仓库，随业务演进走 Code Review——这是它区别于一次性脚本的地方。

适用边界

• 规则质量决定检出质量：模式太宽会淹没在误报里，太窄又漏掉改写过的调用形态；pattern-not-inside 只能收窄范围，不能提升召回。
• 污点追踪是模式级而非完整数据流分析：跨函数、跨模块的间接传递可能覆盖不到，复杂项目需要补测试或加规则。
• 它只读源码：不替代动态测试、模糊测试或运行时防护，也解决不了加密和依赖配置类问题。