Análise de alcançabilidade

Porque existe

Uma análise SCA cruza as versões dos pacotes com avisos de segurança. Sabe que uma versão contém uma falha, mas não se a sua aplicação usa a parte que tem a falha. Uma biblioteca com centenas de funções e um parser vulnerável é reportada da mesma forma quer chame esse parser quer não, e numa árvore de dependências grande isso resulta num backlog que ninguém consegue terminar.

Como funciona a análise de alcançabilidade

1. Encontrar o código vulnerável. A ferramenta precisa de saber em que função se encontra uma vulnerabilidade. Os avisos de segurança muitas vezes não o dizem, pelo que os fornecedores mantêm os seus próprios dados.
2. Construir um grafo de chamadas. Mapeia que funções chamam que funções, desde o seu código até às dependências.
3. Procurar um caminho. Se uma cadeia de chamadas levar do seu código à função vulnerável, a conclusão é alcançável. Se não, é marcada como inalcançável e fica com uma classificação mais baixa.

Níveis de alcançabilidade

Nível	Pergunta a que responde	Contrapartida
Dependência	O pacote é sequer importado?	Barato, e remove apenas dependências não usadas
Função	Um caminho de chamadas pode chegar à função vulnerável?	O objetivo habitual, e exige um grafo de chamadas e dados de vulnerabilidades por função
Tempo de execução	Este código foi carregado ou executado em produção?	Evidências do tráfego real, mas apenas do que foi executado enquanto observava

Uma exploração real precisa de mais do que um caminho. Os dados de entrada têm de chegar à função numa forma que desencadeie a falha, algo que poucas ferramentas conseguem determinar.

Onde a análise de alcançabilidade fica aquém

• Inalcançável não significa seguro. Significa que a ferramenta não encontrou nenhum caminho. A reflexão, as importações dinâmicas e o carregamento de plugins podem criar caminhos que a análise estática não vê.
• A cobertura de linguagens varia. As linguagens compiladas estaticamente são mais fáceis de seguir do que as dinâmicas, e as ferramentas diferem quanto aos ecossistemas que têm análise ao nível da função.
• Os dados de vulnerabilidades são incompletos. Se ninguém tiver associado um aviso de segurança a uma função, a ferramenta não tem nada para procurar.
• Muda com o seu código. Uma conclusão inalcançável hoje pode ser alcançável depois da próxima versão, pelo que a resposta tem de ser verificada novamente.
• Só ordena o que foi identificado. Um componente que o scanner nunca encontrou não pode ser analisado. Sem um inventário completo, a alcançabilidade ordena apenas parte do quadro.

Como a usar com segurança

• Use-a para ordenar o trabalho, não para o descartar. Corrija primeiro as conclusões alcançáveis e agende as restantes, em vez de as fechar.
• Não a deixe sobrepor-se à exploração ativa. Uma conclusão que consta do catálogo KEV da CISA ou com uma pontuação EPSS elevada merece uma decisão humana, mesmo que esteja marcada como inalcançável.
• Tenha cuidado com serviços expostos à internet. O custo de uma resposta errada é mais elevado onde os atacantes o conseguem alcançar diretamente.
• Registe o raciocínio. Se decidir que uma conclusão não se aplica, uma declaração VEX guarda a decisão e explica o motivo aos seus clientes.

Para saber como a alcançabilidade se articula com a gravidade, os dados de exploração e o contexto de negócio, consulte como priorizar vulnerabilidades.

Que ferramentas oferecem análise de alcançabilidade?

Muitas ferramentas comerciais de SCA oferecem-na, entre elas o Snyk, o Endor Labs, o Mend, o Checkmarx, o Semgrep e o Aikido, e a profundidade varia consoante a linguagem. O govulncheck do Go é um exemplo gratuito para um ecossistema. Consulte as melhores ferramentas de SCA comparadas para saber o que cada uma cobre.

Onde se enquadra o CRACI

O CRACI não oferece análise de alcançabilidade. Trabalha no passo anterior: saber o que está no build. É um runner de GitHub Actions que regista cada pacote que cada job obtém, incluindo as dependências ocultas que escapam aos scanners de lockfiles, e continua a reavaliar as SBOM do que foi distribuído à medida que são publicadas novas vulnerabilidades. Se a alcançabilidade for a sua principal prioridade, use uma ferramenta criada para isso a par do CRACI. Consulte onde o CRACI se enquadra junto das suas ferramentas de SCA.

Análise de alcançabilidade: perguntas frequentes

O que é a análise de alcançabilidade em SCA?

Verifica se o seu código pode efetivamente chamar a função vulnerável de uma dependência, para que as conclusões sem caminho a partir do seu código possam ter uma classificação mais baixa.

A análise de alcançabilidade é exata?

É útil, mas não é uma prova. Uma conclusão alcançável tem um caminho real, enquanto uma inalcançável significa apenas que a ferramenta não encontrou nenhum. A reflexão, o carregamento dinâmico e as lacunas nos dados de vulnerabilidades podem ocultar um caminho.

Pode ignorar as vulnerabilidades inalcançáveis?

Não as ignore por completo. Agende-as depois das conclusões alcançáveis, volte a verificá-las após alterações ao código e dê atenção redobrada a tudo o que esteja a ser ativamente explorado ou a ser executado num serviço exposto à internet.

Qual é a diferença entre alcançabilidade e explorabilidade?

A alcançabilidade pergunta se o código consegue chegar à função vulnerável. A explorabilidade pergunta se um atacante consegue usar esse caminho para causar danos. Uma falha pode ser alcançável e, ainda assim, não ser explorável na sua configuração.

A análise de alcançabilidade reduz os alertas?

Sim, é esse o seu principal objetivo. A redução depende da linguagem, da ferramenta e da parte de cada dependência que o seu código usa.