> ## 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

> Which call sites in your code a dependency upgrade affects, classified by risk

When ZeroPath proposes a dependency upgrade, blast radius shows you which call sites in your codebase the change is likely to affect and how risky each one is.

## What You Get

For every patch that suggests a version bump, ZeroPath:

* Locates the call sites in your repository that use the package
* Classifies each one as **safe**, **needs-review**, or **breaking**
* Surfaces the riskiest sites first in the patch view

The classification is precomputed and shown in the patch view, with the riskiest call sites listed first.

## Reading the Labels

<AccordionGroup>
  <Accordion title="safe">
    ZeroPath found no evidence the upgrade changes how this call resolves — the symbol is used the same way and its signature is unchanged across versions. Note that behavior-only changes (same signature, different runtime semantics) aren't detectable from signature inspection and may still be labelled safe.
  </Accordion>

  <Accordion title="needs-review">
    The upgrade might affect this call, but ZeroPath could not confirm one way or the other. Common triggers: the symbol moved between files, the relevant file is large, or the signature is generic enough that direct inspection is inconclusive. Each needs-review label comes with a short reason explaining what couldn't be confirmed.
  </Accordion>

  <Accordion title="breaking">
    Strong evidence this call is likely to break in the new version — for example, ZeroPath found the symbol removed, or its new signature incompatible with the arguments here. This is a code-compatibility signal, not a security assessment. Surfaced first in the patch view so reviewers can address it up front.
  </Accordion>
</AccordionGroup>

ZeroPath defaults to `needs-review` when evidence is ambiguous, favoring inspection over a missed change.

## Supported Package Managers

<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>

Blast radius runs automatically whenever a generated patch upgrades a dependency in one of these ecosystems — no configuration required. Upgrades in other supported SCA ecosystems still generate patches, just without a call-site report. For Maven, a published sources JAR is required.

## What to Keep in Mind

Blast radius works by examining the package source between two versions and matching it against your call sites. For most upgrades this is enough to act on directly. A handful of patterns are harder to detect from source inspection — knowing them helps you interpret the report:

* **Aliased imports** — call-site discovery searches for the package name, so usages reached only through a renamed local binding can be undercounted.
* **Dynamic dispatch** — runtime reflection (`getattr` in Python, reflection in Java, interface/`reflect`-based dispatch in Go), generated exports, or other indirect access patterns are not visible to static call-site detection.
* **Behavior-only changes** — a function with the same signature in both versions but different runtime semantics (e.g. a stricter input validator, a different default) will not be flagged as breaking from signature inspection alone.
* **Re-exports through nested packages** — call sites that hit a re-exported symbol may map to a different file in the new version than blast radius examined directly.
* **Version mismatch** — blast radius analyzes the exact from/to versions in the proposed upgrade. If your environment ultimately installs a different version (version ranges, transitive constraints), the report may not reflect what you actually ship.

<Info>
  Blast radius is AI-derived analysis. For high-risk upgrades — security-sensitive packages, production-critical paths — combine the blast radius output with your standard review workflow.
</Info>

## Where Blast Radius Appears

Blast radius output is attached to the **patch** that generated it. When an [auto-remediation](/sca/remediation) PR upgrades a dependency, the patch view shows the affected call sites grouped by risk level, with a short reason for each one. Reviewers can open each file directly from the report to inspect the call site in context.

If blast radius cannot complete (unsupported ecosystem, the source could not be fetched, or the analysis could not complete in time), the patch is still generated normally; blast radius is additive context, not a gate on patch creation.