O scanner abre dezenas ou centenas de alertas. Todos parecem urgentes: severidade alta, pacote popular e versão afetada. A equipe começa a atualizar dependências, mas descobre que parte delas é usada apenas em testes, outra não chama a função vulnerável e uma terceira está numa rota crítica exposta à internet.
Tratar tudo pela mesma fila aumenta o tempo até corrigir o que realmente importa. A análise de alcançabilidade de vulnerabilidades acrescenta contexto: constrói um grafo de chamadas e procura um caminho do código da aplicação até a função vulnerável presente numa dependência.
Em 28 de outubro de 2026, o GitHub anunciou reachability analysis para alertas do Dependabot em JavaScript e TypeScript. O recurso usa CodeQL e dados curados sobre funções afetadas para mostrar evidências do caminho. A novidade não substitui o alerta nem declara que um pacote é seguro; ela ajuda a priorizar.
Por que a severidade não basta?
CVSS descreve características técnicas e impacto potencial. Ele não sabe se a empresa usa o pacote, se a função vulnerável é chamada, se o serviço está exposto, se existem controles compensatórios ou qual ativo suporta uma operação crítica.
Dois sistemas podem ter o mesmo CVE e riscos diferentes. Uma biblioteca alcançável num endpoint público de pagamentos deve avançar na fila. A mesma biblioteca instalada por uma ferramenta de desenvolvimento e nunca carregada em produção ainda precisa de gestão, mas pode ter prioridade menor.
Como a análise de alcançabilidade funciona
- identifica a dependência e as funções associadas ao aviso de segurança;
- analisa código, imports, módulos e relações entre chamadas;
- constrói um grafo que atravessa aplicação e dependências;
- procura um caminho do código próprio até a função afetada;
- apresenta um veredito e, quando possível, amostras do caminho.
O grafo transforma um alerta abstrato numa pergunta concreta: qual entrada da aplicação pode chegar ao trecho vulnerável?
Como interpretar os vereditos
Alcançável
Existe pelo menos um caminho identificado até a função vulnerável. Priorize a correção e examine a evidência para entender a superfície exposta.
Potencialmente alcançável
A análise não conseguiu excluir o caminho. Trate com prioridade semelhante a “alcançável” até investigar a incerteza.
Não alcançável
Nenhum caminho foi encontrado no momento da análise. Reduza a prioridade relativa, mas não encerre o alerta apenas por esse resultado: uma mudança de código pode criar o caminho amanhã.
Indisponível
O ecossistema, o tamanho do repositório ou uma falha impediram o veredito. Use os demais sinais normalmente.
Exemplo: API de comércio eletrônico
Uma API Node.js usa uma biblioteca de datas em três pontos. Um aviso informa falha numa função de parsing. O pacote aparece em produção e o alerta tem severidade alta. A análise encontra um caminho do endpoint de importação de pedidos até a função afetada, passando por um módulo interno.
Esse caminho não prova exploração, mas responde duas perguntas: o código pode chamar a função e qual fluxo faz isso. A equipe pode desativar temporariamente a importação, validar entradas, atualizar o pacote e criar um teste de regressão focado na rota.
Outro serviço possui a mesma versão, mas usa apenas formatação e não possui caminho para a função de parsing. O alerta permanece aberto, porém entra numa janela normal de atualização em vez de interromper uma entrega crítica.
Alcançabilidade não é explorabilidade
Uma função alcançável pode exigir uma entrada impossível para um atacante, estar protegida por autenticação ou ter uma mitigação ativa. Do outro lado, análise estática pode não enxergar reflexão, código gerado, carregamento dinâmico e relações distribuídas.
O próprio GitHub recomenda combinar alcançabilidade com severidade, EPSS, contexto de produção e conhecimento da aplicação. O veredito é evidência, não sentença.
Um modelo de priorização mais completo
- Alcançabilidade: existe caminho do código até a função afetada?
- Exposição: o caminho começa em internet, utilizador interno ou processo isolado?
- EPSS: qual é a probabilidade estimada de exploração nos próximos 30 dias?
- CISA KEV: existe exploração confirmada no mundo real?
- Impacto: quais dados, privilégios e operações podem ser afetados?
- Criticidade do ativo: o serviço sustenta receita, segurança ou continuidade?
- Controles: autenticação, WAF, segmentação ou validação reduzem o risco?
EPSS é atualizado diariamente e estima probabilidade, mas não conhece o ambiente da empresa. O catálogo KEV confirma exploração observada. A alcançabilidade adiciona contexto do código. Juntos, esses sinais orientam melhor do que uma nota isolada.
Integre o resultado ao fluxo de desenvolvimento
- mantenha lockfiles e inventário de dependências atualizados;
- associe repositório, serviço, ambiente e proprietário;
- execute análise regularmente e após mudanças relevantes;
- envie alertas alcançáveis para a equipe responsável com evidência;
- crie SLA por risco, não apenas por severidade;
- registre mitigação, atualização, teste e validação;
- reanalise depois da correção e de mudanças no grafo.
O artigo sobre lockfiles no CI/CD mostra como tornar as dependências executadas reproduzíveis. A alcançabilidade responde a outra pergunta: como a aplicação utiliza a dependência vulnerável.
Limitações que precisam aparecer no processo
- suporte de linguagem e ecossistema pode ser parcial;
- monorepos grandes podem atingir limites de análise;
- caminhos dinâmicos podem gerar incerteza;
- o veredito representa o código e o aviso naquele momento;
- “não alcançável” não autoriza ignorar atualização indefinidamente;
- um caminho alcançável não demonstra que o ataque terá sucesso.
Durante a prévia anunciada pelo GitHub, o recurso atende JavaScript e TypeScript com npm, Yarn ou pnpm e depende de lockfile. Essas restrições devem ser consideradas antes de transformar o resultado em política empresarial.
Métricas para reduzir risco e ruído
Acompanhe tempo para corrigir vulnerabilidades alcançáveis, percentagem de alertas com veredito, idade por criticidade, cobertura de repositórios, reincidência e exceções vencidas. Compare também quantas interrupções urgentes resultaram em risco confirmado.
Uma boa prática não busca fechar mais alertas por semana. Ela reduz o intervalo entre descobrir e mitigar os caminhos que podem afetar produção.
Segurança orientada por contexto
A análise de alcançabilidade aproxima segurança e engenharia. O time deixa de discutir apenas a nota do CVE e passa a analisar o caminho real, o ativo, a exposição e a consequência. Isso melhora prioridades sem fingir certeza onde a ferramenta não possui evidência.
A ProativaIA desenvolve software sob medida, aplicativos e pipelines seguros. Podemos integrar inventário, análise de dependências, classificação contextual e automação de remediação ao ciclo de desenvolvimento da sua empresa.