Como lidar com o aumento das CVE quando a sua equipa é pequena

O que mudou: os números das CVE

Os números abaixo vêm dos próprios registos do CVE Program, reconstruídos todos os dias na nossa página tendências de publicação de CVE. Segundo o snapshot tirado a 12/11/2026 UTC:

• 47 801 registos foram publicados em 2025, mais 20 % do que no ano anterior.
• 95 494 registos foram publicados até agora em 2026, 303 por dia, +131 % face ao ritmo diário de 2025.
• 155 por dia têm classificação alta ou crítica.
• 17% de todos os registos desde 2020 não têm pontuação CVSS, nem do atribuidor nem do enriquecimento da CISA. A cobertura melhorou: em 2026 a proporção é de 6%.
• 505 organizações atribuíram estes registos, e as 20 maiores representam 75% deles.

• Alta ou crítica
• Outras gravidades e sem pontuação

1. 39 2020
2. 54 2021
3. 68 2022
4. 78 2023
5. 109 2024
6. 131 2025
7. 303 2026*

Média diária de registos publicados em cada ano; * assinala o ano em curso até à data. Fonte: registos cvelistV5 do CVE Program, snapshot de 12/11/2026 UTC. Filtros por mês, gravidade e atribuidor: tendências de publicação de CVE.

Não se trata de um mau trimestre. O número subiu todos os anos desde 2020, e várias mudanças estruturais mantêm-no a subir:

• Mais atribuidores, a atribuir de forma mais ampla. O projeto do kernel Linux tornou-se CVE Numbering Authority em fevereiro de 2024. A sua política documentada é atribuir uma CVE a qualquer correção de bug que possa ser uma vulnerabilidade assim que a correção chega a um kernel estável, porque muitas vezes não é claro se é explorável quando a correção entra. Só a CNA do kernel publicou 18 221 registos desde então.
• Descoberta assistida por IA. Em novembro de 2024, o Project Zero e a DeepMind da Google anunciaram que o seu agente Big Sleep tinha encontrado um bug de segurança de memória explorável no SQLite antes de este chegar a uma versão lançada, o que consideram ter sido o primeiro exemplo público de um agente de IA a fazê-lo em software amplamente utilizado. Ferramentas como esta aumentam o que um investigador consegue encontrar.
• A NVD já não consegue enriquecer tudo. O NIST afirma que a National Vulnerability Database acumulou um backlog de CVE por enriquecer desde o início de 2024 e não o conseguiu eliminar porque as submissões continuaram a aumentar. Em abril de 2026 passou para um modelo baseado no risco: as CVE do catálogo Known Exploited Vulnerabilities da CISA e as CVE em software federal ou crítico são enriquecidas primeiro, e as restantes ficam listadas como não agendadas para enriquecimento imediato. Um processo que depende dos dados de produtos afetados de uma única base de dados fica agora à espera, ou falha.
• Menos tempo para responder. A Mandiant mediu um tempo médio até à exploração de 63 dias em 2018 e 2019. O seu relatório M-Trends 2026 estima menos sete dias para 2025: a exploração começa agora, com frequência, antes de ser lançada uma correção.
• Prazos regulamentares. Ao abrigo do Cyber Resilience Act da UE, os fabricantes comunicam uma vulnerabilidade ativamente explorada com um alerta precoce no prazo de 24 horas, uma notificação no prazo de 72 horas e um relatório final no prazo de 14 dias após a disponibilização de uma correção (o que o CRA exige). O prazo é o mesmo para uma equipa de três pessoas e para uma de trezentas.

Nada disto significa que o software esteja a ficar menos seguro. Significa que o número de coisas que uma equipa tem de analisar cresce todos os anos, e a equipa não.

O que falha no processo de uma equipa pequena

O aumento do número de CVE não quebra a gestão de vulnerabilidades por haver mais vulnerabilidades para corrigir. Quebra-a porque cada passo manual se repete para cada CVE.

Passo manual	Porque falha com o volume atual
Construir o inventário à mão	Uma folha de cálculo, ou uma SBOM feita antes de uma auditoria, fica desatualizada no dia a seguir ao lançamento seguinte.
Ler o feed	Com 155 registos altos ou críticos por dia, ninguém consegue acompanhar.
Perguntar à engenharia "usamos X?"	A mesma pergunta para cada CVE, às mesmas pessoas ocupadas. A pergunta é o estrangulamento.
Um ticket por CVE por repositório	A CVE de uma biblioteca partilhada transforma-se em dezenas de tickets duplicados que afogam o backlog.
Responder a cada cliente individualmente	Os pedidos crescem com a base de clientes, não com o número de vulnerabilidades.
Documentos em PDF ou numa wiki	As ferramentas dos clientes não conseguem cruzar um PDF com o seu inventário, pelo que cada leitor volta a perguntar.
Prazos que não mudam	O tempo até à exploração encolhe, enquanto um processo manual fica mais lento à medida que o volume cresce.

O inventário. A maioria das equipas que mantêm uma lista de componentes à mão atualiza-a antes de uma auditoria ou de um questionário de cliente. Entre essas datas, descreve software que já não é distribuído. Cada pergunta sobre uma CVE começa então por reconstruir o que a versão continha.

O feed. Ler avisos de segurança é o passo por onde as equipas começam, e o primeiro a ceder. Ouvimos equipas que ainda o fazem à mão, incluindo uma em que a análise de vulnerabilidades consiste em pessoas a ler fóruns de CVE. Funciona até ao dia em que deixa de funcionar, e não há nenhum sinal que anuncie esse dia.

A pergunta à engenharia. "Usamos esta biblioteca, e em que versão?" interrompe um programador por cada CVE que possa aplicar-se. Uma equipa de segurança de produto de duas pessoas disse-nos que o seu trabalho é carregar em botões só para acompanhar, sem tempo para melhorar o processo.

Os tickets. Quando uma biblioteca partilhada tem uma CVE e cada repositório abre o seu próprio ticket, o backlog conta a mesma decisão muitas vezes. As equipas aprendem a ignorar o backlog e depois falham o ticket que importava.

As respostas aos clientes. Depois de uma vulnerabilidade muito divulgada ou de um ataque à cadeia de abastecimento, os clientes perguntam "somos afetados?". Responder a cada um em separado custa mais tempo precisamente no dia em que há menos.

Os documentos. Uma declaração em PDF ou uma página de wiki tem de ser lida por uma pessoa do lado do cliente. Os scanners dos clientes, e cada vez mais os reguladores, esperam SBOM, VEX e avisos de segurança em formatos que uma máquina consiga cruzar.

Os prazos. Um alerta precoce devido no prazo de 24 horas, ou um exploit que surge antes da correção, não espera que a fila se esvazie.

O que automatizar, por ordem

Cada passo retira trabalho ao seguinte, pelo que a ordem importa mais do que a escolha de ferramentas.

1. Saiba o que distribui. Uma SBOM de cada build transforma "somos afetados?" numa consulta.
2. Faça a correspondência de forma contínua, com mais de uma fonte. As novas CVE são verificadas face a todas as SBOM guardadas, e ninguém precisa de ler o feed.
3. Corte o ruído. As conclusões sobre o que não distribui, e os duplicados, nunca chegam a uma pessoa.
4. Faça a triagem de forma semiautomática. Os factos são preenchidos; uma pessoa toma a decisão.
5. Torne tudo legível por máquina. Cada decisão é tomada uma vez e reutilizada por todos os leitores.
6. Responda uma vez, publicamente. O pedido que nunca chega não custa nada.

1. Gere uma SBOM em cada build, automaticamente

O que substitui: a folha de cálculo e a pergunta à engenharia. Uma SBOM gerada durante o build descreve o que o build realmente usou, e guardar uma por cada versão distribuída permite-lhe responder pela versão do ano passado tal como pela main. Os clientes usam versões antigas; o seu inventário tem de as cobrir.

Versão mínima: uma SBOM gerada em CI para cada build de lançamento, guardada junto ao artefacto da versão. Melhor: uma SBOM registada a partir do próprio build em vez de deduzida dos lockfiles depois, para que também inclua os componentes obtidos fora do gestor de pacotes (SBOM geradas durante o build, automatização de SBOM).

Custo: um ou dois dias de trabalho no pipeline para a versão mínima, e depois nada por cada lançamento. Sinal de que funciona: para qualquer versão, consegue listar os seus componentes sem perguntar a ninguém.

2. Faça a correspondência contínua com várias fontes de vulnerabilidades

O que substitui: ler o feed. A correspondência é trabalho para uma máquina: cada nova CVE face a cada SBOM guardada, não apenas a SBOM do build que acabou de correr. Uma versão antiga que estava limpa quando foi lançada passa a estar afetada no dia em que é publicada uma CVE para um dos seus componentes.

Uma fonte não chega. O backlog de enriquecimento da NVD faz com que os dados de produtos afetados possam chegar tarde ou nunca chegar. Os avisos de segurança dos ecossistemas, como a GitHub Advisory Database e o OSV, são muitas vezes mais rápidos e indicam que versões de pacotes são afetadas nos termos do próprio ecossistema. A EU Vulnerability Database da ENISA acrescenta o contexto europeu.

Versão mínima: uma tarefa agendada que volta a analisar diariamente todas as SBOM guardadas face a uma fonte agregada e reporta novas correspondências. Sinal de que funciona: fica a saber que uma versão está afetada antes de um cliente lho dizer. Consulte o acompanhamento de vulnerabilidades para ver como isto funciona no CRACI.

3. Corte o ruído antes de alguém olhar

O que substitui: a revisão manual de conclusões que não importam. A maior parte do ruído é criada a montante: por inventários que listam o que não distribui, por várias ferramentas a reportar a mesma CVE e por dependências de que ninguém precisa. Corrija o inventário, conte cada conclusão uma única vez por package URL (PURL), versão e CVE, distribua menos dependências e acrescente depois o contexto de explorabilidade do CISA KEV, do EPSS e do VEX. Como reduzir o ruído das vulnerabilidades trata estas alavancas uma a uma. Sinal de que funciona: as conclusões por versão distribuída diminuem, e os motivos ficam registados.

4. Faça a triagem de forma semiautomática

O que substitui: uma pessoa a reunir os factos de cada conclusão. Divida o trabalho com precisão:

• Automático: a gravidade, se se sabe que está a ser explorada, que produtos e versões contêm o componente, a equipa responsável, uma prioridade proposta e um prazo.
• Humano: a decisão. Corrigir, mitigar, aceitar com data de expiração ou marcar como não afetado com uma justificação.

O que não é seguro automatizar: fechar uma conclusão como não afetada sem um motivo registado. Isso é supressão, e volta a aparecer numa auditoria ou num incidente. As regras de classificação são tratadas em priorização de vulnerabilidades.

Versão mínima: 15 minutos por dia sobre uma fila que já está ordenada e preenchida. Sinal de que funciona: cada decisão tem um motivo registado, e nada fica à espera de que alguém vá consultar alguma coisa.

5. Torne tudo legível por máquina

O que substitui: PDF, páginas de wiki e e-mails que uma pessoa tem de ler. Publique as SBOM em CycloneDX ou SPDX (CycloneDX vs SPDX), as decisões de não afetado como VEX e os avisos de segurança em CSAF. Os scanners dos clientes e os reguladores podem então consumi-los sem intervenção humana, pelo que cada decisão é tomada uma vez e reutilizada por todos os que perguntam.

Versão mínima para uma equipa pequena: SBOM e VEX a pedido, num local estável; CSAF quando os clientes começarem a pedi-lo. Sinal de que funciona: as ferramentas dos clientes deixam de sinalizar o que já respondeu.

6. Responda uma vez, publicamente

O que substitui: uma troca de e-mails por cliente. Publique um aviso de segurança ou uma página de estado para cada CVE significativa, com as versões afetadas e corrigidas, e mantenha um modelo de resposta com a respetiva ligação. O guia para responder a "somos afetados por esta CVE?" mostra como chegar à resposta. Para a resposta propriamente dita, como responder aos clientes após um ataque à cadeia de abastecimento tem modelos de resposta. O pedido mais barato é o que nunca chega. Sinal de que funciona: a maioria dos pedidos é respondida com uma ligação.

Depois, corrija

Os pull requests automáticos de atualização de dependências mantêm o trabalho de rotina em andamento; agrupe-os por semana ou por versão para que a revisão continue gerível. Atualizar um pacote a montante elimina muitas vezes várias dependências transitivas vulneráveis de uma só vez, e sai mais barato do que corrigir cada uma (remediação automatizada de vulnerabilidades). Depois, impeça que componentes vulneráveis conhecidos regressem com policy gates que bloqueiam o build.

Um plano por dimensão da equipa

As horas são estimativas ilustrativas para planeamento, não benchmarks.

	Uma pessoa, a tempo parcial	Uma função de segurança ou PSIRT de 2 a 5 pessoas	Uma equipa maior
Automatizar primeiro	Passos 1 e 2: uma SBOM por build e correspondência contínua	Passos 1 a 3, depois o encaminhamento para os responsáveis no passo 4	Os seis, com policy gates em todos os pipelines
Continua manual	A decisão sobre cada conclusão alta ou crítica; respostas aos clientes a partir de um modelo	Decisões, justificações VEX, avisos de segurança para CVE significativas	Decisões, exceções e o próprio processo
Tempo semanal, ilustrativo	2 a 4 horas	4 a 8 horas por pessoa	Definido pelo volume de decisões, não pelo feed

Se já tem um PSIRT, aplica-se a mesma ordem; o modelo de processo completo está no ciclo de vida da gestão de vulnerabilidades. Para os pedidos dos clientes que se multiplicam com cada CVE, consulte como escalar uma PSIRT.

Como saber se está a funcionar

• Tempo entre a publicação de uma CVE e "afetado" ou "não afetado", por produto.
• A proporção de pedidos de clientes respondidos com material publicado.
• Conclusões por versão distribuída, não por análise.
• A proporção de decisões com um motivo registado.
• Horas por semana dedicadas a vulnerabilidades, e se estão a diminuir.

Meça primeiro a sua própria linha de base. Não existem benchmarks fiáveis do setor para estes indicadores, e não citamos nenhum.

Contratar, comprar ou mudar o processo?

• Contrate quando o trabalho for corrigir vulnerabilidades no seu próprio código, ou trabalho de segurança junto dos clientes que exige critério.
• Compre ferramentas para os passos que se repetem por CVE: os passos 1, 2, 3 e 5.
• Mude o processo para a responsabilidade e os prazos: quem decide, e até quando.

Seja honesto quanto ao último. Uma ferramenta sem responsável produz um dashboard que ninguém lê.

Onde entra o CRACI

O CRACI automatiza os passos 1 e 2, e parte dos passos 3 e 4, para software compilado em GitHub Actions. Substitui os seus runners alojados no GitHub e, à medida que cada job corre, regista os pacotes que o job efetivamente obteve, incluindo pacotes restaurados de caches de CI e dependências ocultas que nenhum lockfile lista.

• Uma SBOM de cada build. A SBOM de cada job identifica cada componente por PURL e tem um estado de completude, para que saiba quando algo não pôde ser visto. O histórico de builds guarda cada build anterior com a sua SBOM, para que veja que builds continham uma dependência vulnerável, direta ou transitiva.
• Correspondência contínua. As SBOM monitorizadas são reavaliadas continuamente, e as conclusões são agregadas entre builds e repositórios, pelo que a CVE de uma biblioteca partilhada surge como um único problema, não quarenta.
• Notificações e gates. O CRACI notifica as pessoas relevantes de uma vulnerabilidade e da sua gravidade, e os policy gates podem parar um build em tempo real, incluindo um build que contenha uma CVE específica.
• Triagem e encaminhamento. As equipas de segurança fazem a triagem das conclusões no CRACI e encaminham cada uma para a equipa responsável pela correção.
• SBOM legíveis por máquina. As SBOM são exportadas em CycloneDX ou SPDX, e o CRACI suporta VEX.

O CRACI não publica avisos de segurança, não oferece análise de alcançabilidade e não analisa o seu próprio código. Cobra apenas os minutos de build: $0.002 por minuto de vCPU ($0.004 para um runner predefinido de 2 vCPU), medidos ao segundo, sem mensalidade, sem custo por SBOM e, por agora, sem taxa de licença. Consulte os preços.

Automatize hoje os dois primeiros passos: execute os seus builds no CRACI. Estamos a acompanhar pessoalmente a integração de cada equipa antes da disponibilidade geral.

Quando o CRACI não é a resposta

• O seu software não é compilado em GitHub Actions. O GitLab CI e o Jenkins estão no roadmap.
• A sua exposição é sobretudo de infraestrutura: servidores, endpoints e configuração de cloud. As ferramentas de gestão de vulnerabilidades de infraestrutura são mais adequadas.
• Integra firmware de terceiros que não compila. As ferramentas de análise binária são mais adequadas.
• O seu backlog é sobretudo composto por conclusões verdadeiras e exploráveis no seu próprio código. Isso é um problema de capacidade de remediação, não um problema de automatização.

Automatização da gestão de vulnerabilidades: perguntas frequentes

Porque há agora tantas mais CVE?

Há mais organizações a atribuir CVE, e algumas atribuem-nas de forma ampla: o kernel Linux tornou-se CVE Numbering Authority em 2024 e atribui uma a qualquer correção de bug que possa ser uma vulnerabilidade. As ferramentas assistidas por IA encontram mais bugs por investigador. Foram publicados 47 801 registos em 2025, e 2026 segue a um ritmo de 303 por dia. A tendência dura há anos.

Como pode uma equipa pequena acompanhar as novas CVE?

Não as lendo. Gere uma SBOM em cada build, cruze automaticamente as novas CVE com todas as SBOM guardadas, corte o ruído e deixe as pessoas tomar apenas as decisões sobre o que resta. Uma equipa pequena acompanha o ritmo eliminando os passos que se repetem para cada CVE, não trabalhando mais depressa.

O que devemos automatizar primeiro na gestão de vulnerabilidades?

O inventário: uma SBOM gerada em CI para cada build de lançamento, guardada com a versão. Todos os passos seguintes dependem dela, e ela transforma "somos afetados?" de uma pergunta à engenharia numa consulta. A correspondência contínua com essas SBOM vem em segundo lugar.

Precisamos de uma equipa de segurança para tratar das vulnerabilidades?

Não para começar. Uma pessoa responsável pelo processo a tempo parcial consegue geri-lo se o inventário, a correspondência e a redução do ruído estiverem automatizados. Precisa mais de um responsável identificado e de prazos do que de uma equipa. Contrate quando o trabalho passar a ser corrigir o seu próprio código ou trabalho de segurança junto dos clientes.

Como sabemos que novas CVE afetam o nosso produto?

Guarde uma SBOM de cada versão distribuída e volte a verificá-las todas sempre que são publicadas novas CVE, com mais de uma fonte de vulnerabilidades. Uma CVE afeta-o quando corresponde a um componente e a uma versão que realmente distribui. O contexto de explorabilidade e o VEX dizem depois se isso importa.

O que significa "legível por máquina" para SBOM, VEX e avisos de segurança, e porque importa?

Significa um formato estruturado normalizado que uma ferramenta consegue interpretar: CycloneDX ou SPDX para SBOM, VEX para declarações de não afetado, CSAF para avisos de segurança. O scanner de um cliente consegue cruzá-los com o seu inventário sem que ninguém os leia, pelo que uma decisão que toma uma vez é reutilizada por todos os clientes e ferramentas.

Que parte da triagem se pode automatizar com segurança?

A recolha dos factos: gravidade, estado de exploração, que produtos e versões contêm o componente, o responsável, uma prioridade proposta e um prazo. A decisão em si deve ficar com uma pessoa. Nunca feche automaticamente uma conclusão como não afetada sem um motivo registado.

De quanto tempo dispomos para responder a uma CVE crítica?

Menos do que a maioria dos processos pressupõe. O M-Trends 2026 da Mandiant estima o tempo médio até à exploração em 2025 em menos sete dias, ou seja, exploração antes de existir uma correção. Ao abrigo do Cyber Resilience Act da UE, uma vulnerabilidade ativamente explorada exige um alerta precoce no prazo de 24 horas. Defina o seu próprio prazo por gravidade e exploração, e meça-se face a ele.