Confirmed limitVercel says Security Review is source-code analysis, not a security audit, runtime assessment or guarantee that an application is free of vulnerabilities.
The Vercel Security Review public beta runs on every GitHub push
Vercel's November 3 changelog says the public beta is available to Pro and Enterprise teams. Once enabled, every push to a connected GitHub repository triggers a review, including direct and force pushes to the production branch.
If one push affects several Vercel projects, the review considers those projects together. Vercel says it compares the change with the previous deployment or base, then examines changed code and relevant surrounding code.
That makes the unit of analysis important. A one-line authorization change can be reviewed in context, but unchanged code elsewhere is not automatically a fresh whole-repository audit.
| Question | Security Review can provide | Separate control still needed |
|---|---|---|
| Did this push introduce a code-level issue? | Analysis of changed source and surrounding context | Human review and project tests |
| Is the whole repository secure? | No complete-repository assurance | Architecture review and targeted audit |
| Is the running application exploitable? | No runtime or penetration test | Runtime monitoring and security testing |
| Is a dependency known to be malicious? | Not the announced purpose of this feature | Lockfile, audit and package controls |
| May this finding block release? | A GitHub check and review evidence | A team-owned release and escalation rule |
Findings appear beside the commit and pull request
Each finding includes the affected project, environment, branch and commit, plus a summary, suggested fix and AI-generated severity. Vercel adds a GitHub check to the commit and can place findings on a pull request as review comments.
For a missing authorization check in an API route, an engineer can see the finding beside the changed line instead of discovering it in a separate monthly report. The Vercel dashboard remains the place to manage the broader finding history.
“Fix with Vercel Agent” can propose code and open a pull request, but nothing merges without approval. Inspect the assumption and verify the affected permission path.
The feature can catch logic mistakes that pattern scanners miss
Vercel's product announcement positions the review around application logic and code context, not only known string patterns. Its example is a missing authorization check, where valid code becomes unsafe because the wrong user can reach it.
Imagine a new route fetches an invoice by ID but never verifies that the invoice belongs to the signed-in account. A conventional syntax check may see valid code. A contextual review can flag the relationship between authentication, resource ownership and the new query.
AI-generated severity and fixes still need human triage. Record false positives, later misses and findings that changed a release decision.
Vercel explicitly limits the review to deployment changes
The Vercel Service Terms say Security Review analyzes changes associated with a deployment, not the entire repository. They also say findings are not a security audit, may miss vulnerabilities and use an AI estimate for severity.
A finding marked resolved or no longer detected is not proof that the vulnerability was fixed. The relevant line may have changed while an equivalent flaw remains elsewhere. Verify the behavior with a test or manual review before closing the issue.
Vercel can use plain-language team policies during review, but its terms do not guarantee compliance. Keep critical rules in enforceable permissions, tests and configuration.
Cost and visibility need a small controlled trial
Vercel says reviews are free until November 10, 2026. After that, usage is billed at the underlying model provider's inference rate without markup, plus $0.25 per million Vercel tokens. Agent-generated fixes are billed separately as agent usage.
Run a representative week on one repository and observe reviews, findings, tokens and triage time. Automated pushes can create a different cost and noise profile from reviewed pull requests.
Findings can appear in GitHub surfaces visible to people with repository access. Test a non-sensitive branch and confirm where details appear before expanding access.
Place the new review beside existing deployment controls
Security Review adds one source-code signal. Keep dependency protection, framework updates, access tests, secret handling, runtime monitoring and incident response as separate controls.
Vercel's automatic malicious npm package blocking addresses listed dependency versions during builds. The Next.js security release guide covers framework patching. Neither answers whether a new route forgot an authorization check, which is where contextual code review may help.
Assign the operational response before expanding the beta. A website maintenance agreement should name who receives a finding, who can delay release and how a false positive is documented.
Test these items before relying on Security Review
Enable the beta on one non-critical GitHub-connected project and use a normal change, not a staged vulnerability, to observe the complete workflow. Then check the following evidence.
- Every expected push triggers one review across the affected Vercel projects.
- The GitHub check and pull-request comments reach the people who own triage.
- Finding details, severity and suggested fixes are reviewed by a person.
- A proposed agent fix opens a pull request and cannot merge without approval.
- The team can distinguish a dismissed finding from a verified fix.
- Review usage and triage time are visible before the free period ends.
- Runtime, dependency, secret, framework and incident controls remain active.