A lacuna entre um pentest e o próximo
A falha de software passou a ser a porta de entrada mais usada pelos atacantes. Segundo o Data Breach Investigations Report 2026, da Verizon, que analisou incidentes ocorridos entre novembro de 2024 e outubro de 2025, 31% das violações de dados começam pela exploração de uma falha de software, à frente do roubo de senhas pela primeira vez em dezenove anos de relatório.
O X-Force Threat Intelligence Index 2026, da IBM, chega à mesma conclusão por outro caminho e registra alta de 44% na exploração de aplicações expostas à internet em um ano. É esse o risco que se acumula entre um teste e o próximo, quando as falhas novas aparecem e ninguém as está procurando.
Entre as falhas do catálogo KEV, lista pública de vulnerabilidades já exploradas em ataques reais mantida pela CISA, apenas 26% haviam sido totalmente corrigidas nas 13 mil organizações consultadas, contra 38% no levantamento anterior.
Esses números descrevem capacidade de execução. Duas empresas podem contratar o mesmo teste e terminar o ano em situações muito diferentes, conforme uma mantenha o fluxo de correção funcionando e a outra trate cada relatório como um evento isolado.
O que corrigir primeiro
Um ambiente de médio porte acumula centenas de falhas por ciclo, e nenhuma equipe corrige tudo ao mesmo tempo. A priorização de vulnerabilidades define o resultado mais do que o tamanho da fila.
Quatro perguntas organizam essa ordem:
Qual o impacto se a falha for explorada, medido pela nota pública de gravidade do padrão CVSS?
Qual a chance de alguém explorá-la em breve, estimada pelo modelo EPSS?
Qual a importância do sistema afetado para a operação e que dados ele processa?
O sistema está exposto na internet ou vive apenas na rede interna?
Uma falha de gravidade média em um servidor exposto, com ataques já registrados, entra na frente de uma falha grave em um sistema interno sem acesso externo. A nota de gravidade sozinha não produz essa ordem.
A fila também muda com o tempo. A estimativa de probabilidade é recalculada conforme o cenário evolui, e uma falha que entrou em posição intermediária pode subir semanas depois, quando surge uma ferramenta de ataque pública. Por isso a equipe reordena a fila a cada revisão de pendências, no mesmo ritmo das varreduras.
Números que mostram se a gestão contínua de vulnerabilidades funciona
Um programa de gestão contínua de vulnerabilidades se mede por três indicadores simples, todos com número apurado e não estimado:
Medido por faixa de gravidade, contado entre a descoberta e a conferência final.
Mostra há quanto tempo cada falha espera na fila.
Indica o percentual de falhas resolvidas dentro do tempo definido para sua faixa.
O prazo adequado varia com dois fatores ao mesmo tempo: a gravidade da falha e a importância do sistema. O NIST SP 800-40 Rev. 4 orienta as empresas a definirem grupos de manutenção segundo esses dois eixos, com prazos próprios para cada cenário.
A leitura desses três números junto com a diretoria costuma revelar uma distância entre percepção e operação. Sem medição comum, cada nível da empresa responde a partir da própria impressão, e a diretoria aprova o orçamento de segurança a partir de um retrato que a equipe técnica não reconhece.
O ritmo da gestão contínua de vulnerabilidades ao longo do ano
A rotina da gestão contínua de vulnerabilidades distribui o esforço ao longo dos doze meses, com frequência proporcional ao risco de cada sistema. A correção de vulnerabilidades deixa de depender de um evento anual e passa a acontecer em ciclos curtos, que se fecham em quatro movimentos:
Varredura recorrente Mais frequente nos sistemas expostos à internet e mais espaçada nos internos.
Revisão da fila Reordena prioridades conforme o ambiente muda.
Campanhas de correção Cada uma com responsável, escopo e prazo.
Reteste A repetição do mesmo teste no mesmo sistema depois da correção, que só fecha o registro quando a falha deixa de ser reproduzível.
Parte das falhas, algumas vezes, permanece sem correção direta; por exemplo, sistemas antigos sem atualização disponível, softwares de terceiros com calendário próprio e equipamentos homologados em uma versão específica continuam abertos por decisão operacional. Nesses casos, o programa registra a exceção com data de revisão e aplica uma proteção alternativa.
O teste de intrusão anual permanece no calendário, com outra função. Ele confirma, na prática e com técnica de atacante, o que as varreduras e os retestes indicaram durante o ano.
No setor financeiro: o ciclo como prova de governança
Em instituições autorizadas pelo Banco Central, o ciclo de correção deixa rastro, e esse registro constitui a evidência que o regulador espera encontrar. As Resoluções BCB 538 e CMN 5.274, ambas de 18 de dezembro de 2025, atualizaram os requisitos de segurança cibernética do setor.
Em análise do escritório Demarest, a Resolução BCB 538 traz a institucionalização dos testes de intrusão e o aumento da responsabilidade das instituições reguladas. As leituras do escritório NDM Advogados e da Grant Thornton convergem nos pontos operacionais: teste de intrusão anual conduzido por profissionais independentes, documentação dos resultados e planos de ação mantidos à disposição do Banco Central por cinco anos, com prazo de adequação encerrado em 1º de março de 2026.
A vantagem de manter o ciclo funcionando aparece na hora da verificação. A instituição que mede tempo de correção, acompanha a idade das pendências e registra cada reteste chega com o histórico pronto, porque ele nasce da própria operação.
Na saúde: correção contínua e continuidade do atendimento
Em hospitais e clínicas, a varredura recorrente e o reteste registrado mantêm em operação os sistemas de que o atendimento depende. Uma falha de configuração aberta por meses mantém prontuários e exames acessíveis a quem souber onde procurar durante todo esse período, e uma parada em sistema assistencial adia consultas e cirurgias já agendadas.
O caso da MedicSolution, fornecedora brasileira de software para clínicas, mostra o mecanismo. Em setembro de 2025, o grupo KillSec assumiu o ataque e, segundo a apuração noticiada pelo Dark Reading, os dados saíram de um armazenamento em nuvem configurado de forma incorreta, com mais de 94 mil arquivos expostos, entre resultados de exames, imagens e registros de menores.
O caso também mostra onde o escopo fica curto. A MedicSolution atende várias clínicas, então a falha em um fornecedor alcançou pacientes de diferentes instituições. O relatório da Verizon registra que o envolvimento de terceiros nas violações cresceu 60% em um ano e passou a aparecer em quase metade dos casos.
Quem opera o ciclo e quem o testa
Dois times dividem o ciclo de correção entre um pentest e o próximo: o Blue Team, que opera a rotina de defesa, e o Red Team, que a submete a teste.
Cuida do dia a dia: acompanha os alertas, tria o que é relevante, conduz a correção de vulnerabilidades e responde aos incidentes.
Age como um invasor real contra pessoas, processos e tecnologia, usando táticas catalogadas em bases como o MITRE ATT&CK.
É na sinergia e no encontro entre os dois times que mora o diferencial da operação. O Red Team entrega as falhas e os caminhos que percorreu; o Blue Team recebe esse material, aplica a ordem de prioridade e conduz a correção até o reteste. Sem essa passagem organizada, o relatório é arquivado sem tratamento.
Por onde começar
O ponto de partida costuma estar na própria operação. O plano de ação do último pentest já traz as falhas, os responsáveis e os prazos. Três perguntas medem a distância entre esse documento e um programa em funcionamento:
- A lista de sistemas está atualizada, com responsável e grau de importância definidos para cada um?
- O tempo de correção e a idade das pendências têm número apurado em alguma ferramenta?
- Cada correção fecha com uma nova verificação registrada, com data e resultado?
Uma resposta negativa a qualquer uma delas indica onde o ciclo se rompe.
Conheça a atuação da Prolinx
A Prolinx opera esse ciclo nas frentes de SOC, SIEM e gestão de vulnerabilidades: o SOC é o centro de monitoramento que acompanha o ambiente em tempo integral, o SIEM é a plataforma que reúne e cruza os registros dos sistemas, e a gestão de vulnerabilidades conduz as correções da triagem até a validação.
Para avaliar como está o ciclo da sua operação hoje, fale já com um especialista da equipe.
Perguntas frequentes
O que é gestão contínua de vulnerabilidades?
É o trabalho permanente de encontrar, priorizar, corrigir e conferir falhas de segurança, com varreduras recorrentes, campanhas de correção e nova verificação ao final. Ela mantém o ambiente sob revisão entre um teste de intrusão e o próximo.
Qual a diferença entre o plano de ação do pentest e a gestão contínua?
O plano de ação trata as falhas de um teste específico, com responsável, prazo e conferência. A gestão contínua mantém esse mesmo trabalho funcionando o ano inteiro, aplicado ao que aparece entre um teste e o seguinte.
O que acompanhar para saber se funciona?
Tempo médio de correção por faixa de gravidade, idade das pendências abertas e cumprimento do prazo interno. Juntos, os três mostram se a fila está sob controle.
Com que frequência escanear os sistemas?
A frequência acompanha o risco de cada sistema, seguindo a lógica de grupos de manutenção do NIST SP 800-40 Rev. 4: quanto mais exposto e mais importante o sistema, mais curto o intervalo entre as varreduras.
O que muda em setores regulados?
O registro do ciclo passa a ser cobrado como evidência. No setor financeiro, as Resoluções BCB 538 e CMN 5.274 atualizaram os requisitos de segurança cibernética; na saúde, o registro do tratamento das falhas sustenta a continuidade do atendimento.
Vulnerabilidade não espera o próximo pentest.
Fale com a equipe da Prolinx para estruturar um ciclo contínuo de varredura, priorização, correção e reteste com evidência para a gestão.