Semgrep 自定义规则构建器

你要解决的问题

把团队内部的框架习惯写成可执行的检查，往往是 SAST 落地最卡的一步。通用规则能挡住 eval(user_input) 这类直白写法，但你的项目里真正的风险藏在自己的约定里：某个 ORM 查询拼接、某个应该只在服务端调用的鉴权函数被传进模板、某个内部 SDK 的回调参数没做长度限制。这些模式 Semgrep 自带的规则包覆盖不到，而手写 YAML 的学习曲线又让人容易放弃——尤其是 pattern-either、metavariable-regex 和污点模式几个概念混在一起时，规则要么误报一片，要么形同虚设。

这个技能要解决的就是从「我知道有风险」到「我有一条能跑进 CI 的规则」之间的这段路。

它实际做什么

技能以 Semgrep CLI 为执行入口，遵循 Semgrep 的 YAML 规则 schema，围绕三类能力组织规则：

• pattern-either：用多个候选模式覆盖同一类问题，避免为了边角情况写一条过于宽泛的正则。
• metavariable-regex：在匹配之后对捕获的变量做额外约束，比如要求参数名形如 *query* 才触发，从而压掉一部分误报。
• taint-mode 污点追踪：指定数据从来源（source）流向汇集点（sink）的完整路径，用来表达「用户可控数据最终进了危险 API」这类跨函数、跨赋值的漏洞。

覆盖面限定在 Python、Go、JavaScript 三种语言，适合常见的服务端与前端工程。对于这些语言里框架特有的漏洞模式——比如特定 ORM 的查询拼接、特定 HTTP 客户端的重定向处理——可以先用 pattern 做近似匹配，再叠加元变量约束或污点链路逐步收敛。

适用边界

这套能力是静态分析，不执行代码，也不做数据流之外的运行时推理。它判断的是「代码长什么样」，不是「程序实际怎么跑」，因此对反射、动态导入、重度元编程的误报和漏报都会比较明显。

需要留意的几点：

• 污点模式需要显式声明 source 与 sink，漏掉一个汇聚点就意味着那条路径不会被标记。
• 规则的精确度高度依赖你对目标框架 API 的了解程度，规则写得不准时噪声会迅速积累，反而让团队关掉 CI 检查。
• 涉及认证、授权类判断时，静态匹配能发现危险组合，但无法替代人工的安全审查。

建议先用小范围规则在存量代码上跑一遍基线，把误报清干净之后再接入流水线，比一次性铺开几十条规则要实际得多。