Vercel Security Review integra varredura de vulnerabilidades a cada push no beta público

A Vercel colocou em beta público o Security Review, recurso disponível para times nos planos Pro e Enterprise que varre automaticamente o código em busca de vulnerabilidades. Segundo o changelog oficial da Vercel, uma vez habilitado, toda alteração enviada a um repositório GitHub conectado passa por essa análise, e os achados vão parar num painel de Vulnerabilidades dentro do dashboard do time.

O detalhe que interessa a quem vive de pipeline é o gatilho escolhido: não é a pull request, é o push. Isso muda o que o recurso enxerga.

Da revisão em pull request para a revisão a cada push

A maioria das ferramentas de análise estática que um time de front-end↳Front-end60 conteúdosFront-end em larga escala: quando seu projeto vira um Frankenstein (e como evitar)Dev (Back & Front) · mar 2026Build e bundling no front-end: 7 decisões que impactam performance de verdadeDev (Back & Front) · abr 2026Como modelar APIs pensando no front-end: 8 práticas para evitar retrabalho entre timesDev (Back & Front) · abr 2026Ver tudo em Dev (Back & Front) → já conhece roda em cima de pull requests: abriu PR, disparou o check. A Vercel Security Review inverte a lógica e reage a eventos de push. Na prática isso cobre um ponto cego comum: push direto ou forçado na branch de produção, sem passar por PR nenhuma, também é revisado.

Outro detalhe de arquitetura importa para quem trabalha com monorepo: quando um único push afeta vários projetos dentro do time, todos eles são revisados juntos, e não isoladamente a cada deploy individual. Isso significa que um push grande pode gerar uma leva de achados de uma vez só para triagem.

O que entra em cada achado

Cada vulnerabilidade reportada no dashboard vem com um pacote de contexto, não só um alerta solto:

• Projeto, ambiente, branch e commit exatos onde o problema apareceu
• Um resumo do que foi encontrado
• Uma sugestão de correção
• Uma classificação de severidade gerada por IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →

A Security Review também adiciona o próprio check do GitHub a cada commit analisado. Quando existe uma pull request envolvida, os achados aparecem como comentários de revisão linkados de volta ao item no dashboard. Em repositórios públicos, por outro lado, o detalhe completo do achado fica só dentro do dashboard da Vercel, sem exposição no próprio PR público, o que é uma decisão sensata para não publicar um roteiro de exploração junto do código aberto.

Dois caminhos para corrigir: o agente da Vercel ou o seu

Para quem quer resolver sem sair do fluxo, clicar em "Fix with Vercel Agent" num achado entrega o problema ao Vercel Agent, que propõe uma correção e abre uma pull request. Nada é mesclado automaticamente: a PR fica esperando aprovação humana, o que preserva o controle do time sobre o que entra em produção.

Quem já usa outro agente de código (Copilot, Cursor, Claude Code, o que for) não fica refém do agente da Vercel. O comando vercel security vulnerabilities na Vercel CLI expõe os achados para alimentar qualquer assistente externo, e também dá para copiar um achado específico como Markdown ou JSON e colar onde for preciso. Esse comando exige Vercel CLI na versão 65.10.0 ou superior, então times que ainda rodam uma CLI mais antiga em pipeline vão precisar atualizar antes de usar o fluxo via terminal.

Políticas de segurança em linguagem simples

Um ponto que separa esse recurso de um linter de segurança genérico é a possibilidade de escrever políticas em linguagem natural para dar contexto sobre como o time constrói software. Dá para definir uma política de time, válida para todos os projetos, nas configurações de Agent, e políticas específicas por projeto, nas configurações de Security de cada um.

Na prática, isso serve para coisas como avisar que determinada rota é intencionalmente pública, que um padrão específico de autenticação é o esperado no time, ou que certa biblioteca legada tem um workaround conhecido que não deve ser sinalizado toda vez. É a tentativa da Vercel de reduzir falso positivo sem exigir configuração em formato estruturado, algo que normalmente é o ponto fraco de ferramentas de SAST tradicionais.

O que a ferramenta promete e o que ela não promete

A própria documentação da Vercel é direta sobre o limite do recurso: Security Review analisa código-fonte. Não é uma auditoria de segurança, e não faz teste de runtime nem pentest. Ajuda a encontrar vulnerabilidades, mas não garante que a aplicação esteja livre delas.

Isso importa porque é fácil ler "revisão automática de segurança a cada push" e assumir que o time ganhou uma rede completa. Não ganhou. O que existe é uma camada de análise estática integrada ao fluxo de deploy, útil para pegar o que passaria despercebido numa revisão de código apressada, mas que não substitui teste de penetração, revisão de infraestrutura ou análise de comportamento em produção. Times que lidam com dado sensível continuam precisando de uma camada de segurança mais profunda ao lado disso.

O preço depois do período gratuito

O modelo de cobrança segue a mesma lógica já usada pelo Vercel Agent: inferência do provedor de IA pelo preço de token do próprio provedor, sem markup da Vercel, mais uma taxa própria chamada Vercel Token Rate.

Como cada push dispara uma nova análise, o custo escala com a frequência de push e o volume de código alterado, não com o número de deploys. Até 10 de novembro de 2026 as revisões de segurança são gratuitas; só a correção feita com o Vercel Agent já é cobrada desde já pela taxa do Vercel Agent. Depois dessa data, times com hábito de muitos commits pequenos e pushes frequentes, algo comum em squads de front-end que fazem deploy contínuo, vão sentir o custo entrar na conta de uso da plataforma junto com build e função serverless.

Para quem avalia adotar, o cálculo prático é simples: o recurso vale a pena se o time já confia em revisão automatizada de código e quer um gate a mais sem reescrever pipeline, mas pedir pra rodar em todo push de todo repositório sem pensar no volume de commits pode transformar uma ferramenta de segurança numa linha extra relevante na fatura.

Fonte: Vercel Changelog