Vercel 把安全审查挪到每次 push：不等 PR，强推生产分支也照查，只审改动那几行

2026年11月4日0 次阅读

3分钟看懂

Vercel 在 2026 年 11 月 3 日把 Security Review 开放公测：它是 Vercel Agent 里新增的一块能力，和原来的 Code Review、Investigation 并列，面向 Pro 和 Enterprise 团队。

和大多数「AI 帮你审代码」的工具相比，它最大的不同是触发点。它不等你开 Pull Request，而是盯着 GitHub 的 push 事件——代码一推上去就开始扫。直推生产分支、甚至 force push 覆盖历史，这些常常绕过 PR 流程的动作，也在它的覆盖范围里。

另一个关键设计是只审改动。每次审查都拿当前代码和一个 base 比：有部署时，base 是这个分支上一次部署，也就是「线上正在跑的那份」；没有部署时回退到 GitHub API。因此它只看 diff，秒级出结果，官方说可以挂在每一次预览和生产部署上。缺点是第一次审查（没有 base）会读全量源码。

为什么这次值得注意

传统代码扫描器靠规则和模式匹配，能抓出明显的注入、硬编码密钥，但对「少了一句归属校验」这类逻辑漏洞很吃力。Vercel 的说法是：这个 Agent 会读 diff，同时看周边代码，追一遍改动是怎么被调用到的，检查已有的防护，最后在报出来之前把每条 finding 再核一遍。

官方博客给了一个很具体的例子：一个下载发票的接口，查询时没校验这张发票属于哪个组织。结果是任何登录用户只要改一下 ID，就能下载别家公司的发票。这种漏洞不会触发语法级告警，但会被「追调用链」的方式抓到。

对读者的意义在于：AI 写代码的比例在上升，而每个 Agent 处理安全审查的方式都不一样，很多干脆不处理。把审查从「人记得开 PR 时顺手做」变成「push 就自动跑」，是把安全从习惯问题变成默认配置。

怎么用

操作步骤不复杂，但每一步都有个容易忽略的点：

进 Vercel 的 Agent settings，找到 Security Reviews，打开 Review Deployments Automatically。
选项目：默认全部项目，也可以指定，最多 100 个。建议先挑一个仓库试跑。
想用 Vercel Agent 直接修，需要在同一页打开 Enable Chat，否则只能看不能修。
结果在哪看：Vulnerabilities 面板是主入口；每次审查会给对应 commit 加一个 GitHub check；私有仓或内部仓在有开着的 PR 时，还会把 findings 发成 PR 评论并链回详情。
两种修法：面板上点 Fix with Vercel Agent，它会先确认漏洞还在，再做最小改动并更新测试，最后开一个 PR 等你审；或者用 vercel security vulnerabilities 把 findings 拉下来，交给自己常用的编码 Agent 改（需要 Vercel CLI 65.10.0 及以上）。
团队策略可以直接用自然语言写，比如「任何返回客户数据的接口都必须校验请求者拥有该数据」。团队级在 Agent settings 配，项目级在项目的 Security 设置里配，也能用 vercel security policy 走 CLI。

适用场景

代码已经托管在 GitHub、并且用 Vercel 做预览/生产部署的团队，开个开关就能用。
团队里有强推生产分支、或 PR 流程不严格的习惯——这类路径平时最容易被漏掉。
让编码 Agent 参与写代码、但还没想好怎么把安全审查塞进流程的团队。
需要把安全事件接进 SIEM 的企业：每条新 finding 都会生成审计日志事件，Enterprise 可以通过 Audit Log Drains 转出去。

不适用场景

它只看源码，不做运行时检测，也不做渗透测试。官方明确写了这不是安全审计，也不能保证应用没有漏洞。想验证「线上真的打不穿」，还得另做测试。
目前只覆盖 GitHub push。用 Vercel CLI 部署、v0 生成的部署、以及不在 Vercel 上部署的仓库，都还没支持，官方说在路上。
公共仓库只发 GitHub check，findings 细节留在面板里——这是好事（避免公开泄露未修复漏洞），但也意味着外部贡献者看不到细节。

成本怎么算

这是最需要提前算的一项：它按 push 计费，不是按 PR。

价格是推理按底层模型的 token 原价、不加价，再加 Vercel 的 Token Rate：每百万 token 0.25 美元（输入、缓存输入、输出同价）。2026 年 11 月 10 日之前免费，之后开始计费；用 Vercel Agent 做的修复按 Vercel Agent 的费率另算。

换句话说，一个每天推几十次的小团队，和一个一天推两次的团队，账单结构完全不同。开之前先看一眼自己的推送频率，比看单价更有用。

注意事项

私有仓或内部仓的 findings 会以 PR 评论形式出现，能看到这个仓库的人都能看到，受众比面板更宽。如果仓库里混着外包或实习同学，需要提前说清楚。
首次审查没有 base，会读全量源码，第一次跑得慢、也可能一次性冒出较多历史问题，别被吓到。
同一个问题不会重复报：新 finding 会和已报过的比对，并且绑定到它第一次出现的那个部署，之后跟着环境变化走；某一轮不再检出时，会标成「不再检测到」，对应的 GitHub 评论自动关闭。
权限上，Owner、Member、Developer、Security 角色能看到所有项目；Contributor 只能看分配给自己的；Billing 和 Viewer 看不到。

第一步可以做什么

今天：挑一个改动频繁、又不是最核心的仓库，把 Security Review 打开，跑一周看误报率。
本周：把团队最在意的两类问题写成自然语言策略（越权访问、密钥泄露），比笼统地「多查点」有效。
之后：如果效果稳定，再全量铺开，并把审计日志接到现有的告警链路里。