Por que isso importa agora?

Olha só o cenário: times crescendo, agentes de IA criando projetos em segundos, e um monte de configuraçãozinha esquecida se acumulando. Um preview deployment público aqui, um token de API de longa duração ali... nada disso quebra o build, mas cada um aumenta sua superfície de ataque.

A Vercel respondeu com o Security Dashboard, agora GA (generally available) em todos os planos. Ele te dá uma visão única da sua postura de segurança em todas as contas e projetos, ordenada por risco. Você acessa pela UI ou dispara os mesmos checks pelo terminal com vercel security check.

O dashboard sinaliza coisas como:

  • Membros do time sem 2FA ativado
  • Credenciais de longa duração que podem virar OIDC federation
  • Preview deployments públicos
  • Variáveis de ambiente não-sensíveis e obsoletas

Cada achado linka direto pra tela de configuração onde você corrige. Achados que são só ruído pro seu time podem ser silenciados, e o relatório completo exporta pra CSV pra triagem ou compliance.

Se você curte entender como psicologia de produto influencia adoção de ferramentas, dá uma olhada nessa análise sobre behavioral design em UX.

Vercel Security Dashboard UI showing misconfigurations ordered by risk with fix links Technical Structure Concept

O CLI: feito pra agentes, não só pra humanos

A parte mais legal desse release é o comando vercel security check. Ele foi desenhado pra que agentes de IA leiam os achados, apliquem correções e re-verifiquem — um loop fechado que antes precisava de um humano no meio.

# Roda todos os checks de segurança na conta/time atual
vercel security check

# Limita o check a um projeto específico (mudança mais cirúrgica)
vercel security check --project meu-app

# Emite os achados em JSON pra consumo por agentes
vercel security check --findings

Em CI ou qualquer ambiente não-interativo, o comando escreve o relatório automaticamente em stdout como JSON — sem flag extra. Ou seja, seu pipeline consegue parsear falhas e abrir tickets, ou um agente consegue iterar nas correções.

Correções que um agente consegue aplicar programaticamente:

  • Ativar Git fork protection
  • Marcar variável de ambiente como sensível
  • Trocar credencial estática por OIDC federation

Um loop típico de agente fica assim:

# 1. O agente lê os achados estruturados
vercel security check --findings > findings.json

# 2. O agente parseia findings.json e aplica correções via API/CLI
# 3. O agente roda o check de novo pra confirmar
vercel security check --findings

Esse passo de re-check é o que faz a parada ser realmente útil — o agente não chuta, ele verifica.

Se você também mexe com performance no lado de GPU, o deep dive no CUB single-call API é uma boa leitura complementar sobre reduzir boilerplate em código de baixo nível.

Developer running vercel security check in terminal with JSON output for CI pipeline Software Concept Art

O que ele cobre — e o que ele não cobre

CheckAuto-fix por agenteObservações
2FA faltando no timeNãoPrecisa de ação do usuário
Credenciais de longa duraçãoSim (OIDC)Melhor candidato pra automação
Preview deployments públicosParcialDepende da config do projeto
Env vars obsoletas/não-sensíveisSimMarcar como sensível
Git fork protectionSimToggle via API

Limitações que você precisa saber

  • É um scanner de postura, não um WAF em runtime. Não pega injeção, SSRF nem falha de lógica na sua app.
  • Os achados são heurísticos. Um "preview deployment público" pode ser intencional num site de demo; silenciar é seu amigo, mas silenciar demais derrota o propósito.
  • Auto-fix por agente é poderoso mas arriscado. Se você deixar um agente ligar OIDC federation num projeto de produção sem revisão, pode se trancar pra fora. Coloque os fixes baseados em --findings atrás de um PR ou aprovação.
  • Saída JSON só em stdout no modo não-interativo — cuidado pra não vazar detalhes sensíveis nos logs públicos do CI.

Cloud security posture overview across multiple Vercel projects and team accounts Algorithm Concept Visual

Vale a pena ligar hoje?

Vale — o custo de rodar vercel security check uma vez é quase zero, e o primeiro scan geralmente acha pelo menos um token esquecido ou preview público perdido. Comece em modo leitura: roda o check, exporta CSV, triagem com o time, e só depois habilita fixes por agente pras categorias de baixo risco (sensibilidade de env var, fork protection).

Próximos passos

  1. Roda vercel security check no seu maior projeto primeiro.
  2. Pluga a saída JSON no CI como relatório não-bloqueante.
  3. Quando confiar no sinal, migra OIDC pra modo assistido por agente.
  4. Re-scan semanal — más configurações voltam conforme o time cresce.

Referência oficial: changelog do Vercel Security Dashboard.

Este conteúdo foi elaborado com o auxílio de ferramentas de IA, com base em fontes confiáveis, e revisado pela nossa equipe editorial antes da publicação. Não substitui o aconselhamento de um profissional especializado.