Vercel Security Review now scans GitHub repos without a linked Vercel project

Security Review no longer needs a Vercel project

Vercel has untied its Security Review feature from its own deployment platform. According to a changelog entry on the Vercel blog published November 13, 2026, the automated vulnerability scanner can now examine code changes in GitHub repositories that have no connection to a Vercel project — a connection that had been a prerequisite for using the tool.

Security Review exists to catch vulnerabilities in code as it changes. Historically that meant a repository first had to be attached to a Vercel project. Now, Vercel says, the scanner inspects commits inside the repository itself wherever the feature is switched on, with no project or deployment involved on the Vercel side.

How coverage and scoping work

The default scope is broad. Vercel states that Security Review will cover every unlinked repository the Vercel GitHub App can reach within a connected GitHub account. Teams that want a tighter footprint can limit coverage to particular connected accounts or down to individual repositories, with the relevant controls located in Agent settings.

Once the feature is on, the workflow runs itself: each push to a covered repository automatically kicks off a review of the changes it introduces. Repositories that are linked to Vercel keep the deeper integration. When a push also produces a deployment for a linked project with Security Review enabled, the review takes advantage of the extra context that the project and deployment provide, according to the changelog.

Setup is a two-step process, per Vercel: connect the GitHub account in the team's Git settings, then enable Security Review in Vercel Agent settings. The company's Security Review documentation carries the full walkthrough.

Why it matters

The change quietly repositions Security Review from a perk of deploying on Vercel into a general-purpose code scanner for GitHub repositories, and that shift has several practical consequences.

For teams whose code lives partly on Vercel and partly elsewhere, vulnerability scanning no longer stops at the edge of the Vercel deployment graph. Repositories that have never been deployed — internal tools, shared libraries, early experiments — can now be reviewed on every push, which moves security checks earlier in the development lifecycle instead of tying them to a deployment event.

The breadth of the default deserves attention, too. Because coverage applies to every unlinked repository the GitHub App can reach, teams with large GitHub organizations may find themselves scanning far more code than they intended unless they constrain the scope in Agent settings. Checking that configuration at rollout, rather than after the first flood of findings, is the sensible order of operations.

Finally, the move places Vercel more directly alongside general static-analysis and code-scanning tooling built for GitHub. By separating scanning from hosting, Vercel is competing for a slice of the repository security workflow that platform-agnostic tools have largely owned. It also gives teams one more reason to grant the Vercel GitHub App wide access — a permissions decision that now carries scanning implications alongside deployment ones.