Ter uma dependência vulnerável nem sempre significa que seu aplicativo chama a função afetada. Reachability analysis adiciona um veredicto a cada Dependabot alerta para ajudá-lo a priorizar correções com base em como seu código usa a dependência.
Observação
Reachability analysis para Dependabot alerts está em prévia pública e sujeito a alterações.
Como reachability analysis funciona
Reachability analysis analisa seu open Dependabot alerts para determinar se seu aplicativo pode chamar as funções vulneráveis. Ele usa CodeQL análise estática e dados curados que identificam as funções afetadas para procurar caminhos de chamada do seu código até essas funções.
Cada alerta analisado Dependabot recebe um veredicto que ajuda você a decidir sua prioridade. Quando disponível, as evidências de caminho de chamada mostram como seu código pode alcançar uma função vulnerável, para que você possa entender por que um alerta é importante para seu aplicativo.
Requisitos e ecossistemas com suporte
Reachability analysis dá suporte a repositórios JavaScript que usam npm, pnpm ou Yarn, e a repositórios TypeScript. Seu repositório deve ter um arquivo de bloqueio, como package-lock.json, pnpm-lock.yamlou yarn.lock.
Dependabot alerts deve ser habilitado para reachability analysis funcionar.
A análise é executada em executores hospedados em GitHub. Não há suporte para executores auto-hospedados.
Compreendendo veredictos de alcance
Use a alcançabilidade juntamente com a severidade, as pontuações do EPSS (Exploit Prediction Scoring System), o escopo da dependência e a relação de dependência para decidir quais alertas devem ser resolvidos primeiro.
| Verdito | Meaning | Resposta recomendada |
|---|---|---|
| Acessível | A análise encontrou pelo menos um caminho de chamada do código do repositório para uma função vulnerável. | Dê prioridade à correção e examine as evidências do caminho da chamada. |
| Potencialmente alcançável | A análise não pôde descartar uma chamada para uma função vulnerável. Essa incerteza não é causada por um ecossistema sem suporte ou por uma verificação com falha. Em repositórios com vários manifestos, as chamadas encontradas somente fora do diretório de um manifesto são consideradas potencialmente acessíveis. | Dê prioridade à correção juntamente com alertas alcançáveis. |
| Inacessível | A análise foi concluída e não encontrou uma chamada, a partir do código do seu aplicativo, para uma função vulnerável. | Dê ao alerta uma prioridade mais baixa, mas não ignore ou feche-o apenas por causa deste veredicto. |
| Conectividade indisponível | A análise não pôde fornecer um veredicto, por exemplo, porque o alerta é para um ecossistema sem suporte ou a verificação falhou ou atingiu o tempo limite. | Faça a triagem do alerta usando os outros sinais de priorização. |
Use o alcance para priorizar, não fechar, alertas
Reachability analysis adiciona informações aos alertas abertos existentes para ajudá-lo a priorizar a correção. Não encontra novas vulnerabilidades nem fecha ou descarta alertas automaticamente.
Um veredicto é uma avaliação em um dado momento. Você não deve fechar ou ignorar um alerta apenas com base em seu veredicto de alcançabilidade; embora uma função possa não ser alcançável a partir do seu código hoje, alterações de código ou atualizações em um aviso podem alterar o resultado de uma varredura posterior.
A alcançabilidade não é a explorabilidade
Uma função acessível não é necessariamente explorável. A alcançabilidade mostra que existe um caminho de chamada, não que um invasor possa usá-lo para explorar a vulnerabilidade.
Da mesma forma, um veredicto "Inacessível" não é uma garantia de que uma dependência é segura. Continue revisando esses alertas e mantenha as dependências atualizadas.
Evidência do caminho de chamada
Para alertas acessíveis, as evidências de caminho de chamada mostram como uma chamada de seu código pode levar a uma função vulnerável. Use essa evidência para entender onde seu aplicativo usa a dependência afetada e planeje a correção.
Um alerta pode mostrar até cinco caminhos de exemplo. Esses exemplos não são uma lista completa de todos os caminhos de chamada possíveis.
Entendendo quando os resultados são atualizados
Ativar reachability analysis inicia uma verificação inicial dos alertas abertos do repositório. Depois disso, as verificações são executadas uma vez a cada 24 horas, enquanto o repositório tem alertas abertos. Cada verificação abrange todos os alertas abertos.
O envio por push de alterações de código não dispara uma verificação. Depois de alterar seu código, o veredicto não refletirá essas alterações até que uma verificação subsequente seja concluída.
Durante prévia pública, você não pode agendar ou disparar verificações sob demanda.
A duração da verificação depende do tamanho do repositório e das dependências. As verificações podem ser concluídas em alguns minutos, mas verificações maiores levam mais tempo. Durante a prévia pública, as varreduras têm um limite de tempo de três horas.
Cobrança e uso durante o prévia pública
Reachability analysis é gratuito durante o prévia pública. Seus scans não consomem minutos cobrados GitHub Actions.
Limitações conhecidas
Reachability analysis tem as seguintes limitações durante prévia pública:
- Suporte ao ecossistema: não há suporte para alertas fora dos ecossistemas JavaScript e TypeScript suportados.
- Repositórios grandes e monorepos: alguns repositórios podem atingir o limite de verificação de três horas ou encontrar limites de recursos, deixando os resultados indisponíveis.
Usando vereditos com a API REST
A Dependabot alerts API REST expõe veredictos para reachability analysis. Você pode recuperar veredictos por meio do repositório, da organização e dos endpoints de alerta da empresa. Consulte Pontos de extremidade da API REST para Dependabot alerts.
Próximas Etapas
Para habilitar reachability analysis para seu repositório, consulte Configurando a análise de alcançabilidade para alertas do Dependabot.