Skip to content
AlertaVuln DocsAlertaVuln DocsAlertaVuln Docs

Prioritise alerts with reachability

Once your pipeline syncs the tech stack, one more step teaches AlertaVuln how your project actually uses those packages, so every alert gets an exploitability verdict and the ones that matter rise to the top.

That step is a single command, run from the repository root right after the sync:

Terminal window
av reach analyze --path . --project "$ALERTAVULN_PROJECT_ID"

It analyses your dependency graph and source imports locally and uploads a usage report - package names, manifest paths, and file:line import sites only. Your source never leaves the runner.

Before you start

Section titled “Before you start”

  1. Finish the tech-stack sync setup. This guide assumes you already have a pipeline running av techstack sync, with a ReadWrite ALERTAVULN_API_KEY secret and an ALERTAVULN_PROJECT_ID variable in place. Reachability builds directly on that.

  2. Confirm your plan. Reachability uploads and verdicts require a Business or Enterprise subscription. You can check under Settings -> Subscription.

  3. Declare your exposure (recommended). Under Settings, set whether the project is Internet-facing. Exposure is one of the three inputs to the score, so declaring it sharpens every verdict.

Add the analyze step

Section titled “Add the analyze step”

Chain av reach analyze immediately after the sync step, in the same job, so it runs from the same checkout with the same key.

.github/workflows/alertavuln-techstack.yml
- name: Sync tech stack
  run: av techstack sync --project "${{ vars.ALERTAVULN_PROJECT_ID }}"


- name: Analyse reachability
  run: av reach analyze --path . --project "${{ vars.ALERTAVULN_PROJECT_ID }}"

On the next run the analyzer reports how each ecosystem’s packages are used and uploads the evidence. Analysis is best-effort per ecosystem: if a toolchain is missing on the runner, those packages come back Unknown and the rest still upload.

See the badges on your alerts

Section titled “See the badges on your alerts”

Open the project’s Vulnerabilities page. Each alert now carries a verdict badge next to its status:

  • Likely exploitable - act on these first.
  • Needs review - the signals are mixed; take a look.
  • Likely not exploitable - low real-world risk here.
  • Known exploited - a distinct treatment for CISA KEV CVEs.

When verdicts are present the list sorts by priority and gains a verdict-band filter, so “show me only what is likely exploitable” is one click. Expand any alert to see the evidence: how the package is used, the exploit context (EPSS, KEV, attack vector), and your exposure.

The verdict never changes the alert’s own RED / YELLOW / GREEN tier - it prioritises, it does not hide.

Override what the machine gets wrong

Section titled “Override what the machine gets wrong”

When you know more than the analyzer - a “transitive-only” package is actually called directly, or an imported package only runs in a sandboxed build step - open the alert’s reachability panel, choose Override, mark it Not exploitable or Exploitable, and record a reason. The override wins over every later recomputation and stays until you clear it, with who set it and why kept beside the machine verdict.

See also

Section titled “See also”