Integrations: SIEM export, alerting and ticketing

Findings are most useful where your teams already work. Everything leaves RelixQ through two paths, and which one you want depends on whether you are feeding a system or a person:

• Signal export streams three signal types — metrics, scan change events, and OCSF-normalized security findings — to your observability and SIEM destinations. Configured under org → Integrations.
• Alerting and ticketing turns findings and posture regressions into tickets, deduplicated incidents, and chat or email notifications, and syncs external ticket status back. Configured under org → Alerts and the notification API.

Route: /orgs/<slug>/integrations. A rollup strip — Connected, Enabled, Paused, 24h delivery success — sits above three views: Catalog, Connected, and Delivery log.

All ten have real sink implementations; "API only" means the type is absent from the web catalog grid today, so you create those connections with POST /api/connections instead. Security findings are exported in OCSF normalization, so SIEM correlation rules survive a destination change.

Pick a tile in the Catalog and the inline connect form opens: a connection name, the provider non-secret configuration fields, and where required a secret.

• Configuration card — the provider, every non-secret config value, the connection id, and a credential status chip (stored / none).
• Streams and state — independent toggles for Metrics, Change events, and Security events, plus a whole-connection enabled/paused switch. Pausing keeps the config but stops all deliveries.
• Test — a side-effect-free connectivity probe that reaches the sink with your stored credentials and reports success or the failure detail. It sends no signals.
• Recent deliveries — the last delivery attempts to this destination only.

The org-wide delivery log lists recent attempts across all destinations — timestamp, connection, signal kind, status, HTTP status, latency, signal count, and the error text on failures.

Semantics are bounded and explicit. A failing delivery is retried a small, fixed number of times with a back-off, and each attempt is its own row so you can see what happened. Once the retries are exhausted the delivery is explicitly dead-lettered — recorded and given up on, never retried silently forever. One destination failing never blocks delivery to the others.

Beyond org-wide connections, the API supports per-project export routes, each binding a project to a connection with a minimum severity and a stream subset. There is no web surface for routes today.

Route: /orgs/<slug>/alerts. The Alerts section connects on-call and ITSM tools and routes crypto-risk regressions to them as deduplicated incidents.

A rule has a name, an optional project scope or org-wide, a target provider and connection, an incident severity, an enabled flag, and one of two kinds:

• Per-finding rules fire when a finding event matches the predicate: minimum severity, exposure, environment, "new findings only", and a minimum HNDL relevance.
• Posture-threshold rules watch a metric after each scan and fire when it crosses the line: crypto-agility score, RelixQ Score, max blast radius, HNDL-exposed findings, and open critical findings.

Incidents are trigger-once / resolve-once. Each rule renders a dedup key, so a threshold that stays breached across ten scans holds one open incident rather than paging ten times.

The resolve round-trip is automatic in both directions: when a threshold metric returns to the safe side on a later scan, the open incident for that key resolves; and when a finding is resolved upstream — fixed, accepted, or marked false positive — every open incident that referenced it is auto-resolved.

The same service owns finding tickets, notification routing, and chat actions. This surface is API-first: apart from the Alerts pages, there is no web UI for ticketing integrations or notification rules yet.

Ticket creation is idempotent — one external ticket per finding — so replayed events and overlapping rules never file duplicates. Dispatch retries are bounded, with a rate limiter and an optional digest mode that batches low-urgency notifications.

Each notification routing rule has a match block (severity, exposure, environment, algorithm, project ids — empty means "any"), an ordered list of actions, a digest flag, and a priority. For config-as-code, PUT /notifications/rules/yaml bulk-upserts an entire rule set from a YAML document in one call.

Slack notifications carry action buttons. The interactivity endpoint verifies the Slack signing secret with a 5-minute replay window before any state change, and handles Acknowledge, Request exception, and Mark false positive.

Webhooks for tickets the service did not create are logged and ignored, so it is safe to point an existing shared webhook at these endpoints.

Connected a destination but no events are arriving. Check in this order:

1. 1Have any scans completed since you connected? Export carries real scan output only. A freshly connected destination with no completed scans has nothing to deliver, and the empty delivery log is honest rather than broken.
2. 2Have any findings actually fired? A freshly connected org with no completed scans has nothing to deliver.
3. 3Are the right streams enabled? A connection with Security events toggled off will never carry findings.
4. 4Is the connection paused? Paused connections keep their config and history but deliver nothing.

Deliveries show `failed` then `dead-letter`. failed rows are individual retriable attempts; dead-letter means the retry budget was exhausted. Dead-lettered batches are not replayed automatically — fix the destination (401/403 means credentials, 429 means quota) and new deliveries resume with the next event.

Alert did not fire. Check the rule is enabled, its project scope matches, the finding meets the predicate, and — for threshold rules — that a scan has completed since the metric crossed the line. If it fired once and never again, that is dedup working as designed.