> ## Documentation Index
> Fetch the complete documentation index at: https://zeropath.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Blast Radius

> Quais call sites no seu código um upgrade de dependência afeta, classificados por risco

Quando o ZeroPath propõe um upgrade de dependência, o blast radius mostra quais call sites na sua base de código a mudança provavelmente afeta e o quão arriscado é cada um.

<h2 id="what-you-get">
  O que você recebe
</h2>

Para cada patch que sugere um bump de versão, o ZeroPath:

* Localiza os call sites no seu repositório que usam o pacote
* Classifica cada um como **safe**, **needs-review** ou **breaking**
* Exibe primeiro os sites mais arriscados na visualização do patch

A classificação é pré-computada e exibida na visualização do patch, com os call sites mais arriscados listados primeiro.

<h2 id="reading-the-labels">
  Interpretando os rótulos
</h2>

<AccordionGroup>
  <Accordion title="safe">
    O ZeroPath não encontrou evidência de que o upgrade mude como esta chamada é resolvida — o símbolo é usado da mesma forma e sua assinatura não muda entre as versões. Note que mudanças apenas de comportamento (mesma assinatura, semântica de runtime diferente) não são detectáveis pela inspeção de assinaturas e ainda podem ser rotuladas como safe.
  </Accordion>

  <Accordion title="needs-review">
    O upgrade pode afetar esta chamada, mas o ZeroPath não conseguiu confirmar em nenhum dos sentidos. Gatilhos comuns: o símbolo mudou de arquivo, o arquivo relevante é grande, ou a assinatura é genérica o bastante para que a inspeção direta seja inconclusiva. Cada rótulo needs-review vem com uma breve razão explicando o que não pôde ser confirmado.
  </Accordion>

  <Accordion title="breaking">
    Evidência forte de que esta chamada provavelmente quebrará na nova versão — por exemplo, o ZeroPath encontrou o símbolo removido, ou sua nova assinatura é incompatível com os argumentos usados aqui. Este é um sinal de compatibilidade de código, não uma avaliação de segurança. É exibido primeiro na visualização do patch para que os revisores possam tratá-lo de imediato.
  </Accordion>
</AccordionGroup>

O ZeroPath adota `needs-review` como padrão quando a evidência é ambígua, favorecendo a inspeção em vez de uma mudança não percebida.

<h2 id="supported-package-managers">
  Gerenciadores de pacotes suportados
</h2>

<Columns cols={3}>
  <Card title="npm" icon="js" iconType="brands" />

  <Card title="PyPI" icon="python" iconType="brands" />

  <Card title="Go modules" icon="golang" iconType="brands" />

  <Card title="Maven Central" icon="java" iconType="brands" />

  <Card title="crates.io (Cargo)" icon="rust" iconType="brands" />

  <Card title="RubyGems" icon="https://mintcdn.com/zeropath/3LQWG-DWQmf_zR2q/icons/ruby.svg?fit=max&auto=format&n=3LQWG-DWQmf_zR2q&q=85&s=e98ed481966bcbb1508f8d69e680b60e" width="128" height="128" data-path="icons/ruby.svg" />

  <Card title="Packagist / Composer" icon="php" iconType="brands" />
</Columns>

O blast radius roda automaticamente sempre que um patch gerado atualiza uma dependência em um desses ecossistemas — nenhuma configuração é necessária. Upgrades em outros ecossistemas de SCA suportados ainda geram patches, apenas sem o relatório de call sites. Para Maven, é necessário um JAR de sources publicado.

<h2 id="what-to-keep-in-mind">
  O que ter em mente
</h2>

O blast radius funciona examinando o código-fonte do pacote entre duas versões e comparando-o com seus call sites. Para a maioria dos upgrades isso é suficiente para agir diretamente. Alguns padrões são mais difíceis de detectar por inspeção de código-fonte — conhecê-los ajuda a interpretar o relatório:

* **Imports com alias** — a descoberta de call sites pesquisa pelo nome do pacote, então usos alcançados apenas por meio de um binding local renomeado podem ser subcontados.
* **Dispatch dinâmico** — reflection em runtime (`getattr` em Python, reflection em Java, dispatch baseado em interface/`reflect` em Go), exports gerados ou outros padrões de acesso indireto não são visíveis à detecção estática de call sites.
* **Mudanças apenas de comportamento** — uma função com a mesma assinatura em ambas as versões mas semântica de runtime diferente (por exemplo, um validador de entrada mais estrito, um default diferente) não será marcada como breaking apenas pela inspeção de assinaturas.
* **Re-exports através de pacotes aninhados** — call sites que atingem um símbolo re-exportado podem mapear, na nova versão, para um arquivo diferente do que o blast radius examinou diretamente.
* **Divergência de versão** — o blast radius analisa exatamente as versões de origem/destino do upgrade proposto. Se seu ambiente acabar instalando uma versão diferente (faixas de versão, restrições transitivas), o relatório pode não refletir o que você de fato distribui.

<Info>
  O blast radius é uma análise derivada de IA. Para upgrades de alto risco — pacotes sensíveis à segurança, caminhos críticos de produção — combine a saída do blast radius com seu fluxo de revisão padrão.
</Info>

<h2 id="where-blast-radius-appears">
  Onde o blast radius aparece
</h2>

A saída do blast radius fica anexada ao **patch** que a gerou. Quando um PR de [auto-remediação](/pt/sca/remediation) atualiza uma dependência, a visualização do patch mostra os call sites afetados agrupados por nível de risco, com uma breve razão para cada um. Os revisores podem abrir cada arquivo diretamente do relatório para inspecionar o call site em contexto.

Se o blast radius não puder ser concluído (ecossistema não suportado, o código-fonte não pôde ser obtido, ou a análise não terminou a tempo), o patch ainda é gerado normalmente; o blast radius é contexto adicional, não um gate para a criação do patch.