Gestão de vulnerabilidades e CVEs: do alerta ao patch sem pânico

O scanner rodou na sexta e cuspiu cento e quarenta e sete vulnerabilidades, trinta e duas delas marcadas como "críticas" em vermelho berrante. O time olhou aquilo, sentiu o estômago afundar, e fez a única coisa que dava para fazer naquele estado de pânico: escolheu meia dúzia mais ou menos ao acaso, atualizou o que deu, silenciou o resto num arquivo de exceções e voltou para as tarefas do sprint. Três meses depois, uma das que ficaram silenciadas — não uma das trinta e duas vermelhas, mas uma amarela discreta de gravidade "média" — foi explorada em produção, porque tinha exploit público circulando e estava exposta na borda. As críticas que assustaram no relatório eram, quase todas, bibliotecas de teste que jamais rodam em produção. O time gastou pânico no lugar errado e ignorou o único sinal que importava. Gestão de vulnerabilidades não é sobre zerar o scanner; é sobre saber, de cento e quarenta e sete alertas, quais três vão te machucar de verdade — e por quê.

Este artigo é sobre construir esse discernimento. Vamos entender o que um CVE é de fato, por que o CVSS que todo mundo usa para priorizar é justamente o que menos deveria priorizar sozinho, quais sinais realmente indicam risco de exploração, como lidar com o fato incômodo de que a maioria do código que você entrega não é seu, e como montar um ciclo de patch que funciona no ritmo do dia a dia em vez de virar incêndio a cada boletim.

O que é um CVE, e o que ele não é#

CVE é um identificador. Quando alguém descobre uma falha específica num software específico, ela recebe um número no formato CVE-ano-sequencial, e esse número passa a ser o nome canônico daquela vulnerabilidade em todo lugar — no aviso do fornecedor, no scanner, na notícia. O CVE não é uma nota de gravidade, não é uma instrução de correção, não é um julgamento de risco. É só um nome estável para que todo mundo saiba que está falando da mesma falha. Confundir "tem CVE" com "é perigoso" é o primeiro passo em falso: existem CVEs triviais e CVEs devastadores, e o número em si não distingue.

Para dar gravidade a um CVE, o mundo adotou o CVSS, um sistema que produz uma nota de zero a dez. E aqui começa a confusão mais cara da área. O CVSS tem três grupos de métricas, mas quase todo mundo usa só o primeiro. A pontuação base descreve as características intrínsecas da falha — quão fácil é explorar, se precisa de autenticação, qual o impacto em confidencialidade, integridade e disponibilidade — e é fixa, calculada uma vez pelo emissor. A pontuação temporal ajusta pela realidade do momento: já existe exploit público, já existe correção, quão confirmada está. E a pontuação ambiental ajusta pelo seu contexto: o quanto aquele ativo importa no seu ambiente, se ele está exposto, se o dado que ele toca é sensível. O número vermelho que apavora no relatório é quase sempre só a base, isolada de tempo e de contexto — exatamente as duas dimensões que decidem se aquilo é um problema seu ou de outra pessoa.

Por que o CVSS sozinho é um péssimo critério de prioridade#

O problema prático é volumétrico. Se você priorizar por CVSS base, vai tratar como urgente todo CVE com nota nove ou dez, e num sistema real isso é uma fila interminável que nunca esvazia, porque notas altas são abundantes e a maioria esmagadora delas nunca será explorada contra você. A pontuação base pergunta "quão grave seria se explorada"; ela não pergunta "qual a chance de ser explorada" nem "isso está no meu caminho". Uma falha de nota dez numa dependência que só existe no ambiente de testes, sem alcance de rede, sem dado sensível, é ruído. Uma falha de nota seis num serviço exposto na internet, com exploit rodando em massa nesta semana, é uma emergência. O CVSS base coloca a primeira acima da segunda, e é por isso que priorizar por ele é matematicamente ocupado e praticamente cego.

Dois sinais corrigem essa miopia, e todo desenvolvedor deveria conhecê-los pelo nome. O EPSS é uma pontuação probabilística, atualizada diariamente, que estima a chance de uma vulnerabilidade ser explorada nos próximos trinta dias, com base em dados observados de exploração real no mundo. Ele responde justamente à pergunta que o CVSS não faz. Uma nota base alta com EPSS baixíssimo é uma falha grave que, empiricamente, ninguém está explorando. Uma nota base média com EPSS alto é o oposto: menos grave no papel, mas ativamente sob fogo. O segundo sinal é o catálogo KEV, mantido pela CISA — a lista de vulnerabilidades conhecidamente exploradas, isto é, aquelas para as quais há evidência concreta de exploração ativa observada na natureza. Se um CVE está no KEV, a discussão acabou: não é hipótese, está acontecendo, e vira topo absoluto da fila independentemente do que o CVSS diga. A prioridade sensata combina os três — a gravidade do CVSS para dimensionar o impacto, o EPSS para estimar a probabilidade, e o KEV como gatilho inegociável — e por cima disso aplica o seu contexto: isso está exposto, isso toca dado sensível, isso roda em produção?

O código que você entrega não é seu#

Há um fato desconfortável no desenvolvimento moderno: a maior parte do que você coloca em produção não foi escrita por você. Uma aplicação típica é uma casca fina de código próprio sobre uma montanha de dependências de terceiros, cada uma trazendo suas próprias dependências transitivas, camada sobre camada, até que o seu package.json ou Cargo.toml com quarenta linhas se materialize em mil pacotes na árvore instalada. É nessa montanha que vive a esmagadora maioria das vulnerabilidades que te afetam — não no seu código, mas no código que você importou sem ler.

A ferramenta que endereça isso é o SCA, análise de composição de software. Um scanner de SCA lê a árvore de dependências resolvida do seu projeto, compara cada componente e cada versão com bases de vulnerabilidades conhecidas, e te diz quais dos seus pacotes carregam CVEs. É indispensável, porque ninguém audita mil dependências à mão. Mas o SCA tem um pré-requisito para funcionar bem, e é o SBOM: a lista de materiais de software, um inventário formal, legível por máquina, de tudo que compõe o seu artefato — cada componente, sua versão, sua origem. Sem SBOM, quando o próximo boletim crítico estourar num pacote muito usado, você vai passar horas tentando responder à pergunta mais básica de todas: "a gente usa isso?". Com SBOM gerado no build e versionado, a resposta é uma consulta de segundos. O SBOM é o que transforma "acho que não usamos" em certeza, e essa diferença é o que separa uma resposta a incidente calma de uma noite em claro.

Supply chain: quando o problema é a origem#

Vulnerabilidade acidental numa dependência é um problema; dependência maliciosa por desenho é outro, mais insidioso, e cresce todo ano. O typosquatting é o clássico: alguém publica um pacote com nome quase idêntico ao de uma biblioteca popular — uma letra trocada, um hífen a mais — apostando que desenvolvedores vão errar a digitação e instalar o impostor, que vem com código malicioso embutido. A dependência abandonada é outro vetor: um pacote legítimo cujo mantenedor parou de cuidar e transferiu, ou teve a conta comprometida, e de repente uma versão nova sai com um backdoor para uma base que confiava cegamente nas atualizações. E há a confusão de namespace, ou dependency confusion, em que um atacante publica num repositório público um pacote com o mesmo nome de um pacote interno privado seu, e o gerenciador, mal configurado, prefere a versão pública maliciosa à interna legítima.

A defesa contra supply chain não é um scanner, é disciplina de processo. Fixe versões com lockfile e verifique integridade por hash, para que uma atualização silenciosa não entre sem você ver. Desconfie de dependências novas: quem mantém, com que frequência publica, quantos olhos há sobre aquele código, faz quanto tempo existe. Prefira o pacote maduro e chato ao pacote novo e brilhante que resolve um problema que você poderia resolver em dez linhas próprias. Configure escopos e registries para que pacotes internos jamais sejam resolvidos do público. E automatize a detecção, mas mantenha o julgamento humano no laço, porque a decisão de confiar numa dependência é uma decisão de segurança, não uma conveniência de produtividade.

O ciclo de vida do patch, sem incêndio#

Ter os sinais certos não adianta sem um processo que os transforme em ação repetível. O ciclo tem cinco etapas, e cada uma falha de um jeito característico quando é pulada. Detectar é rodar SCA de forma contínua, integrada ao pipeline, não uma varredura trimestral que acumula uma montanha de dívida entre uma e outra. Triar é a etapa que este artigo inteiro defende: pegar o que foi detectado e ordenar por risco real — KEV primeiro, depois EPSS alto combinado com exposição e sensibilidade, e o resto na fila de manutenção — em vez de tratar tudo como urgente ou nada como urgente. Testar é aplicar a correção num ambiente que não é produção e verificar que ela não quebrou nada, porque um patch que derruba o serviço é tão danoso quanto a vulnerabilidade, e atualizações de dependência quebram compatibilidade com frequência. Aplicar é promover a correção por um fluxo controlado e reprodutível, jamais editando o servidor à mão. E verificar é confirmar, depois do deploy, que a versão vulnerável de fato saiu de produção — porque "atualizei o lockfile" não é o mesmo que "a versão nova está rodando na máquina", e essa lacuna já deixou muita gente achando que estava protegida enquanto o binário antigo seguia no ar.

O ritmo importa. A maioria das correções cabe numa janela de manutenção planejada, cadenciada, previsível, em que você atualiza dependências em lote com teste adequado e baixo estresse. A minoria — o que está no KEV, o que tem EPSS altíssimo e está exposto, o que já mostra sinal de exploração — quebra a cadência e vira urgência com fluxo acelerado, mas ainda pelo mesmo pipeline, sem mão direta no servidor. A arte é calibrar o gatilho: se tudo é urgência, o time queima e passa a ignorar; se nada é, a emergência real chega junto com o incidente. Um bom processo tem os dois trilhos claramente separados, e critérios escritos para decidir em qual trilho cada CVE entra.

Ruído, falso positivo e a mentira do relatório verde#

Scanners erram, e para o lado do exagero. Uma parcela grande dos alertas é falso positivo ou irrelevante no seu contexto: a vulnerabilidade está numa função que você nunca chama, num pacote que só é usado no build e nunca vai para produção, ou num caminho de código morto. Tratar cada alerta como verdade absoluta leva à fadiga — o time vê tanto vermelho que para de olhar, e o dia em que o alerta é real se perde no mar de falsos. A resposta madura é triar com contexto e registrar as exceções de forma explícita e auditável: esta vulnerabilidade não se aplica por tal motivo, revisada em tal data, a ser reavaliada em tal condição. Silenciar sem justificativa é como o time do começo fez, e é como a falha real passa despercebida. Exceção documentada é gestão; exceção no escuro é a origem do próximo incidente.

E há a armadilha mais silenciosa de todas, que já custou meses de exposição a mais de uma equipe: o playbook existir não é a mesma coisa que ele estar aplicado. Ter o processo escrito, o scanner configurado no repositório, a política de patch documentada no wiki — nada disso protege produção se a coisa não está de fato rodando na máquina que está no ar. A verificação de que a mitigação está aplicada tem que olhar o ambiente real, o binário que roda, a versão que responde, e não o documento que descreve a intenção. A diferença entre "configuramos backup" e "o backup rodou ontem e restaura" é a diferença entre estar protegido e achar que está.

Um ângulo novo: as libs de IA e ML#

O ecossistema de IA e machine learning trouxe uma classe de vulnerabilidade que os processos tradicionais ainda estão aprendendo a tratar, e que merece atenção porque a superfície cresceu rápido. Formatos de modelo serializados carregam risco de execução de código: carregar um checkpoint de terceiros pode, em certos formatos, rodar código arbitrário no momento da desserialização, transformando "baixei um modelo" em "executei o que o autor do modelo quis". Bibliotecas de ciência de dados e frameworks de deep learning têm seu próprio fluxo de CVEs, e a cultura de pegar pesos e notebooks de repositórios abertos sem verificar procedência é um vetor de supply chain esperando para acontecer. Trate modelos e datasets de terceiros com a mesma desconfiança que você trata uma dependência de código: verifique origem, prefira formatos seguros de serialização, isole o carregamento, e inclua essas bibliotecas no seu inventário de SBOM e na sua varredura de SCA. A montanha de código que não é seu agora inclui pesos que não são seus, e a mesma disciplina se aplica.

Fechando: o processo que sobrevive à segunda-feira#

Em prosa de checklist, para levar ao time. Entenda que CVE é só um nome, e que o CVSS base que apavora no relatório é a dimensão que menos deveria priorizar sozinha — ele diz gravidade, não probabilidade nem contexto. Priorize combinando o KEV como gatilho inegociável, o EPSS como estimativa de exploração real, e o seu próprio contexto de exposição e sensibilidade por cima de tudo. Aceite que a maioria do seu risco vive em dependências, rode SCA continuamente e gere SBOM no build para nunca mais gastar horas respondendo "a gente usa isso?". Trate supply chain como disciplina de processo, não como scanner: lockfile, verificação de integridade, desconfiança de pacote novo, registries bem configurados. Rode o ciclo de patch inteiro — detectar, triar, testar, aplicar, verificar — com dois trilhos separados, a janela de manutenção cadenciada e a urgência acelerada, e critérios escritos para decidir qual usar. Documente cada exceção em vez de silenciar no escuro. E, acima de tudo, verifique no ambiente real, nunca no documento: o playbook existir não protege ninguém; o patch aplicado e confirmado em produção, sim. Feito assim, cento e quarenta e sete alertas deixam de ser pânico e viram uma fila ordenada em que você sabe, com sossego, quais três atacar primeiro.