O reachability analysis —ou análise de alcançabilidade— é uma técnica de segurança de software que determina se uma aplicação realmente chama o código vulnerável de um componente de terceiros. Ela trabalha sobre o caminho de execução, não sobre o inventário: uma dependência pode ser declarada, instalada e implantada sem que uma linha do código defeituoso execute. O reachability analysis não produz mais uma pontuação de severidade, e sim a resposta a uma única pergunta: este código pode executar aqui?
Menos de 1.200 das cerca de 350.000 vulnerabilidades de código aberto rastreadas pelo banco de dados da Fluid Attacks têm regras de alcançabilidade em nível de função. Essa proporção mede até onde a técnica chega hoje, e explica por que o reachability analysis serve para priorizar, não para silenciar um achado.
Esta página cobre o que é o reachability analysis, no que diferem a abordagem estática e a dinâmica, como a Fluid Attacks reporta três níveis em vez de um binário alcançável/não alcançável, o que CISA e OWASP dizem sobre caminhos de execução, e onde a técnica deixa de ser confiável.
O que é reachability analysis ou análise de alcançabilidade?
O reachability analysis rastreia os caminhos de execução de uma aplicação para estabelecer se a função, classe ou módulo afetado por uma vulnerabilidade conhecida é invocado a partir do código avaliado. É a pergunta que ele existe para responder. Um pacote costuma trazer várias vulnerabilidades e a aplicação usa apenas algumas funções. A técnica separa o que uma aplicação contém do que ela exercita, a distinção que todo relatório de dependências achata.
O escopo pode ir além das dependências diretas. Quase todo código vulnerável chega por dependências transitivas: bibliotecas que arrastam outras bibliotecas, que os desenvolvedores raramente escolhem e às vezes nem conseguem nomear. O reachability analysis segue essas cadeias e reporta qual elo leva a uma função vulnerável.
O que o reachability analysis não faz é provar explorabilidade. Chegar ao código vulnerável é condição necessária para a exploração, não suficiente: o atacante ainda precisa de uma entrada que possa controlar, de uma implantação compatível e de nenhum controle compensatório no caminho. O reachability analysis também não substitui a análise de composição de software: é a camada que dá contexto de aplicação aos achados de SCA, e se lê junto com eles.
Por que o reachability analysis importa
A varredura de dependências produz mais achados do que uma equipe consegue tratar, e a severidade não os ordena bem. É aí que entra o reachability analysis. A análise de alcançabilidade traz a única variável que muda a priorização de vulnerabilidades: se aquele código executa ou não nesta aplicação.
Inventários reportam presença, não risco
Uma lista de materiais de software responde "o que há aqui dentro", não "o que isto faz aqui". A documentação da Fluid Attacks sobre SCA aponta que combinar a varredura de dependências com testes estáticos de segurança é o que permite identificar vulnerabilidades alcançáveis: casos em que o produto avaliado de fato usa o elemento inseguro da dependência.
Sem um reachability analysis, cada pacote declarado com um advisory pesa igual aos demais. Ele transforma esse inventário plano em uma fila ordenada.
A lacuna é grande. Uma estimativa reportada pela Dark Reading situa o uso típico em 10 % a 20 % do código importado: o número de um especialista, não uma constante medida, mas a direção se sustenta.
A severidade herda premissas de montante
Sistemas de pontuação feitos para o caso geral repassam seu conservadorismo adiante. A análise da Fluid Attacks sobre severidade constatou que as ferramentas costumam herdar as pontuações base da NVD ou dos advisories do fornecedor e exibi-las sem ajustá-las por alcançabilidade, explorabilidade ou contexto do cliente, de modo que essas premissas passam sem questionamento (argumento completo aqui).
Há um caso concreto no banco de dados da Fluid Attacks. CVE-2022-23848, uma injeção de comandos em um componente Maven do Alluxio, traz uma pontuação CVSS original de 9,8, crítica, na versão 3.1. A pontuação ajustada pela Fluid Attacks na v4.0 para a mesma entrada é 4,4, média, com um EPSS de 1,21 %. A mesma vulnerabilidade, duas filas de remediação muito diferentes. A análise de alcançabilidade é a correção local, contra o código que de fato vai executar.
CVE-2022-23848 no banco de dados da Fluid Attacks: crítica no CVSS v3.1 (9,8), média no CVSS v4.0 ajustado (4,4).
Muda o que se corrige primeiro
Priorizar só serve se mover a remediação. O reachability analysis é a variável que consegue isso. No Relatório de ataques 2026 da Fluid Attacks, sobre 1.119.396 vulnerabilidades reportadas em sistemas de clientes em 2025, os sistemas com CI Gate alcançaram remediação de 72,2 % contra 58 % dos que não o usavam. O reachability analysis dá a esse portão o seu critério: uma compilação deveria quebrar por código que executa, não por uma entrada num lockfile.
Alcançabilidade, presença e explorabilidade não são a mesma coisa
Quase todo relatório de dependências reúne em uma só três afirmações que exigem evidências distintas. O reachability analysis responde uma das três. Separá-las é o que o torna útil em vez de mais um rótulo, e o que evita que seu resultado seja lido como atestado de boa saúde.
Afirmação | O que sustenta | Evidência exigida | O que não pode dizer |
Presença | Um componente com advisory conhecido faz parte da compilação | Entrada no manifesto ou no lockfile, versão resolvida, registro no SBOM | Se algo do seu código é importado ou executado |
Alcançabilidade | O código da aplicação chama, ou leva, à função vulnerável | Grafo de chamadas ou rastro em execução, com caminho do arquivo e linha de código | Se um atacante consegue controlar a entrada que chega até ali |
Explorabilidade | Um atacante consegue acionar a falha nesta implantação | Caminho alcançável, entrada controlada pelo atacante, runtime e configuração compatíveis, sem mitigação | O quanto a organização deveria se importar, que é uma pergunta de risco |
As três afirmações por trás de um achado de dependência, e a evidência que cada uma exige.
A pontuação CVSS descreve a segunda e a terceira coluna para um produto genérico, não para o seu. O EPSS estima a atividade de exploração real, de novo para a vulnerabilidade e não para a sua implantação. O reachability analysis é o único dos três sinais que sai do seu código-fonte, e por isso merece a mesma visão que os outros dois.
A alcançabilidade e o EPSS medem coisas diferentes: uma vulnerabilidade pode ser alcançável, ter EPSS alto, ambas as coisas ou nenhuma.
Ler a coluna do meio como se fosse a da direita é o uso indevido mais comum do reachability analysis, e o que produz confiança injustificada.
Reachability analysis na Fluid Attacks
A Fluid Attacks executa reachability analysis estático dentro de suas varreduras de SCA e reporta o resultado como atributo de priorização na sua plataforma de ASPM, nunca como achado próprio. A decisão de projeto da sua análise de alcançabilidade é deliberada: sobe a prioridade do que consegue confirmar e nunca baixa a do que não consegue.
Três níveis, e nenhum "não alcançável"
A análise de alcançabilidade da Fluid Attacks reporta três níveis em vez de um veredito binário, separando o que foi declarado, o que foi importado e o que foi chamado.
Nível | Condição no código | Cobertura | Efeito na pontuação de prioridade |
Latent | A dependência vulnerável está declarada no gerenciador de pacotes, mas nenhum arquivo a importa | Todos os CVE e advisories das fontes, linguagens e gerenciadores suportados | Redução máxima |
Potential | A dependência está declarada e importada, mas a função afetada não é chamada | Igual a Latent | Redução menor |
Reachable | A dependência está declarada, importada, e essa função é chamada a partir do código | Apenas os CVE e advisories com regra de alcançabilidade publicada | Sem redução |
Os três níveis que a Fluid Attacks reporta, e o que cada um faz com a prioridade de um achado.
O quarto rótulo ausente é o ponto. Não existe o estado "não alcançável": um caminho não encontrado é um limite da análise, não uma propriedade da aplicação. Chamar um achado de não alcançável converte um desconhecido em tranquilidade, e as equipes agem sobre tranquilidades.
Como isso aparece na prática
A técnica só é acionável se entregar ao desenvolvedor uma localização em vez de um veredito.
Na seção Packages, as dependências com advisories aparecem como Vulnerable e, com confirmação, levam a etiqueta "Reachable". Ao expandir a linha e seguir a vulnerabilidade relacionada, identifica-se o caminho do arquivo e a linha de código que chama ou leva à função afetada. O achado aparece também em Vulnerabilities, com origem Inherited e uma captura do código em contexto.
Na seção Packages, uma dependência vulnerável com chamada confirmada leva a etiqueta Reachable (CVE-2020-28500 no lodash).
O achado aponta o arquivo e a linha de código que chamam a função afetada: index.js, linha 24.
Essa é a diferença entre "atualize o lodash" e "a linha 24 de index.js chama a função afetada". Um é um chamado; o outro é um conserto.
Regras determinísticas em vez de inferência probabilística
Os pesquisadores da Fluid Attacks revisam os advisories de terceiros e escrevem regras que identificam o uso de cada função afetada no código do cliente. São publicadas por ecossistema e o changelog registra cada lote: o Release 41, de outubro de 2026, somou 32 regras. A documentação comparativa registra o reachability analysis resultante como determinístico, diante das abordagens probabilísticas que inferem a probabilidade de uso.
A contrapartida é explícita. Uma regra determinística só dispara para uma vulnerabilidade que alguém modelou, então a cobertura cresce de um CVE por vez. O que ela compra é que uma etiqueta Reachable significa que uma chamada foi encontrada, não estimada.
Onde a técnica para: cerca de 0,3 % de cobertura
O filtro do banco de dados público mostra a cobertura real da análise de alcançabilidade em nível de função. Em outubro de 2026 ele retornou 1.154 suportadas, 344.698 não suportadas e 3.664 impossíveis, sobre 349.516 vulnerabilidades rastreadas em 15 ecossistemas: cerca de 0,3 % de cobertura em nível de função, com Latent e Potential carregando o resto.
Filtro Reachability no banco de dados da Fluid Attacks, outubro de 2026: 1.154 suportadas, 344.698 não suportadas e 3.664 impossíveis, de 349.516.
Um segundo limite foi publicado em vez de absorvido em silêncio. No Release 32, a Fluid Attacks restringiu a detecção de CVE em runtime para .NET, Node.js, Bun e Python após concluir que os campos de manifesto em que se apoiava declaram compatibilidade, não o que se implanta, de modo que um CVE levantado dali podia não se aplicar. Retirar uma fonte de detecção é a correção que esta técnica exige: seu valor repousa em que seus positivos signifiquem algo.
A prática que decide o resto
Os resultados do reachability analysis vencem. Uma atualização de dependência ou uma funcionalidade nova transformam um achado Potential em Reachable entre dois commits, o que torna enganosa por projeto qualquer análise de um único momento.
A Fluid Attacks reexecuta o reachability analysis quando o código muda e atualiza seu banco de dados a cada quatro horas. Desde outubro de 2026, a alcançabilidade é o sétimo critério de prioridade da plataforma, ao lado do CVSSF e das demais entradas de pontuação.
"Figure out the attack surface and make sure the tainted input can never reach what you are trying to protect."
— Rafael Ballestas, analista de segurança na Fluid Attacks, em Tainted love
▶️ Vídeo: explicamos o que é a análise de alcançabilidade, como ela determina se as vulnerabilidades das dependências são realmente exploráveis e o que muda na priorização de vulnerabilidades. (em espanhol)
Para aprofundar: o guia da Fluid Attacks sobre benchmark de ferramentas de AppSec explica por que as comparações de SCA deveriam normalizar os achados por vulnerabilidades únicas e acionáveis, não por referências duplicadas a dependências.
Como se faz o reachability analysis
Duas abordagens produzem evidência para a análise de alcançabilidade e falham em direções opostas. Uma lê o código; a outra o observa executar. A maioria dos programas maduros constrói seu reachability analysis sobre a primeira e confirma de forma seletiva com a segunda.
Análise estática de alcançabilidade
O reachability analysis estático examina o código sem executá-lo: resolve importações e pontos de chamada para construir um grafo de chamadas que liga as entradas da aplicação a funções das dependências. Roda a cada commit e não precisa de ambiente implantado, o que o coloca no SDLC a tempo de barrar uma chamada vulnerável antes da produção.
Seus pontos cegos são as partes do programa que só existem em execução: reflexão, despacho dinâmico, carga de plugins e caminhos escolhidos por configuração ou dados externos. O modelo é uma aproximação, e aproximações omitem coisas.
Análise dinâmica de alcançabilidade
A análise dinâmica instrumenta a aplicação em execução e registra qual código de dependências é carregado e executado sob condições reais. Esse reachability analysis resolve o que a análise estática aproxima, corta falsos positivos e revela anomalias como acessos a arquivos ou conexões de saída inesperadas a partir de uma biblioteca.
O custo é a cobertura. Uma execução só prova os caminhos exercitados; um não exercitado não devolve evidência em nenhum sentido. Some a sobrecarga de instrumentação, o volume de dados e a dificuldade de forçar cada combinação de entradas, e a análise dinâmica fica como ferramenta de verificação, não como uma contínua.
Combinar análise estática e dinâmica
Dimensão | Estática | Dinâmica |
Quando roda | A cada commit, antes da implantação | Sobre uma compilação em execução e instrumentada |
Evidência que produz | Grafo de chamadas, caminho do arquivo e linha de código | Registros de chamadas executadas em condições reais |
Ponto cego principal | Comportamento só em execução: reflexão, carga dinâmica, caminhos por configuração | Caminhos não exercitados durante a execução |
Custo principal | A aproximação de um modelo | Sobrecarga de instrumentação e volume de dados |
Melhor uso | Priorização contínua em todo o código | Confirmar ou escalar um achado pontual |
O que cada abordagem do reachability analysis pode e não pode estabelecer.
A combinação funciona como sequência, não como mistura: o reachability analysis estático monta a fila e as execuções dinâmicas resolvem os casos em disputa.
O que os padrões já dizem sobre caminhos de execução
O reachability analysis não é um conceito de fornecedor: a pergunta que ele responde está escrita na forma como agências e organismos de padrões esperam que o risco de dependências seja comunicado.
Os Requisitos mínimos para o Vulnerability Exploitability eXchange (VEX) da CISA, de 2023, definem um documento VEX como a via para um fornecedor declarar que um produto não é afetado por uma vulnerabilidade de um de seus componentes. Essa declaração se apoia em um reachability analysis.
Uma das cinco justificativas permitidas para esse estado é Vulnerable_code_not_in_execute_path, definida como o caso em que "the vulnerable code (likely in [subcomponent_id]) cannot be executed due to the way it is used by [product_id]". Isso é reachability analysis escrito como obrigação de divulgação, e por isso seus resultados pertencem à comunicação com o fornecedor e não apenas a um painel.
O complemento é a lista de materiais de software, o inventário que esses documentos anotam. O OWASP Top 10:2025 posiciona as falhas da cadeia de suprimentos como A03 e reporta a maior taxa de incidência média de qualquer categoria, 5,19 % nos seus dados contribuídos, sobre 215.248 ocorrências registradas.
A OWASP pede rastrear dependências diretas e transitivas, e reduzir a superfície de ataque removendo componentes sem uso. O reachability analysis é como uma organização descobre quais são.
Lidos juntos, os dois padrões descrevem um fluxo: inventariar, decidir com reachability analysis e divulgar com VEX.
Dois casos que mostram para que serve o reachability analysis
Os dois casos são falhas de triagem, não de detecção, e os dois são o argumento prático do reachability analysis. Em ambos o componente vulnerável foi identificado rápido, e a pergunta que a técnica responde —esta aplicação executa aquele código?— ninguém conseguiu responder a tempo.
Log4Shell (CVE-2021-44228). É o caso que mais se cita quando se fala de reachability analysis. A OWASP ainda lista a execução remota de código do Apache Log4j entre seus exemplos de componentes exploráveis, e 2021 é o caso de referência do pânico por dependências: a biblioteca estava enterrada em artefatos de compilação, quase sempre arrastada de forma indireta, e poucas organizações conseguiram estabelecer rápido onde ela estava.
O reachability analysis em nível de função não teria salvado cada instância —Log4Shell foi amplamente explorada—, mas é exatamente a técnica para a pergunta que essas equipes responderam à mão durante semanas (Log4Shell explicado).
O comprometimento do npm em 2025. Em setembro de 2025, 18 pacotes npm muito usados, com cerca de 2,6 bilhões de downloads semanais, foram publicados com versões maliciosas após um phishing contra uma conta de mantenedor.
Como a Fluid Attacks reportou na época, nem todas as aplicações que usavam os pacotes comprometidos foram afetadas: a exposição exigia uma instalação limpa, ou um package-lock.json criado com as versões maliciosas ativas (análise completa). Presença e exposição eram, mais uma vez, perguntas diferentes. O reachability analysis as separa antes que um incidente obrigue a isso.
Desafios e limites do reachability analysis
A escala é a primeira restrição. Construir grafos de chamadas sobre um código grande e poliglota consome computação e tempo, e a exatidão é negociada contra a velocidade: uma análise mais barata eleva falsos positivos e negativos, o que anula o propósito do reachability analysis.
Código ofuscado, minificado ou proprietário dentro de dependências de terceiros resiste ao rastreio. Também resiste o que a linguagem resolve em execução, e por isso a cobertura da análise de alcançabilidade varia por ecossistema.
O resultado ainda se degrada: cada atualização de dependência pode mover uma função afetada para dentro ou para fora do caminho de chamadas, então o reachability analysis precisa ser reexecutado quando o código e os advisories mudam.
O limite que mais pesa é o que dá mais tentação ignorar: um resultado negativo não é prova de segurança. Significa que este reachability analysis, com suas lacunas de cobertura conhecidas, não encontrou um caminho neste momento.
A detecção automatizada sozinha tampouco fecha a lacuna que a análise de alcançabilidade deixa. No benchmark da Fluid Attacks sobre 36 ferramentas de AppSec de terceiros contra 1.201 vulnerabilidades em 105 categorias CWE, o scanner automatizado de melhor desempenho —o da própria Fluid Attacks— detectou 22,7 % com 99 % de precisão; um pentester achou 89,6 % com 100 %. O reachability analysis organiza o trabalho; não o termina.
Conclusões
O reachability analysis responde uma pergunta mais estreita do que quase toda ferramenta de dependências finge responder, e essa estreiteza é seu valor. Ele diz se o seu código chama o código afetado: a diferença entre uma entrada de inventário e um defeito que se entrega a um desenvolvedor com caminho de arquivo e linha. Isso é priorização de vulnerabilidades com evidência anexada, e é o que um reachability analysis bem usado entrega.
Como atributo de priorização, o reachability analysis funciona. Como filtro, a análise de alcançabilidade converte em silêncio uma lacuna de cobertura em uma afirmação de segurança. O projeto de reachability analysis que vale a pena copiar é o que só fala quando tem evidência: três níveis em vez de dois, nenhum rótulo "não alcançável", regras determinísticas com cobertura publicada e reexecução contínua: a resposta muda a cada commit.
Perguntas frequentes
O reachability analysis é o mesmo que análise de composição de software?
Não. O SCA identifica os componentes de terceiros que uma aplicação inclui e os cruza com bancos de dados de vulnerabilidades. O reachability analysis é uma camada acima: determina se o código da aplicação chama a função vulnerável dentro desses componentes. O SCA diz o que você tem; ele diz o que você usa.
É o mesmo que análise de acessibilidade?
É o mesmo conceito com outra tradução. Alguns fornecedores e documentações localizadas traduzem reachability analysis como análise de acessibilidade; a documentação da Microsoft em português usa "SCA baseada em acessibilidade" e "vulnerabilidades alcançáveis" na mesma página. Não deve ser confundido com acessibilidade digital, que é outra disciplina.
Um resultado "não alcançável" significa que a vulnerabilidade não pode ser explorada?
Não, e tratá-lo assim é o principal modo de falha. Um resultado negativo significa que aquele reachability analysis não encontrou um caminho de execução, dentro da sua cobertura e naquele momento. Reflexão, carga dinâmica, comportamento por configuração e CVE não modelados produzem falsos negativos. A Fluid Attacks evita por isso o rótulo "não alcançável" e classifica os achados como Latent ou Potential.
O reachability analysis substitui o CVSS e o EPSS?
Não, ele os complementa. O CVSS descreve a severidade para uma implantação genérica e o EPSS estima a atividade de exploração real; nenhum olha o seu código-fonte. Na plataforma da Fluid Attacks, a alcançabilidade passou a ser o sétimo critério de prioridade em outubro de 2026, usada junto a essas pontuações e não no lugar delas.
O reachability analysis cobre dependências transitivas?
Depende do nível. Na Fluid Attacks, a classificação Latent e Potential cobre todo advisory das suas fontes suportadas, dependências transitivas incluídas. A detecção Reachable em nível de função rastreia hoje dependências diretas, e estendê-la está no roteiro publicado. O OWASP Top 10:2025 faz o argumento de governança para rastrear ambas.
A Fluid Attacks usa reachability analysis e quanto cobre?
Sim, dentro das suas varreduras de SCA e com cobertura publicada. Das cerca de 350.000 vulnerabilidades de código aberto que seu banco de dados rastreia em 15 ecossistemas, cerca de 1.150 têm regras de alcançabilidade em nível de função. Latent e Potential se aplicam a todos os advisories suportados, e cada release traz regras novas.
Faça da alcançabilidade o critério de desempate, não o rótulo
Nossos scanners e pentesters trabalham a partir do seu código-fonte, então um achado de dependência chega à sua equipe com a linha que o invoca, não com uma severidade emprestada de outra implantação: essa é a base da nossa segurança da cadeia de suprimentos de software. Teste gratuito · Fale conosco.
Comece agora com a solução SSCS da Fluid Attacks
