ovhcloud-json-processor

Status: Live Source: OVHcloud Statuspage.io sub-instances at {slug}.status-ovhcloud.com/api/v2/incidents.json Type: json (commentary enricher — no primary CVEMetadata writes) Source slug: ovhcloud Schedule: Runs weekly on Thursdays at 06:00 UTC (cron(0 6 ? * THU *)).

Overview

OVHcloud publishes no PSIRT advisory feed (no CSAF, no CVRF, no RSS — cert.ovh.com redirects to a CSIRT contact page). Their public Statuspage instances, however, emit CVE-titled incident notifications for upstream CVEs affecting managed products (cPanel, Managed Kubernetes, ESXi-based dedicated servers, Public Cloud compute and storage). Six sub-statuspages — bare-metal-servers, customer-service, hosted-private-cloud, network, public-cloud, web-cloud — each expose the standard Atlassian Statuspage v2 REST endpoint at /api/v2/incidents.json.

The processor is a commentary enricher: it does not create any CVEMetadata rows. For every CVE found in an incident’s title or update bodies, it walks every existing (cveId, source) pair in CVEMetadata and inserts a CVEMetadataReferences row pointing at the incident shortlink. CVEs not already known to vdb-manager are skipped (counted as cvesUnknown) — an OVHcloud incident is too weak a signal to seed a new primary CVE row on its own.

Source

Page Structure

Each /api/v2/incidents.json page response carries:

{
  "page": { "id": "...", "name": "...", "url": "...", "updated_at": "..." },
  "incidents": [
    {
      "id": "abc123",
      "name": "cPanel - CVE-2026-41940 - Incident Notification",
      "status": "resolved",
      "shortlink": "https://stspg.io/...",
      "created_at": "...",
      "updated_at": "...",
      "resolved_at": "...",
      "incident_updates": [
        { "id": "...", "status": "resolved", "body": "..." }
      ]
    }
  ]
}

CVE identifiers appear in either incident.name (rare) or in incident_updates[*].body (common — OVHcloud often files an incident first and edits the CVE reference in afterwards).

Parsing

internal/ovhcloud/parse.go provides two helpers:

ExtractCVEs returns a non-nil empty slice when no CVE token matches so the caller can rely on len(cves) == 0 as the “skip this incident” signal.

Storage

No transaction wrapper or processor.StoreCVESourceData — references are inserted directly via per-row INSERT … ON CONFLICT DO NOTHING so re-runs are free and order-independent.

The “fan-out across all parent sources” pattern mirrors cmd/fastly-fetch-processor/main.go:loadAllSourcesForCVEs — the OVHcloud incident is a fact about the CVE itself, not about any one ingesting source’s representation, so every (cveId, source) row in CVEMetadata gets its own reference edge.

Identifier Policy

No OVH-issued identifier is minted. The composite tracker key for content-addressing is (region, incident.id); the same upstream CVE may open separate incidents on multiple sub-statuspages and each one produces its own reference row.

Incremental Strategy

Tracker-hash gating with hard-coded daily frequency:

1. Tracker freshness gate — at startup, db.GetTracker(ctx, pool.Read, "ovhcloud") is read. When now - lastProcessedAt < frequency * 1000 (default frequency = 86400 s = 1 day), the run exits via notifier.NoWork().
2. Per-incident dedup — handled at the DB layer. Every insert uses ON CONFLICT DO NOTHING over the natural key, so re-fetching the same incident on a future page-walk is a free no-op.
3. Pagination cap — --max-pages=20 (50 incidents per page × 6 regions = 6000 incident ceiling per run; far above observed throughput).

The --force flag bypasses the freshness gate.

CRIT Staging (Optional)

With --emit-crit=true, per-(cveId, parentSource) CRIT (Cloud Resource Inventory Tag) candidate envelopes are staged via critutil.StageCandidate when the incident name or body mentions an OVHcloud managed product. Keyword routing (in cmd/ovhcloud-json-processor/crit_mapper.go):

After the scan loop completes, critpublisher.DrainKeys ingests staged candidates into the cloud-resource inventory. The internal/critutil/dictionaries/extended/ovh.json dictionary must be present at load time — if either spec or extended dictionaries fail to load, --emit-crit falls back to warn-and-ignore (best-effort).

CRIT publication is disabled when CRIT_PUBLISH_DISABLED=true.

Slack Notifications

internal/notify emits the standard four lifecycle events plus per-region warnings via RecordError:

SetOvertimeCancel wires the notifier to cancel the request context when the soft deadline fires on ECS scheduled runs.

Flags

ECS Schedule

Soft deadline is applied only when EXPECTED_DURATION_MINUTES is set (ECS-only). Local backfills via just go-ovhcloud-json-backfill run to completion per the AGENTS.md backfill rule.

Architecture

Data Flow

Decision Tree

DB Schema

Key Files

Infrastructure

Future Work

• Same-CVE region dedup — when both bare-metal-servers and customer-service open separate incidents for the same upstream CVE (e.g. cPanel cross-product impact), the reference rows are intentionally kept distinct so each shortlink remains addressable. A future post-processor could collapse these into a single reference per (cveId, parentSource) with a JSON array of incident shortlinks if the CVE detail page UI starts to feel cluttered.
• ovh.json extended dictionary — required at load time when --emit-crit=true. Authoring is tracked separately from this processor; until the dictionary lands the CRIT pass is a no-op warn-only.
• Help-centre commentary — help.ovhcloud.com carries unstructured Meltdown / Spectre style write-ups that are not indexed in /api/v2/incidents.json. Out of scope for the JSON enricher.

S3 Persistence

• Archive path: ovhcloud/files/{sha256}/{filename} ✓
• Quarantine path: failed-feeds/ovhcloud-json-processor/{YYYY-MM-DD}/{reason}/{filename} ✓
• Failure reasons emitted: parse-error

Uses s3client.Uploader from internal/s3client/uploader.go. Skipped when S3_BUCKET_NAME is unset (local dev).

See the S3 Persistence Contract for the full reason taxonomy.