Vercel公测推送即触发的安全审查

Vercel 把安全检查接到了 GitHub 的每次 push 上：开启 Security Review 后，关联仓库的代码变更会自动接受漏洞审查，结果集中进入 Vulnerabilities 仪表盘。目前，这项功能面向 Pro 和 Enterprise 团队开放公测。

这次值得看的，是它把发现问题、提交修复和人工审批串成了一条流程。但它检查的是源码，不提供运行时验证，也不能替代安全审计。是否适合接入，要一起看覆盖范围、结果可信度和按 push 累积的成本。

为什么从 push 触发，而不是只盯着 PR

Security Review 的触发点是向关联 GitHub 仓库推送代码，而不是创建拉取请求（PR）。

这个区别很实际：直接向生产分支 push，或者 force push，同样会触发审查。如果团队只在 PR 上挂检查，绕过 PR 的提交就可能绕过这道流程。以 push 为入口，可以覆盖这类代码变更。

一次 push 影响多个项目时，所有受影响项目会一起审查。不过，原文没有解释如何识别受影响项目，也没有说明「一起审查」是否包含跨项目的数据流分析，不能据此推断它能发现跨服务漏洞。

每条发现都会记录项目、环境、分支和 commit，并提供问题摘要、建议修复方式，以及 AI 生成的严重程度评级。Security Review 还会为审查过的 commit 添加独立的 GitHub check；存在 PR 时，会通过 review comments 反馈问题，并链接到对应发现。

公开仓库有一项特殊处理：漏洞详情保留在仪表盘里。原文没有进一步说明公开 GitHub check 会展示哪些信息。

发现漏洞之后，修复还要经过谁

在漏洞报告里点击 Fix with Vercel Agent，系统会把问题交给 Vercel Agent，由它提出修复并创建 PR，供团队审核。修复不会在你批准之前合并。

如果已有自己的 coding agent，也可以通过 Vercel CLI 的 vercel security vulnerabilities 获取发现，或者把单条发现复制成 Markdown、JSON。这个 CLI 命令要求 Vercel CLI 65.10.0 或更高版本。

这里提供的是两条处理路径：让 Vercel Agent 创建修复 PR，或者把发现交给现有工具处理。原文没有给出修复成功率，也没有说明修复后是否自动复检，因此不能把「生成了修复」等同于「漏洞已经消除」。

团队还能用自然语言编写安全策略，补充项目的开发约束。团队策略在 Agent settings 设置，项目策略在项目的 Security settings 设置；策略可以覆盖全部项目，也可以针对特定项目。

这有助于审查理解团队上下文，但原文没有交代策略冲突如何处理，以及策略会怎样影响问题判定。

每次 push 都检查，账该怎么算

Security Review 按 Vercel Agent 费率计费，包含两部分：

• 模型提供商的推理费用按底层 token 费率收取，不加价。
• 另收 Vercel Token Rate，每百万 token 为 0.25 美元，涵盖输入、缓存和输出 token。

因此，成本与 push 频率、代码改动量有关。原文没有给出单次审查的 token 消耗、典型项目账单，也没有说明每次读取多少上下文，目前无法据此估算普通团队的月度开销。

公告称，安全审查免费至 2026 年 11 月 10 日；使用 Vercel Agent 进行修复，仍按 Vercel Agent 费率收费。试用时要把「审查」和「修复」分开核算。

我的判断

我认可它的流程设计：检查覆盖直接推送，发现能关联到具体 commit，修复进入 PR，最后由人审批。这些安排能减少安全问题在工具之间流转的摩擦。

但这篇公告证明了功能如何接入，没有证明它查得多准。作者没有提供漏洞检出率、误报率、漏报率，也没有与传统静态扫描工具给出对照数据。AI 严重程度评级应当作为排查线索，仍需要结合代码和实际影响复核。

对于前端、Node 或全栈项目，它适合增加一道源码检查。现有依赖漏洞扫描、测试和人工审查仍各有作用。原文也明确承认：它不是安全审计，不做运行时或渗透测试，更不保证应用没有漏洞。

能拿来做什么

• 已经使用 Vercel Pro 或 Enterprise 的团队，可以在团队 Agent settings 开启试用，重点观察直接 push、force push 和 PR 提交是否都能进入审查流程。
• 有现成 coding agent 工作流的团队，可以升级到 Vercel CLI 65.10.0 或更高版本，用 vercel security vulnerabilities 获取发现，或通过 Markdown、JSON 交接，再人工核对修复。
• 可以先为一个项目补充自然语言安全策略，并在试用期记录发现是否有效、修复是否可用及审查成本，再决定扩大覆盖范围。