Existe um momento, no dia a dia de qualquer time de segurança, em que algo começa a não fechar.
Os scans continuam rodando, os relatórios são gerados, as prioridades são definidas, os tickets seguem sendo criados e fechados. Em termos de atividade, tudo parece funcionar. Ainda assim, a sensação de controle não acompanha esse movimento. O backlog não desaparece, a pressão por resposta continua e, sobretudo, o risco parece sempre um pouco fora de alcance.
O problema raramente está no esforço. Está na forma como o esforço é organizado.
Durante muito tempo, o mercado tratou a vulnerabilidade como unidade central de medida. Quantas existem, quais são críticas, quanto tempo levam para serem corrigidas. Essa lógica ainda estrutura boa parte das operações, mas, na prática, ela já não descreve o que realmente importa.
Porque o risco não está na vulnerabilidade em si. Está no tempo em que ela permanece exposta no ambiente certo.
Essa diferença parece sutil, mas muda tudo.
Quando priorizar deixa de ser suficiente
Nos últimos anos, houve uma evolução real na forma como as vulnerabilidades são priorizadas. O uso exclusivo de CVSS ficou para trás. Hoje, o contexto pesa mais: exploração ativa, exposição à internet, criticidade do ativo, modelos probabilísticos como o EPSS.
Esse avanço foi necessário, mas não resolveu o problema por completo.
Priorizar continua sendo uma tentativa de antecipar risco. É, no fundo, um exercício de probabilidade. E a probabilidade, por definição, não garante o que está acontecendo de fato dentro do ambiente.
É possível que uma vulnerabilidade apareça como crítica em todos os indicadores e, ainda assim, não esteja explorável naquele contexto específico. Da mesma forma, uma falha menos evidente pode representar uma porta real de entrada dependendo da arquitetura, da configuração ou das integrações envolvidas.
É nesse ponto que a operação começa a exigir algo diferente.
Não basta saber o que parece mais urgente. É preciso entender o que está realmente exposto.
O que o MTTR não mostra
Métricas como MTTR continuam sendo usadas como referência de eficiência. E elas cumprem esse papel até certo ponto, mas existe uma limitação importante: elas contam uma história média.
E, em segurança, o problema raramente está na média.
Quando parte dos ativos é corrigida rapidamente e outra parte permanece exposta por muito mais tempo, o indicador pode sugerir que tudo está sob controle, mas a realidade é outra. O risco não se distribui de forma uniforme. Ele se concentra justamente nos pontos onde a remediação demora mais, seja por dependência de negócio, por complexidade técnica ou simplesmente por falta de visibilidade.
Essa é a parte que escapa dos dashboards mais tradicionais.
Não é o volume de vulnerabilidades abertas que define o risco. É a duração da exposição nos ativos que realmente importam.
A parte do problema que não aparece
Todo processo de remediação tem um início relativamente previsível. As primeiras correções acontecem, os sistemas mais padronizados seguem o fluxo, os ganhos iniciais aparecem. É um movimento quase automático.
Depois disso, o ritmo muda.
Surgem sistemas que não podem ser interrompidos, dependências entre aplicações, ambientes que não seguem padrão, dispositivos fora da governança direta, restrições operacionais que impedem mudanças imediatas. A partir daí, a remediação deixa de ser linear.
O que permanece aberto não é aleatório. É justamente o que é mais difícil de tratar.
E é nesse ponto que a exposição começa a se acumular.
Essa camada residual, mais lenta, menos visível e muito mais persistente, é o que define o risco real do ambiente. Não é o que aparece no início da esteira. É o que fica depois que a esteira já parece ter funcionado.
Quando o problema deixa de ser técnico
Outro fator que pesa cada vez mais é que a remediação deixou de ser um problema puramente técnico.
Ela depende de decisões. De priorização entre áreas. De negociação com times de infraestrutura, de aplicação, de cloud. Depende de janela de mudança, de tolerância a risco operacional, de impacto no negócio.
O NIST já trata patch management como um processo organizacional, não apenas técnico. Isso não é detalhe. É um reconhecimento de que corrigir vulnerabilidades envolve muito mais do que aplicar atualização. Envolve coordenação.
E a coordenação, por natureza, introduz atraso.
Quando a velocidade do ataque era menor, esse atraso era administrável. Hoje, com exploração acontecendo antes ou no momento da divulgação de falhas, esse intervalo se tornou crítico.
O modelo não deixou de funcionar porque os times falharam. Ele deixou de funcionar porque o contexto mudou.
O que muda quando se olha para exposição, e não para vulnerabilidade
A principal mudança que começa a ganhar força no mercado é a troca de perspectiva.
Em vez de tratar vulnerabilidades como unidades isoladas, passa-se a olhar para exposição como fenômeno contínuo. Não apenas o que existe, mas onde, por quanto tempo e com qual impacto potencial.
Isso exige mais do que descoberta e priorização. Exige capacidade de interpretar o contexto e, principalmente, de validar o que está realmente aberto no ambiente.
É nessa transição que soluções como as da Qualys começam a se posicionar de forma diferente. Ao trazer para a mesma camada a leitura de risco (TruRisk) e a validação de explorabilidade (TruConfirm), a proposta deixa de ser apenas encontrar e classificar falhas. Passa a se entender quais delas representam risco concreto naquele momento.
O efeito disso é direto na operação.
A discussão deixa de ser baseada em score e passa a ser baseada em evidência.
A priorização deixa de ser genérica e passa a ser contextual.
O esforço deixa de ser distribuído e passa a ser direcionado.
Reduzir ruído para conseguir agir
Um dos maiores desafios para times de segurança hoje não é falta de informação. É excesso dela.
Há mais dados, mais alertas, mais vulnerabilidades identificadas e mais pressão por resposta do que em qualquer outro momento. Nesse cenário, eficiência não significa fazer mais. Significa escolher melhor onde agir.
Quando o time consegue diferenciar o que está efetivamente exposto do que é apenas potencialmente relevante, a operação muda de perfil. Menos esforço é desperdiçado em correções que não alteram o risco imediato. Mais energia é aplicada onde existe impacto real.
Essa mudança é fundamental para equipes que operam com recursos limitados e precisam justificar cada decisão com base em risco concreto.
O que passa a definir maturidade
A maturidade de um programa de vulnerabilidades já não pode ser medida apenas pela capacidade de encontrar falhas ou pela velocidade média de correção.
O que começa a diferenciar operações mais eficazes é a capacidade de responder a perguntas mais difíceis, e mais próximas da realidade do ataque:
O que está realmente exposto agora?
Onde essa exposição existe?
Por quanto tempo ela permanece ativa?
Ela pode, de fato, ser explorada no ambiente atual?
Responder a essas perguntas exige uma combinação de visibilidade, contexto e validação que vai além do modelo tradicional.
A discussão sobre vulnerabilidades não desapareceu. Mas ela deixou de ser suficiente.
O foco está se deslocando para algo mais próximo do risco real: a exposição contínua, acumulada e, muitas vezes, invisível nos modelos tradicionais de operação.
Para times de segurança, isso implica uma mudança importante. Não basta mais encontrar e classificar. É preciso entender, validar e agir com precisão.
Porque, no fim, o que importa não é quantas vulnerabilidades existem.
É quanto tempo o ambiente permanece exposto ao que realmente pode ser explorado.
Fontes
Qualys — The Broken Physics of Remediation
NIST — SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
CISA — Known Exploited Vulnerabilities (KEV) Catalog
CISA — Cybersecurity Performance Goals (CPG) 2.0
FIRST — Exploit Prediction Scoring System (EPSS)
Google Threat Intelligence Group — Threat Analysis Reports on Vulnerability Exploitation Trends
Posts recentes
