Your first alert in three steps.
Allow ten minutes in all, two of them to declare your stack. This page describes what you do; the API reference lives in the technical documentation.
In one sentence
Declare what you run, set the noise threshold, connect a channel: from then on, you only receive the vulnerabilities that affect your components.
1. Declare your stack
Three ways, your choice, and they can be combined:
- Import an SBOM (Software Bill of Materials, the component inventory produced by your build pipeline) in CycloneDX or SPDX format. It is the most reliable route: the versions in it are exact.
- Enter manually the vendor, product and version. Allow two minutes for about ten components.
- Detect from a public URL: we identify the visible technologies, you confirm or correct.
Each line is translated into a CPE identifier (Common Platform Enumeration), the naming scheme that identifies a product and its version in the CVE system. This identifier is what makes automatic matching possible, and it is also why an approximate version produces approximate alerts.
Declaring “PHP” without its version
Declaring “PHP” with no version. You will then receive every CVE for every branch, including the ones you don't run: exactly the noise you were trying to remove. Declare php 8.1.28, not php.
2. Set the noise threshold
By default, you receive everything that affects your stack. Most teams dial it down in two steps: a severity threshold (often CVSS ≥ 7) and an exception that lets everything through if the CVE is in CISA's KEV catalog, that is, if its exploitation has been observed in the wild.
Order matters. CVSS measures potential damage; EPSS estimates the probability of exploitation within thirty days; KEV confirms it. To understand what you are tuning, read what CVSS really measures and what the KEV catalog requires.
3. Connect a channel
Slack and Microsoft Teams via OAuth, DKIM-signed email, HMAC-signed HTTP webhook. A tip from experience: send critical alerts to Slack and leave the rest in the daily brief. If everything arrives in real time, the team mutes notifications within a week, and you have lost the benefit.
Next: automate
A workflow starts from a trigger (new CVE on your stack, proof of concept published, KEV listing, end of support approaching), filters it through conditions, then runs actions. You can dry-run it on a real CVE before enabling it.
On the machine side, REST API v1 exposes the same objects: alerts, CVE database, inventory, cases, statistics. The Plus plan opens read access (GET), the Pro plan read and write. The most common use case is a CI job that blocks deployment as long as a critical CVE remains unhandled.
Full API reference and curl, Python, JavaScript and GitHub Actions examples.
What this page does not cover
It covers setup, not day-to-day operation. We have not yet published a guide on keeping a vulnerability register or on responding to an audit. If that is what you are looking for, tell us: we write first what people ask us for.