不是一条"之后再翻译"的通用特征，而是目标引擎的原生表达式。下面这条匹配的是 Next.js 中间件绕过所依赖的请求头，不是它碰巧打到的那个路径。
# 屏蔽候选 —— 免认证即可触发的认证绕过。 # 以观察态签发。晋升到拦截是另一个决定，由人来做。 (http.request.uri.path contains "/api/" and http.request.method eq "POST" and any(http.request.headers["x-middleware-subrequest"][*] ne ""))
光按严重度筛是错的闸门。把整个 CVE 流过滤到 critical，每天还剩约 31 条 —— 但最近一周里其中 88% 是某一家厂商对一款企业 UNIX 的批量披露，那东西 WAF 够不着、EDR 也没有 agent。所以闸门是软件本身：自托管、有 HTTP 控制台、倒了就是大事。
直接上拦截的规则，就是在等第一个长得像利用的正常请求来制造故障。每个阶段都要挣到下一个，而且每一步都可以退回去。
在边缘对真实流量做影子评估。不丢任何流量，所以误报是以数据的形式出现，而不是以事故的形式。
收窄到一部分流量。近似样本语料必须干净 —— 命中了正常请求的规则不会往前走。
过了窗口，由人决定，编译进你的 WAF。回执里存着变更前的镜像，一次调用就能放回去。
一条悄悄什么都没挡住的虚拟补丁比没有更糟，因为有人会因此不再追真正的修复。下面这些只给工单和写明的理由，不给表达式。
WAF 根本看不到它。诚实的产出是一张 livepatch 合作方工单 —— Canonical、KernelCare、Ksplice —— 或者就是走变更窗口。
VPN 集中器或防火墙本身就是边界。它前面没有属于你的东西可以承载规则。
恶意请求和正常请求长得一样。宽到能抓住它的规则，也宽到会把应用打坏。
这正是"在安全厂商之前"那句话的另一半。托管规则集覆盖主流框架的头条 CVE，而且几小时内免费下发——那一格我们不抢，会直接说明并给出他们那条的链接。我们跑在前面的是他们不做的那批：JumpServer、KubeSphere、Nacos、Gitea 这类自托管软件，没有哪家 WAF 厂商为它们出托管规则。
没有东西可屏蔽的日子照样发布：读了多少条、为什么一条都没过闸门。一年下来，那份记录比任何单条规则都值钱，也是竞争对手一个周末抄不走的那部分。
// 数据源：NVD · OSV · GitHub Advisories · 厂商公告