Skip to content
Fleet CRA

Vulnerability Monitoring — Overview

A product registered in FLEET has a stored SBOM. Vulnerability monitoring re-checks that SBOM against advisory feeds on a schedule, keeps a durable, time-tracked record of findings, triages them with VEX, and alerts on anything new — auto-drafting a CRA Art.14 ENISA notification when a match is actively exploited.

It builds on FLEET’s existing OSV enrichment (src/vuln_enrich.rs) but adds the continuous dimension: a clean SBOM today can become vulnerable tomorrow as new advisories land.

The loop

Section titled “The loop”
 stored SBOM (PURLs)
        │  (on a schedule, or on demand)
        ▼
   match + overlay ──▶ OSV.dev (CVE+GHSA)  ·  CISA KEV (exploited)
        │                EUVD (euvd id)    ·  GHSA (severity)
        ▼
   vulnerability_finding  ◀── VEX (OpenVEX / CycloneDX) triage
        │  diff vs last pass → new / newly-exploited / resolved
        ▼
   alert (notification channels)  +  exploited → draft CRA Art.14 ENISA notice

Sources

Section titled “Sources”
Source Role Notes
OSV.dev matcher PURL → CVE/GHSA/ecosystem advisories
CISA KEV overlay flags actively exploited — the CRA 24h trigger
EUVD overlay adds the EUVD-… id (CRA/ENISA alignment)
GHSA overlay severity/CVSS enrichment (needs a GitHub token)

Each source is individually toggleable.

Findings & history

Section titled “Findings & history”

Findings are stored per (product, component, vuln) with first_seen, last_seen, and an open/resolved state. Each pass yields a delta: what’s new, what became exploited, and what resolved (no longer present). Operator VEX triage is preserved across passes — a source re-scan never clobbers it. See VEX Triage.

Scheduling & configuration

Section titled “Scheduling & configuration”

Two triggers, both running the same pass:

  • In-process interval — enabled via environment, runs every N hours.
  • On demand — POST /api/v1/monitor/products/{id}/run (for cron/CI/CLI).

Configuration (environment):

Variable Default Meaning
FLEET_VULN_MONITOR__ENABLED false run the in-process scheduler
FLEET_VULN_MONITOR__INTERVAL_HOURS 6 hours between passes
FLEET_VULN_MONITOR__OSV / __KEV / __EUVD true toggle sources
FLEET_VULN_MONITOR__GHSA false enable GHSA (requires token)
FLEET_VULN_MONITOR__GITHUB_TOKEN — token for GHSA (or GITHUB_TOKEN)

REST API

Section titled “REST API”

All under /api/v1/monitor, behind API-key auth with the assessment:* scopes:

Path Method Scope Purpose
/monitor/products/{id}/findings GET assessment:read List findings
/monitor/products/{id}/run POST assessment:write Run a pass now
/monitor/products/{id}/vex POST assessment:write Ingest a VEX document
/monitor/products/{id}/vex GET assessment:read Emit VEX (?format=cyclonedx)
Terminal window
# trigger a pass
curl -X POST https://your-fleet/api/v1/monitor/products/$ID/run \
  -H "Authorization: Bearer $FLEET_KEY"
# → { "data": { "new": 2, "resolved": 0, "alerts": 2, "enisa_drafts": 1 } }

Alerting & CRA Art.14 auto-draft

Section titled “Alerting & CRA Art.14 auto-draft”

Each newly-actionable finding (new or newly-exploited, not VEX-suppressed) emits a VulnerabilityDetected event to FLEET’s notification channels (Slack/email/…). When a finding is actively exploited (CISA KEV), FLEET also auto-drafts a CRA Art.14 ENISA vulnerability notification (24h early warning) pre-filled with the CVE, EUVD id, product, and manufacturer — an operator reviews it and submits via ENISA Reporting. Nothing is sent to ENISA automatically.

MCP

Section titled “MCP”

AI assistants can drive monitoring via fleet_list_vuln_findings, fleet_ingest_vex, and fleet_emit_vex — see MCP Tools.