---
type: adr
id: "0003"
status: accepted
date: 2026-08-01
supersedes: null
superseded_by: null
related: []
---

# 0003 — CVE-Meldeweg: aggregierte Alarme, eigener Security-Raum, gleicher Bot

**Status:** akzeptiert · **Datum:** 2026-08-01 · **Entscheider:** sorb

## Kontext

Der erste CVE-Alarmweg (eine Matrix-Nachricht pro CVE) flutete den Raum mit 126
Nachrichten und musste stummgeschaltet werden (gitops#51, AAR in `verfahren/aar/`).
Gleichzeitig war entschieden (CFGMON-13), Release-/Security-Meldungen von
Betriebsalarmen zu trennen.

## Entscheidung

CVE-Alarme werden **pro Scan-Ziel aggregiert** (`count by (target, target_type,
host)`, CRITICAL sofort / HIGH nach 24 h) und in den **Security-Raum**
(`!YRJvcEbVXtRlUIkNld`) geroutet; Details liegen im Grafana-CVE-Dashboard, die
Nachricht verlinkt nur dorthin. Absender bleibt der bestehende `@alerts`-Bot
(ein Bot, Trennung über Räume).

## Konsequenzen

- Raum bleibt lesbar; Einzel-CVE-Detail wandert in Dashboard/Metriken
  (`trivy_vuln_info{...}` mit CVE-ID, Severity, fixed_version, first_seen).
- Pflichtfelder je Meldung: CVE-ID, Mitigation/Fix-Version, Zeitstrahl, Ort, Typ.
- Follow-up-Idee (sorb): Grafana-Dashboard als Widget direkt im Matrix-Raum.

## Verworfene Alternativen

- Eine Nachricht pro CVE: real erlebter Flood, Raum unbrauchbar.
- Eigener Bot je Meldungsklasse: mehr Betrieb ohne Erkenntnisgewinn, Räume trennen genügt.