Com Que Frequência Você Deve Escanear seu Site em Busca de Vulnerabilidades?

A resposta direta: continuamente, não uma vez por ano

Para a maioria das pequenas e médias empresas, a frequência correta para escanear um site em busca de vulnerabilidades é contínua, com scans automatizados rodando pelo menos uma vez por semana, além de um scan imediato após cada novo deploy de código ou mudança relevante de configuração. Um scan anual, ou pior, um scan único feito antes do lançamento do site, deixa a empresa exposta por meses a vulnerabilidades que sequer existiam na última verificação.

Esse não é um número usado para vender mais scans. Ele reflete como o cenário de ameaças realmente se move. Novas vulnerabilidades são divulgadas todos os dias, o código do site muda constantemente, e atacantes usam ferramentas automatizadas para encontrar sistemas expostos poucas horas depois de uma nova falha se tornar pública. Um scan é uma fotografia: no momento em que termina, já começa a ficar desatualizado.

Por que isso importa para pequenas e médias empresas

Grandes empresas costumam rodar scans diários, ou até contínuos, porque têm times de segurança dedicados e orçamento compatível. Pequenas empresas costumam presumir que podem fazer menos porque são "pequenas demais para serem alvo". Essa suposição está invertida, e é um dos motivos mais comuns pelos quais PMEs sofrem violações de dados.

Segundo o Data Breach Investigations Report da Verizon, pequenas empresas participam de uma fatia grande e crescente das violações confirmadas todos os anos, e os atacantes automatizam cada vez mais o reconhecimento de alvos em vez de escolher vítimas manualmente. Um plugin de WordPress vulnerável, um painel de administração exposto ou um framework sem atualização é encontrado por um bot de varredura, não por uma pessoa decidindo que sua empresa vale o esforço. A frequência do scan é sua principal defesa contra ser pego por essa automação.

Existe também o problema do custo do atraso. O IBM Cost of a Data Breach Report mostra, ano após ano, que violações que demoram mais para ser identificadas e contidas custam significativamente mais do que as detectadas rapidamente. No Brasil, o custo médio de uma violação de dados chega a R$ 7,19 milhões, segundo dados da IBM. Uma vulnerabilidade que fica onze meses sem correção porque só foi verificada uma vez por ano é uma vulnerabilidade com onze meses de janela para ser explorada, vendida em um fórum da dark web, ou combinada com outra falha para gerar uma violação completa.

Há ainda o fator LGPD: sob a Lei Geral de Proteção de Dados, a ANPD espera que empresas adotem medidas técnicas e administrativas proporcionais ao risco para proteger dados pessoais. Um programa de scan de vulnerabilidades frouxo, com verificações esporádicas, é justamente o tipo de lacuna que a ANPD investiga em caso de incidente.

Como pensar a frequência de scan por cenário

Situações diferentes pedem cadências diferentes. Use isto como referência prática e ajuste para cima, nunca para baixo, de acordo com seu perfil de risco.

Linha de base: scans automatizados semanais

Todo site ou aplicação web voltada ao público deve ter um scan de vulnerabilidades automatizado rodando pelo menos uma vez por semana. Isso captura:

• CVEs recém-divulgadas afetando seu CMS, plugins ou frameworks
• Desvios de configuração introduzidos por manutenções de rotina
• Certificados SSL expirados ou serviços recém-expostos
• Regressões, quando um problema já corrigido volta a aparecer

Semanal é o mínimo que mantém sua janela de exposição medida em dias, não em meses.

Após cada deploy

Toda vez que código for enviado para produção, seja uma nova funcionalidade, uma correção de bug ou a atualização de um plugin de terceiros, rode um scan imediatamente depois. Deploys são o momento mais comum em que novas vulnerabilidades são introduzidas, porque novos caminhos de código, novas dependências e novas opções de configuração chegam todos ao mesmo tempo.

Após adicionar nova infraestrutura

Novos subdomínios, ambientes de staging deixados publicamente acessíveis, novos endpoints de API e integrações de terceiros recém-conectadas ampliam o que os atacantes conseguem atingir. Cada adição à sua superfície de ataque deveria disparar descoberta e scan, em vez de esperar o próximo ciclo agendado.

Imediatamente após uma CVE divulgada que afete sua stack

Se uma vulnerabilidade crítica for divulgada publicamente em uma tecnologia que você usa (o núcleo de um CMS, um plugin popular, um servidor web), não espere o ciclo semanal. Escaneie imediatamente. Atacantes agem poucas horas após a divulgação pública, e sua empresa precisa agir na mesma velocidade.

Antes e depois de grandes eventos de tráfego

Lançamentos de produtos, campanhas de marketing e datas sazonais (Black Friday, Natal) atraem tanto tráfego legítimo quanto atacantes oportunistas. Escaneie nos dias anteriores para confirmar uma base limpa, e novamente logo depois para capturar qualquer coisa introduzida sob a pressão de um lançamento apressado.

O que um scan realmente precisa cobrir

Frequência só ajuda se o scan em si for completo. Um scan raso rodando todo dia é menos útil que um scan abrangente rodando semanalmente. Garanta que sua abordagem de scan verifique:

1. Problemas do OWASP Top 10 — injeção de SQL, cross-site scripting (XSS), falhas de autenticação, configurações inseguras e as demais categorias padrão da indústria
2. CVEs conhecidas no seu CMS, plugins, frameworks e qualquer software do qual seu site dependa
3. Configurações inseguras — painéis de administração expostos, credenciais padrão, listagem de diretórios habilitada, cabeçalhos de segurança ausentes
4. Subdomínios, não apenas o domínio principal — sites de staging esquecidos e páginas antigas de marketing são pontos de entrada comuns
5. Configuração SSL/TLS — certificados expirados ou fracos comprometem qualquer outro controle que você tenha implementado

Erros comuns a evitar

• Escanear uma vez antes do lançamento e nunca mais. Um site nunca está "pronto". Cada atualização é uma nova chance de uma vulnerabilidade entrar.
• Escanear apenas o domínio principal. Subdomínios, ambientes de staging e microsites antigos de marketing são frequentemente esquecidos e frequentemente explorados.
• Tratar um scan limpo como garantia permanente. O resultado de um scan é válido para o momento em que roda. Novas CVEs são divulgadas todos os dias contra exatamente as stacks de software que a maioria das empresas usa.
• Esperar uma auditoria de compliance para disparar o scan. Scans anuais motivados por compliance são um piso mínimo, não uma estratégia. Existem para satisfazer auditores, não para impedir atacantes.
• Ignorar achados de severidade baixa e média. Atacantes costumam encadear vários problemas "menores" para alcançar um resultado crítico. O que parece baixo risco isoladamente nem sempre é baixo risco combinado.
• Não escanear após atualizações de plugins ou dependências de terceiros. Atualizações corrigem alguns problemas e, ocasionalmente, introduzem novos. Toda atualização merece uma verificação de acompanhamento.

Como a Volturion ajuda

A Volturion executa scans de vulnerabilidades automatizados em um cronograma recorrente compatível com seu plano, para que sua janela de exposição nunca se estenda por meses. Cada scan verifica problemas do OWASP Top 10, CVEs conhecidas que afetam os frameworks e plugins usados pelo seu site, e configurações inseguras comuns, mapeando cada achado à sua severidade e à categoria específica de CWE e OWASP envolvida.

Como a superfície de ataque muda constantemente, a Volturion também descobre automaticamente novos subdomínios conectados aos domínios monitorados e os inclui no mesmo cronograma de scan, para que sites de staging esquecidos e páginas antigas de marketing não se tornem pontos cegos. Para cada vulnerabilidade encontrada, a IA da Volturion gera um plano de correção específico e passo a passo, adaptado à sua stack de tecnologia, para que sua equipe feche a brecha imediatamente em vez de esperar o próximo horário disponível de um consultor de segurança. Alertas em tempo real por e-mail, Slack, Discord ou webhook garantem que você saiba de um novo achado crítico em minutos após a detecção, não na próxima revisão agendada.