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.
The complete user guide
Every screen of the application explained step by step, with annotated screenshots and close-ups: account, stack, alerts and how to handle them, workflows, reports, NIS2 compliance, team administration and the Partner space. Open the user guide.
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, Microsoft Teams and Discord through the channel's incoming webhook URL, 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. It is included in the Team and Enterprise plans, read-only, with one exception: your CI pipeline can upload its scan reports. 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.