Incident Alerts

Incident Alerts matches public security advisories to what you run and alerts you when one applies, including malicious package releases such as LiteLLM 1.107.0. It is on every plan. It never reads your code, repository, or dependency files and never probes your site: packages count only when you declare them.

What it watches

Everything it knows about is a stack item: a product, a version if known, and where it was seen.

Dismiss a detected item that is wrong: it stops matching and the next scan does not bring it back.

Declare your stack

In Leak Alarm, Incidents, add an item:

A stack holds 200 items, detected and declared together. Add versions: an advisory that names affected versions never matches an item without one.

Packages

Under Add a package, pick the registry (PyPI, npm, Maven, RubyGems, crates.io, Packagist, NuGet, Pub, or Hex), type the name as the registry spells it, and the exact version you run. Maven names are group:artifact.

Paste a list reads lines from requirements.txt, package.json, a Gemfile, Cargo.toml, or Maven coordinates, such as litellm==1.107.0, axios@1.7.2, "express": "4.19.2", or gem 'rails', '7.1.3'. The list is read in your browser; you review it and nothing is saved until you add it. A line without an exact version is skipped.

A package already watched is checked straight away. One nobody had declared before gets its full history within 15 minutes.

Advisory sources

Every source is checked every 15 minutes, and OSV.dev’s whole export is read again once a day. ShellOrbit only downloads from them, the OSV.dev export whole rather than by package; nothing about your account, not even a package name, is sent.

How matching works

Matching runs in ShellOrbit’s own AWS account, when an advisory changes and when your stack changes. An advisory matches:

• a version range: the version falls between the first affected and the fixed version, compared part by part as numbers, with pre-releases such as 1.2.0rc1 or 1.2.0-beta.1 before their release;
• an exact release: the version is one the advisory lists, as OSV.dev does for malicious releases;
• a release line: the version is on an ended line, so 8.1.34 is on 8.1;
• a product: you use it at any version, as in a vendor breach;
• a certificate: your site’s chain holds a key, or an issuer and serial, the advisory names.

Expect an alert within minutes of an advisory reaching a public feed; feeds can trail the first news by hours. When two advisories are the same incident (one lists the other’s id), each stack item gets one of them.

Alerts and resolving

Each match is a finding with the source Incident: the evidence, the fix, and any deadline. Matches never count toward your monthly events.

A match resolves on its own when its evidence goes: a newer runtime is reported, a scan sees the new certificate or no version, you remove or dismiss the item, or the advisory is withdrawn.

Dashboard and API

Leak Alarm, Incidents shows what affects you, every advisory from the last 90 days marked Affected, Not affected, or Not enough data, and your stack. Package advisories appear only where they affect you.

Reads work with any API key; writes need read and write. MCP agents use list_incidents, get_incident, and list_stack.

Limits

ShellOrbit alerts only for what it can see: items it detected or you declared, with a version where the advisory names versions. It does not catch every incident.

• No warning for flaws or breaches not yet made public.
• Sees only your verified domains, SDK projects, findings, and declared stack.
• Checks only the packages you declare, never your code or lockfiles; a dependency scanner covers every transitive package.
• Tells you the fix; does not apply it. Not a security operations centre.