CVE Watch Alerts

When CVE Watch detects a newly published or updated CVE that affects your inventory, it persists an alert record and (subject to the org's notification routing) dispatches a notification.

Alert object

Field	Type	Description
`id`	string	Stable alert ID.
`cveId`	string	The CVE this alert is for.
`severity`	enum	`CRITICAL`, `HIGH`, `MEDIUM`, or `LOW`.
`cvss`	number \| null	CVSS score from the originating source.
`source`	enum	`nvd`, `ghsa`, or `cisa_kev`.
`kev`	boolean	True when CISA has flagged this CVE as exploited in the wild.
`packageName`	string	Affected package name.
`affectedImages`	array	Images in your inventory currently containing the package. Each entry contains `imageName`, `tag`, and `installedVersion`.
`fixedVersion`	string \| null	Fix version reported by the source, if available.
`status`	enum	`pending`, `notified`, `digested`, or `suppressed`.
`publishedAt`	datetime	When the source published the CVE.
`detectedAt`	datetime	When HarborGuard recorded the alert.

Status lifecycle

Status	Meaning
`pending`	Alert just created; not yet routed to channels.
`notified`	Sent to a real-time channel (Slack, PagerDuty, webhook).
`digested`	Rolled into a daily or weekly summary delivery.
`suppressed`	Filtered out before delivery — most commonly because every affected finding already has an active attestation.

The alert's severity is the canonical CVE severity from the originating source (NVD CVSS v3.1 mapping, GHSA's severity field, or KEV-implied "high or above" for KEV-only entries). The minSeverityFilter in CVE Watch settings (see CVE Watch) gates which alerts are persisted at all — anything below the threshold is dropped before reaching the alert table.

KEV-flagged CVEs always generate an alert regardless of severity, on the assumption that any CVE in the CISA catalogue is operationally critical.

Listing alerts

curl -H "Authorization: Bearer $HG_API_KEY" \
  "https://harborguard.co/api/cve-watch/alerts?severity=CRITICAL&status=pending"

Supported filters: severity, status, packageName. Standard pagination applies.

Example payload

A typical real-time alert sent to a Slack or webhook channel:

{
  "event": "cve_watch.alert",
  "alert": {
    "id": "alert_01HV2K8X7N4Y9T",
    "cveId": "CVE-2026-10042",
    "severity": "CRITICAL",
    "cvss": 9.8,
    "source": "nvd",
    "kev": true,
    "packageName": "openssl",
    "fixedVersion": "3.0.13-r0",
    "publishedAt": "2026-04-26T07:30:00Z",
    "detectedAt": "2026-04-26T07:34:12Z",
    "affectedImages": [
      { "imageName": "api-gateway", "tag": "v2.4.1", "installedVersion": "3.0.7-r0" },
      { "imageName": "auth-service", "tag": "v1.9.0", "installedVersion": "3.0.7-r0" }
    ]
  }
}

Webhook deliveries are HMAC-signed with the channel's shared secret in the X-Harborguard-Signature header.

Routing and digesting

Alerts are routed through the same notification channels you configure for compliance events. A typical pattern:

Critical + KEV alerts → PagerDuty (real time, status becomes notified).
High alerts → Slack channel for SecOps (real time, status notified).
Medium / low alerts → daily email digest (status digested after the digest is sent).

Suppression happens automatically when every affected image already has an active attestation matching the CVE+package; that alert is recorded with status: suppressed and is visible in the alerts list but generates no notification.

Alert object

Status lifecycle

Severity rules

Listing alerts

Example payload

Routing and digesting

On this page