Normale Ansicht

RHEL CVE Monitor für arme Admins

07. September 2026 um 05:00

User Story: Als RHEL-Systemadministrator:in möchte ich für einige ausgewählte Kompontenten, wie z.B. kernel, openssl oder samba, über neue CVE für diese Komponenten informiert werden. Leider steht mir dazu keine Schwachstellenmanagementlösung zur Verfügung. Einen Red Hat Satellite Server habe ich nicht und den Vulnerability Service in der Hybrid Cloud Console kann bzw. darf ich nicht nutzen.

Transparenzhinweis: Ich arbeite als TAM für Red Hat. Die im Folgenden vorgestellte Anwendung habe ich als Open-Source-Projekt unter MIT-Lizenz veröffentlicht. Es steht in keiner offiziellen Verbindung zu Red Hat.

RHEL CVE Monitor ist ein Python-Tool, das die Red Hat Security Data API regelmäßig abfragt und neue Sicherheitslücken (CVEs) für eine konfigurierbare Liste von RHEL-Paketen meldet.

Die zu überwachenden Pakete werden in packages.txt festgelegt (z. B. kernelopensslsamba, rear). Beim ersten Lauf werden CVEs der letzten 30 Tage ausgegeben; danach zeigt das Tool nur noch neue Einträge seit dem letzten erfolgreichen Durchlauf. Bereits gemeldete CVEs werden in einer lokalen Zustandsdatei (.cve_monitor_state.json) gespeichert, damit nichts doppelt erscheint.

Die Ausgabe kann als Text, JSON oder CSV erfolgen und eignet sich für manuelle Prüfungen, Cron-Jobs oder systemd-Timer. Mit --exit-code lässt sich das Tool auch in CI/CD-Pipelines einbinden, die bei neuen CVEs alarmieren sollen.

Wie benutzt man das?

Der folgende Code-Block zeigt die CVE im RHEL-kernel der letzten 5 Tage:

[host.example.com rhel_cve_monitor]$ python3 rhel_cve_monitor.py --initial-days 4
=== kernel (1 new CVE) ===
  CVE-2026-80725       important    2026-08-29  https://access.redhat.com/security/cve/CVE-2026-80725

Total: 1 new CVE across 1 package

Die Ausgabe ist bewusst spartanisch gehalten. Man erhält lediglich die CVE-Nummer, die Severity, das Erscheinungsdatum und die URL zur Red Hat CVE Datenbank, wo man weitere Informationen zur Schwachstelle findet.

Verfügbare CLI-Optionen findet man in der Hilfe:

[host.example.com rhel_cve_monitor]$ python3 rhel_cve_monitor.py --help
usage: rhel_cve_monitor.py [-h] [--packages PACKAGES]
                           [--state-file STATE_FILE]
                           [--initial-days INITIAL_DAYS] [--output OUTPUT]
                           [--exit-code] [--verbose] [--dry-run]
                           [--format {text,json,csv}]
                           [--reset-packages PACKAGE [PACKAGE ...]]
                           [--reset-after YYYY-MM-DD]

Monitor Red Hat Security Data API for new CVEs affecting given RHEL packages.

options:
  -h, --help            show this help message and exit
  --packages PACKAGES   Path to file with one package name per line (default:
                        packages.txt)
  --state-file STATE_FILE
                        Path to state file tracking last run time (default:
                        .cve_monitor_state.json)
  --initial-days INITIAL_DAYS
                        On first run (no state file), look back this many days
                        (default: 30)
  --output OUTPUT       Optional file path to write the report to (in addition
                        to stdout)
  --exit-code           Exit with code 2 when new CVEs are found (useful for
                        CI/automation)
  --verbose, -v         Enable verbose logging
  --dry-run             Preview what would be queried without hitting the API
  --format {text,json,csv}
                        Output format: text (default), json, or csv
  --reset-packages PACKAGE [PACKAGE ...]
                        Clear seen-CVE state for these packages (use 'all' for
                        every package) and exit
  --reset-after YYYY-MM-DD
                        When resetting, also set last_run to this date so next
                        run queries from here

Mehr kann die kleine Anwendung nicht.

Und wo gibt es das?

Unter der URL: https://github.com/Tronde/rhel_cve_monitor

Das englischsprachige README enthält weitere Beispiele und Hinweise zur Nutzung.

Falls ihr diese kleine Anwendung nützlich findet, freue ich mich, wenn ihr mir hier im Blog einen Kommentar hinterlasst und eure Erfahrung weiterverbreitet. Wenn ihr Fehler findet oder Verbesserungsvorschläge habt, meldet diese bitte im GitHub-Issue-Tracker des Projekts.

Proof of Concept: Abfrage der nicht mehr unterstützten AppStreams über die Red Hat Lifecycle API

18. Mai 2026 um 05:00

Im Folgenden möchte ich euch einen Proof of Concept (PoC) vorstellen, der aus einem Gespräch mit einem meiner Kunden entstanden ist.

AppStreams != AppStream

Es geht hier nicht um den offenen Standard AppStream, sondern um die in RHEL 8 und RHEL 9 genutzten AppStreams. Letztere sind ein inzwischen abgekündigtes Konzept zur Bereitstellung verschiedener Paketversionen mit einem definierten Unterstützungszeitraum innerhalb eines Major-Release. Für weitere Informationen hierzu siehe den englischsprachigen Artikel: Red Hat Enterprise Linux Application Streams Life Cycle.

Das Risiko

  • Pakete aus AppStreams werden auf Servern installiert.
  • Die Unterstützung dieser AppStreams endet und niemand merkt es.
  • Es wird Software in der Infrastruktur betrieben, die nie wieder ein Update erhält.

User Story

Im IT-Betrieb möchten wir die Lebenszyklusinformationen der AppStreams über eine API abfragen, deren Unterstützungszeitraum abgelaufen ist. Diese Liste möchten wir mit den auf unseren Servern installierten AppStreams abgleichen, um die Installationen zu identifizieren, die aktualisiert oder migriert werden müssen.

Lösungsansatz

Die gewünschten Informationen können über die Red Hat Lightspeed for RHEL Planning API abgerufen werden.

Wer seine Systeme an der Hybrid Cloud Console registriert hat, kann mit den abgelaufenen AppStreams gleichzeitig eine Liste der Systeme abrufen, auf denen diese installiert sind. Wer seine Systeme dort nicht registriert hat, kann die abgelaufenen AppStreams abfragen und die Informationen mit eigenen Mitteln weiterverarbeiten, um einen Abgleich durchzuführen.

Zur Demonstration habe ich einen Proof of Concept erstellt:

Die Repos beinhalten eine README.md mit der Dokumentation des Bash- und Python-Skripts sowie Links zu weiterführenden Informationen.

Falls euch dieses Beispiel gefällt, gebt ihm doch gerne einen Stern im jeweiligen Repository oder hinterlasst hier einen Kommentar.

Was gibt es dazu sonst noch wissenswertes?

Die in RHEL Lightspeed enthaltene Roadmap/Lifecycle-Anwendung verhält sich für einige User unerwartet. Als installiert werden AppStreams angezeigt, die auf einem System aktiviert sind. Dies ist auch der Fall, wenn ein Module Stream lediglich aktiviert ist, aber kein RPM-Paket aus diesem Stream tatsächlich installiert wurde. Dies kann zu einer Fehlinterpretation führen.

Red Hat liegt ein Feature Request vor, um dieses Verhalten zu ändern und nur AppStreams aufzuführen, deren RPM-Pakete tatsächlich installiert wurden. Mir liegen keine Informationen vor, ob und wann Red Hat dies umsetzen wird.

Des Weiteren liegt Red Hat die Anfrage vor, die Lightspeed Planning App als on-premises App im Satellite bereitzustellen. Auch hier kann ich leider nicht vorhersagen, ob und wann dies umgesetzt wird.

Falls ihr euch dafür interessiert, nehmt bitte Kontakt zum Red Hatter eures Vertrauens auf.

❌