Vercel lança Security Dashboard para auditar configurações de projetos em produção
Disponível em todos os planos, a ferramenta lista más configurações por severidade na UI ou pelo CLI, com o comando vercel security check pronto para agentes aplicarem correções.
A Vercel anunciou no dia 26 de agosto de 2026, via changelog oficial, a disponibilidade geral (GA) do Security Dashboard, uma ferramenta de auditoria de postura de segurança que passa a estar em todos os planos, inclusive o gratuito. A proposta é reunir num só lugar o estado de segurança de cada conta e projeto hospedado na plataforma, algo que antes ficava espalhado por várias telas de configuração ou simplesmente não era monitorado.
O recorte do problema é honesto e reconhecível para quem trabalha com Next.js↳Next.js2 conteúdosImersão React: Alura realiza aulas gratuitas com foco em Next.JSGestão Dev & TI · jan 2021Criando sua primeira aplicação com RemixDev (Back & Front) · set 2024Ver tudo em Dev (Back & Front) → e front-end em escala: conforme os times crescem e os agentes de código aceleram a criação de projetos, pequenas configurações erradas se acumulam sem ninguém perceber. Um preview deployment que ficou público, uma variável de ambiente que deveria ser sensível e não foi marcada, um membro do time sem 2FA. Nenhum desses itens derruba a aplicação, mas todos ampliam a superfície de ataque de forma silenciosa.
O que a ferramenta flagra
O Security Dashboard varre a conta em busca de más configurações e as ordena por risco, das mais severas para as menos. Entre os achados que ele detecta automaticamente estão:
- Membros do time sem 2FA habilitado;
- Credenciais de longa duração que poderiam ser substituídas por OIDC (federação de identidade, que gera tokens de curta duração em vez de segredos estáticos);
- Preview deployments públicos, ou seja, ambientes de pré-visualização acessíveis por qualquer um com a URL;
- Variáveis de ambiente não marcadas como sensíveis e variáveis obsoletas (stale).
Cada finding na interface tem link direto para a tela de configuração que resolve o problema, o que reduz o atrito entre descobrir e corrigir. Achados que são apenas ruído para o time podem ser silenciados (muted), e todo o resultado pode ser exportado em CSV para triagem ou relatório. Esse detalhe do CSV é o que aproxima a ferramenta de fluxos de compliance: dá para anexar a evidência num processo de auditoria ou levar para uma conversa de resposta a incidente sem precisar tirar print de tela.
O ângulo que importa: o CLI e os agentes
A parte mais interessante do anúncio, do ponto de vista de automação, é o novo comando de CLI. Rodar vercel security check no terminal executa exatamente as mesmas verificações da interface e imprime a lista completa de más configurações ali mesmo.
O que muda o jogo é o desenho pensado para agentes de código. Com vercel security check --findings, um agente consegue ler o que falhou, aplicar a correção e rodar de novo para confirmar. A Vercel lista correções que um agente já é capaz de aplicar sozinho:
- Ligar a proteção contra forks no Git (Git fork protection);
- Marcar uma variável de ambiente como sensível;
- Substituir uma credencial estática por federação OIDC.
Para mudanças mais cirúrgicas, dá para restringir a verificação a um projeto específico com --project, gerando um conjunto de alterações mais enxuto. E o detalhe que faz diferença em pipeline: em ambiente de CI ou qualquer contexto não interativo, o comando escreve o relatório em JSON no stdout automaticamente, sem precisar de flag extra. Isso significa que a saída já vem estruturada para ser consumida por outro processo, seja um agente, seja um step de GitHub Actions que quebra o build se houver achado crítico.
Na prática, o fluxo mínimo para começar é rodar o primeiro scan pela interface do dashboard ou disparar o comando localmente:
vercel security check
# saída estruturada para automação
vercel security check --findings
# limitando a um único projeto
vercel security check --project meu-appPor que isso importa para o dev brasileiro
O cenário descrito pela própria Vercel, projetos nascendo rápido demais por causa de agentes, é exatamente o que muitos times por aqui vivem hoje. A promessa de "security shift-left" costuma esbarrar na falta de uma ferramenta que já esteja onde o deploy acontece. Ter a checagem embutida na plataforma de hospedagem, sem instalar scanner de terceiros nem manter uma integração à parte, baixa bastante a barreira para incluir segurança no fluxo de trabalho.
Há dois usos claros. O primeiro é compliance: o export em CSV e a ordenação por severidade dão o material bruto para relatórios exigidos em auditorias, algo relevante para quem lida com dados sensíveis ou precisa demonstrar controles a clientes. O segundo é resposta a incidentes: quando algo dá errado em produção, ter um inventário rápido de más configurações abertas ajuda a reduzir o tempo até identificar o que estava exposto.
A integração com agentes também casa com a direção que a própria Vercel vem tomando, com o Agent Stack e o Vercel Agent. A ideia de que um agente leia os findings em JSON, aplique a correção e revalide é o tipo de automação que, se funcionar bem, economiza o trabalho tedioso de caçar toggle por toggle nas configurações.
Trade-offs e o que fica em aberto
Algumas ressalvas valem antes de tratar isso como bala de prata. A ferramenta é específica da Vercel: ela audita a postura da conta e dos projetos na plataforma, não o código da aplicação. Não é um SAST, não substitui análise de dependências, não olha vulnerabilidades no seu bundle nem em bibliotecas. Ela cobre a camada de configuração de plataforma, que é importante mas é só uma fatia da segurança de uma aplicação real.
Para quem não hospeda na Vercel, obviamente não há nada aqui, e o lock-in é o custo implícito: quanto mais o time apoia seu processo de segurança nesse dashboard, mais amarrado fica à plataforma. Vale também um olhar crítico sobre delegar correções a agentes: vercel security check --findings aplicando fixes automaticamente é conveniente, mas trocar uma credencial estática por OIDC ou ligar fork protection são mudanças que podem afetar deploys em andamento. Em ambientes críticos, faz sentido revisar o changeset do agente antes de mergear, e não deixar a correção automática rodar sem supervisão.
A documentação completa e o passo a passo para o primeiro scan estão na página de docs do Security Dashboard referenciada no anúncio. O material da Vercel não detalha ainda com que frequência as verificações rodam automaticamente nem se há alertas proativos quando uma nova má configuração surge entre scans, algo que faria diferença para monitoramento contínuo em vez de checagem sob demanda.
Fonte: Vercel Changelog
Este artigo foi escrito por Carina Ferreira, colunista de front-end do iMasters, um agente de inteligência artificial com revisão editorial humana. Publicado sob revisão editorial de Rafael Chinaglia - iMasters e validação técnica de Tiago Rosa. Saiba como produzimos no expediente.











Comentários
Ninguém comentou ainda. Começa a conversa?