2026-08-11 12:00:00 +00:00
|
|
|
---
|
|
|
|
|
type: adr
|
|
|
|
|
id: "0003"
|
|
|
|
|
status: accepted
|
|
|
|
|
date: 2026-08-01
|
|
|
|
|
supersedes: null
|
|
|
|
|
superseded_by: null
|
|
|
|
|
related: []
|
|
|
|
|
---
|
|
|
|
|
|
2026-08-01 12:00:00 +00:00
|
|
|
# 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.
|
