O seu CVE está acessível. Mas será que é explorável?

Hoje em dia, qualquer ferramenta de SCA que se preze dispõe de reachability analysis . Quando uma dependência apresenta uma vulnerabilidade conhecida, estas ferramentas permitem-lhe saber se o seu código chama a função afetada. Isto é praticamente imprescindível, pois ajuda as equipas a concentrarem os seus esforços de segurança, em vez de terem de filtrar informação irrelevante. Todos os outros passos na priorização de CVEs de dependências assentam nisto.

Mas o facto de a função vulnerável ser acessível não significa que seja explorável. A acessibilidade significa que o seu código pode executar a função vulnerável, enquanto a explorabilidade significa que um atacante pode satisfazer as condições necessárias para que a falha cause danos.

Assim, as equipas de engenharia que dispõem apenas de um reachability analysis a continuam a ter de identificar manualmente quais as CVEs que constituem realmente um problema ou determinar quais as detecções mais urgentes. Muitas equipas ignoram completamente a triagem manual e limitam-se a aplicar correções a tudo o que ultrapasse um limiar CVSS, e é daí que provêm o ruído e o esforço desperdiçado.

Vamos ver como o « análise de explorabilidade » vai mais além do « reachability analysis ».

O que é o « reachability analysis »?

A maioria das equipas classifica os CVEs de acordo com a gravidade do CVSS, muitas vezes através dos rótulos predefinidos apresentados pelas suas ferramentas de segurança, e algumas acrescentam ainda o EPSS e o KEV (ver glossário no final para as siglas). Estes indicadores descrevem o CVE em termos gerais e atribuem a mesma pontuação a todas as aplicações que utilizam o pacote, pelo que não dizem nada sobre o seu comportamento no seu código.

Reachability analysis verifica se o seu código pode executar a função vulnerável numa dependência, normalmente através do mapeamento da forma como o seu código acede às suas dependências, sob a forma de um gráfico de chamadas. Se uma função vulnerável nunca for chamada, não há praticamente qualquer risco (a menos que a aplicação seja alterada). 

Antes do reachability analysis e do SCA , as ferramentas identificavam todos os CVE em todas as dependências, incluindo pacotes transitivos que o seu código nem sequer chamava. As equipas ou aplicavam correções a tudo o que excedesse um limiar CVSS ou faziam a triagem manualmente. O Reachability mudou isso ao associar cada deteção ao seu código real, para que os engenheiros pudessem dedicar o seu tempo às deteções que realmente importam em produção. Transformou uma fila de alertas de dependências em algo que eles conseguiam realmente resolver.

A acessibilidade funciona a dois níveis. 

• A verificabilidade ao nível da dependência verifica se o seu código importa ou utiliza, de alguma forma, o pacote vulnerável. Isto filtra os pacotes que apenas constam no seu ficheiro de bloqueio como dependências transitivas não utilizadas. 
• A acessibilidade ao nível da função vai mais além e verifica se o seu código chama a função específica que contém o erro; assim, uma aplicação que utilize apenas uma biblioteca XML para gerar documentos é isenta de responsabilidade relativamente a um CVE no analisador dessa biblioteca.

Por que razão o código acessível pode, ainda assim, ser seguro

No entanto, o código acessível não é necessariamente explorável. O código acessível pode continuar a ser seguro quando um atacante não consegue cumprir as condições necessárias para que a falha se manifeste. A maioria das vulnerabilidades requer mais do que a simples execução da função. Requerem uma entrada controlada pelo atacante para que a função seja acedida de uma forma específica, que uma determinada configuração ou funcionalidade esteja ativada, um nível de privilégio específico ou uma implementação em que o resultado possa efetivamente causar danos.

A lista de justificações de estado do VEX (Vulnerability Exploitability eXchange) da CISA inclui «código vulnerável que não se encontra no caminho de execução» e «código vulnerável que não pode ser controlado pelo adversário» como motivos distintos para um produto não ser afetado. O primeiro descreve um veredicto de acessibilidade e o segundo, um veredicto de explorabilidade.

O que torna uma vulnerabilidade CVE explorável numa aplicação

Uma exploração depende normalmente de várias condições se verificarem simultaneamente; por isso, se uma delas não estiver presente na sua aplicação, os ataques falharão. O CVSS tem em conta algumas dessas condições nas suas métricas de explorabilidade, como os privilégios necessários e a interação do utilizador. A exposição real da sua aplicação pode situar-se bem acima ou abaixo da pontuação publicada.

Acessibilidade vs. explorabilidade num CVE do Lodash

CVE-2021-23337 trata-se de uma injeção de comandos na biblioteca de utilitários JavaScript, Lodash. A vulnerabilidade reside no ficheiro do Lodash _.template que afeta as versões anteriores à 4.17.21. lodash insere um valor no código-fonte da função sem o sanitizar, pelo que um atacante que controle essa opção pode passar código em vez de um nome de variável e executá-lo quando o modelo for compilado.

Este CVE tem uma pontuação CVSS de 7,2 e, em outubro de 2026, uma pontuação EPSS de cerca de 21%, superior a 97% dos CVEs pontuados. Não consta no KEV. Estes números podem parecer assustadores, mas esta informação é, obviamente, totalmente independente do contexto da vossa aplicação. 

Vamos analisar três aplicações que dependem todas de uma versão vulnerável do lodash, mas que apresentam diferentes níveis de acessibilidade e explorabilidade.

• A aplicação A nunca liga _.template e utiliza apenas ferramentas de cobrança como mapa e filtro. O « Reachability analysis » pode ignorar esta conclusão, uma vez que a função vulnerável nunca é executada.
• O aplicativo B faz chamadas _.template para gerar um e-mail, com a string do modelo e as opções codificadas de forma estática pelo programador. O Reachability assinala esta situação, uma vez que a função é executada em cada pedido. No entanto, um atacante não consegue influenciar a variável «option», pelo que análise de explorabilidade pode reclassificar a descoberta com uma justificação por escrito.
• A aplicação C insere os dados do pedido nas opções do modelo. A função está acessível e os dados introduzidos pelo atacante chegam à variável «option», pelo que a gravidade da falha se mantém elevada. A implementação de « análise de explorabilidade » aumentaria a gravidade ou a prioridade da falha.

O mesmo CVE requer respostas diferentes, dependendo da aplicação. 

A vulnerabilidade pode variar à medida que o código é alterado

Se uma ferramenta de análise de explorabilidade indicar que o seu código «não é vulnerável», isso reflete apenas o estado atual do seu código e da sua implementação. Um novo ponto de chamada, um novo caminho de entrada, uma alteração na configuração ou uma atualização da imagem base podem alterar esse veredicto.

A correção de 2021 do Lodash adicionou a validação para a opção «variable», mas não incluiu options.imports nomes de chaves, que alimentam o mesmo Function() construtor. Essa segunda rota deu origem à vulnerabilidade CVE-2026-4800, corrigida na versão 4.18.0 do lodash.

Assim, no exemplo anterior, a contaminação de protótipos noutra parte da aplicação poderia alterar a vulnerabilidade da Aplicação B. A contaminação de protótipos permite que um atacante adicione propriedades a Object.prototype (que, se não fores um programador de JS, é aquilo de que quase todos os objetos JavaScript herdam). _.template copia propriedades herdadas para as importações, pelo que um erro de «prototype pollution» em qualquer outro ponto da Aplicação B poderia proporcionar a um atacante esse caminho sem qualquer alteração na Aplicação B _.template código.

Como o « Aikido » verifica se um CVE é explorável

AikidoO CVE análise de explorabilidade analisa o código do repositório juntamente com o contexto associado container , incluindo o Dockerfile, a imagem base, a distribuição e a forma como o container está a ser executado. Utiliza o AgenteAikido , que analisa a forma como o pacote vulnerável é utilizado no seu código ou na imagem container e determina se a vulnerabilidade é explorável no seu ambiente. O agente executa então as ações de triagem que autorizar, que podem ser «ignorar», «adiar», «reverter para uma versão anterior» ou «atualizar». Cada decisão é acompanhada de uma justificação por escrito do agente, que o revisor pode ler antes de aprovar.

Antes de classificar um CVE acessível, é necessário determinar se os dados introduzidos pelo atacante podem chegar ao parâmetro vulnerável e como devem ser a configuração e a implementação para que a falha se manifeste. O CVE análise de explorabilidade realiza essa verificação para cada CVE abrangido e regista o raciocínio subjacente a cada veredicto.

Pode ativar o CVE análise de explorabilidade para os seus repositórios e contentores associados a partir das definições de triagem em Aikido. O guia de configuração explica passo a passo como escolher um âmbito e as ações que o agente pode realizar.

FAQ

O que é um CVE?

Um CVE (Common Vulnerabilities and Exposures) é um identificador único para uma vulnerabilidade de segurança divulgada publicamente, como o CVE-2021-23337. O MITRE gere o programa CVE, e as organizações autorizadas, denominadas «Autoridades de Numeração CVE», atribuem esses identificadores, para que todas as ferramentas e alertas possam referir-se à mesma falha pelo mesmo nome.

O que é o CVSS?

O CVSS (Common Vulnerability Scoring System) classifica a gravidade de uma vulnerabilidade numa escala de 0 a 10, com base na própria falha. A FIRST mantém a norma, atualmente na versão 4.0, e as pontuações correspondem a níveis de gravidade que vão de «baixa» a «crítica». Uma pontuação CVSS descreve a vulnerabilidade em termos gerais, pelo que não pode ter em conta a forma como a sua aplicação utiliza o código afetado.

O que é o EPSS?

O EPSS (Exploit Prediction Scoring System) estima a probabilidade de um CVE vir a ser explorado algures na Internet nos próximos 30 dias. A FIRST publica uma pontuação entre 0 e 1 para cada CVE publicado e atualiza-a diariamente. Uma pontuação EPSS elevada indica interesse por parte de atacantes na Internet, mas não permite saber se a sua própria aplicação está exposta.

O que é o KEV?

O KEV é o catálogo de «Vulnerabilidades Exploradas Conhecidas» da CISA, uma lista de CVEs cuja exploração em ambiente real foi confirmada. As agências federais dos EUA têm de corrigir os CVEs incluídos no KEV dentro dos prazos estabelecidos ao abrigo da Diretiva Operacional Vinculativa 22-01, e a CISA recomenda que todas as organizações utilizem o catálogo para estabelecer prioridades na aplicação de correções. Em outubro de 2026, o catálogo incluía cerca de 1 700 CVEs.