Vercel安全审查公测：每次推送自动扫描漏洞

Vercel 正在把安全能力前移到代码推送环节。其 Security Review 功能已面向 Pro 和 Enterprise 团队开放公测，开启后，每次向已连接的 GitHub 仓库推送代码，系统都会自动审查漏洞，并把结果汇总到 Vulnerabilities 仪表盘。

这件事的意义不在于多了一个扫描工具，而在于触发时机和交付方式的变化——安全审查从"上线前的一道检查"变成了"每次提交的默认动作"。

从推送事件出发，而不是拉取请求

多数代码安全工具以 Pull Request 为触发点，这留下了一个显而易见的盲区：直接推送和强制推送。Vercel 的做法是从 GitHub push 事件启动审查，因此直接推送到生产分支、以及 force push 的代码同样会进入审查范围。一次推送影响到的所有项目会被合并在一起审查，而不是逐个项目排队。

这个设计选择很务实。团队里真正危险的提交，往往不是那些走了完整 PR 流程的改动，而是紧急修复时绕过评审直接推上生产的那几行代码。

GitHub push 事件与 GitHub Checks

GitHub 的 push 事件是仓库收到新提交时触发的 webhook，payload 中包含被推送的 commit、分支、强制推送标志（forced）等信息。相比 Pull Request 事件，push 事件同样覆盖直接推送和 force push——GitHub 在被强制覆盖的分支上仍会记录旧 ref 与新 ref 的差异，外部服务据此能取得本次推送涉及的实际提交集合。GitHub Checks 则是挂在某个 commit 上的状态与输出载体：外部工具可以为一个 SHA 创建 check run，写入标题、摘要、结论（success/neutral/failure）和详情链接，结果直接显示在 PR 的 Checks 标签页和 commit 列表中。这解释了为什么同一次推送要合并审查：一次 push 可能同时影响多个 Vercel 项目，但只有一条 commit 可供挂载 check。

一条漏洞记录里有什么

每条 finding 都会记录项目、环境、分支和 commit，并附带一段摘要、一个建议修复方案，以及由 AI 生成的严重程度评级。

Security Review 会为每个被审查的 commit 添加一个独立的 GitHub check。如果这次提交关联了 PR，它还会把发现以 review comment 的形式贴出来，并链接回对应的 finding 详情。公开仓库则不同：finding 的具体细节保留在仪表盘内，不会外露。

修复路径：交给 Vercel Agent 或你自己的工具

在漏洞报告中点击 "Fix with Vercel Agent"，这条 finding 会被交给 Vercel Agent，由它提出修复方案并开一个 PR 供你审阅——在你批准之前，没有任何东西会被合并。

如果你更愿意用自己的编程助手处理，有两条路：在 Vercel CLI 中执行 vercel security vulnerabilities，或者把任意 finding 复制为 Markdown 或 JSON。CLI 命令要求 Vercel CLI 65.10.0 或更高版本。

这种不锁定工作流的态度值得肯定：审查结果不是只能在一个封闭面板里消费，而是可以流进团队已有的 agent 或工单系统。

Vercel Agent 与 Vercel CLI 的角色

Vercel Agent 是 Vercel 平台内具备自主执行能力的 AI 代理，可以读写仓库内容、创建分支并提交变更，因此它能把一条漏洞 finding 转化为待审阅的 Pull Request。它采用的是典型的 agent 流程：读取 finding 上下文（涉及的文件、行、漏洞摘要）→ 定位代码 → 生成补丁 → 以分支和 PR 形式交付，人工仍保留合并决策权。Vercel CLI 则是本地命令行工具，vercel security vulnerabilities 属于 65.10.0 起新增的子命令，用于在终端中拉取并列出漏洞记录，方便脚本化处理或交付给外部编程助手；把 finding 导出为 Markdown 或 JSON 则是另一条无 API 依赖的路径，适用于接入工单系统或自建流水线。

用自然语言写安全策略

团队可以用自然语言编写安全策略，作用于全部项目或指定项目，目的是让 Security Review 更了解团队的构建方式。团队级策略在 Agent 设置中配置，项目级策略则在项目的 Security 设置中配置。

给审查引擎补充上下文，是降低误报的常见思路。代码扫描的痛点从来不是找不到问题，而是找到太多无关紧要的问题，让真正的风险淹没在噪音里。

误报抑制与审查上下文

静态代码扫描的误报通常来自缺少上下文：引擎不了解某些输入已被上游校验、某些代码路径只在内部使用、或团队有意的模式（例如把用户输入交给模板引擎而非直接拼接）。自然语言策略的作用相当于给引擎注入这类先验知识，让它区分真实风险和团队已知的约定。行业中常见做法包括：在规则配置里为特定路径或模式添加排除项、使用 // nosec 之类的内联抑制注释、或维护基线文件只报告新增问题。用自然语言描述策略降低了配置门槛，但效果依赖模型对描述的理解，策略越具体（指明哪些入口参数可信、哪些内部接口不对外暴露）越能减少噪音。

边界与计费

Vercel 对能力边界说得比较直白：Security Review 分析的是源代码，它不是安全审计，也不做运行时测试或渗透测试。它能帮你发现漏洞，但不保证应用没有漏洞。把它当成一道自动化的早期防线，而不是合规凭证。

计费按 Vercel Agent 费率执行：provider 推理按底层 token 费率计费且不加价，另加每百万 token 0.25 美元的 Vercel Token Rate（输入、缓存、输出均计入）。由于每次推送都会触发审查，成本会随推送频率和代码变更量增长。

目前审查本身免费，该状态持续到 2026 年 11 月 10 日；使用 Vercel Agent 生成的修复则按 Agent 费率计费。

Vercel Agent 的 token 计费方式

Agent 类功能按模型推理消耗的 token 计费：输入 token（送进模型的上下文，包含代码片段、策略与 finding 信息）、缓存 token（命中提示词缓存的部分，通常有折扣）、输出 token（模型生成的分析与补丁）。Vercel 声明 provider 推理按底层模型的原价计费、不加价，另叠加每百万 token 0.25 美元的 Vercel Token Rate，作为平台侧的费用。由于每次 push 都触发审查，且审查范围随 diff 大小线性增长，成本与推送频率、单次变更规模直接相关；大仓库频繁推送时，需要结合免费期结束后的定价估算实际支出。

谁适合先开

推送频繁、生产分支保护不严、又已经在用 Vercel 部署的团队，收益最直接——不需要改动 CI 配置，打开开关就多了一层覆盖。反过来，如果团队本就对每次推送有严格的门禁和人工评审，这项功能的边际价值更多体现在 AI 生成的严重程度评级和修复建议上。

功能在团队的 Agent 设置中开启，详细说明可查阅官方文档与公告。