Vercel Security Review scans GitHub pushes
Vercel launched Security Review in public beta on November 2. It checks code pushed to connected GitHub repositories, including changes sent directly to production branches.
Spec sheet
- Availability
- Public beta, Pro and Enterprise
- Introductory offer
- Reviews free until November 10; fixes billed
- Policy limit
- 32,000 characters
Review follows the push
The service examines changed code against a base, usually the branch’s preceding deployment. Vercel says the agent follows reachable code and checks existing protections before reporting a potential vulnerability. The company charges provider inference costs without a markup, plus twenty-five cents per million tokens.
Scope and disclosure differ by repository
The operational documentation gives the first review a different scope: when no comparison base exists, it reads the full source. In a monorepo, each project’s root directory bounds its review. Administrators can select all projects or a list of up to one hundred. Enabling reviews requires the Owner role. The documentation distinguishes a missing deployment from a missing comparison base. If no previous deployment exists, it falls back to GitHub’s API. Pull-request reviews without a deployment are tracked against the branch and pull request. Fixing findings through Vercel Agent also requires its chat capability to be enabled in team settings.
Findings may contain confidential code and other sensitive information from the reviewed files. Owners, Members, Developers and the Security role can see findings across projects. Contributors are limited to assigned projects, while Billing and Viewer roles see none. Repository access creates another audience: private or internal pull-request comments can reveal finding details to anyone who can read that repository. Public repositories receive a check and dashboard link instead of public vulnerability details. That distinction matters when a repository’s readership is broader than the team that normally triages security reports.
A closed finding is not a verified fix
The management guide separates dismissal from closure. Dismissal records a human decision that a finding does not need action. Closure happens when a subsequent review stops detecting the issue; it is not confirmation that the vulnerability has been repaired. Severity labels are also generated estimates, not scores from a fixed rubric. Agent-assisted remediation opens a pull request against the affected branch, and does not merge it automatically. Team and project policies add plain-language review context, with project instructions supplementing the team policy. They can describe a threat model, focus attention on sensitive areas or exclude irrelevant issues. They do not override the reviewer’s core vulnerability-finding behavior. A changed policy only affects reviews started after it was saved. Because policy changes can suppress findings, a cleaner dashboard after an instruction change is not necessarily evidence of a safer application.
Claim check
Sources
- Introducing Vercel Security Review · Vercel · 2 Nov
- Security Review · Vercel · 30 Oct
- Managing Security Reviews · Vercel · 30 Oct