Hi, in diesem Beitrag möchte ich euch ein Projekt vorstellen, an dem ich gerade arbeite. Inspiriert ist es von meinem RHEL CVE Monitor für arme Admins. Doch bevor es losgeht, beginne ich mit einem Disclaimer und einem Transparenzhinweis. Anschließend erläutere ich die Probleme, die ich mit diesem Projekt lösen möchte und gebe ein Beispiel wie man es nutzt.

Disclaimer: Es handelt sich hierbei um ein Community-Projekt, welches in keinster Weise von Red Hat stammt bzw. unterstützt wird. Es nutzt ausschließlich öffentlich verfügbare APIs, die ohne Authentifizierung genutzt werden können.

Transparenzhinweis: Das Projekt ist unter Nutzung eines KI-Coding-Assistenten entstanden.

Wofür ist das gut?

Ich führe mit meinen Kunden regelmäßig Videokonferenzen durch, um sie über Neuigkeiten zu informieren und ihre Sorgen, Nöte und Anträge aufzunehmen. Da ich ihre Red Hat-Subskriptionen kenne, möchte ich sie darüber informieren, welche Red Hat Errata seit unserem letzten Termin veröffentlicht wurden. Die Scripts aus diesem Projekt helfen mir dabei, diese Informationen effizient zusammenzustellen und in die Agenda einzufügen.

Aktuell bieten die Red Hat Errata Notifications noch keine Möglichkeit die Errata nach Produkt zu filtern. Mein Errata-Monitor bietet diese Funktionalität in Form von Filtern. Im Modus monitor speichert er auch den Status der letzten Ausführung, um bei erneuter Ausführung nur die Änderungen zum vorherigen Lauf auszugeben.

Das Projekt eignet sich damit sowohl für Ad-hoc-Abfragen, als auch für einen Monitoring-Modus, wo das Skript zeitgesteuert ausgeführt wird und neue Errata ausgibt bzw. diese Informationen per E-Mail versendet.

Wie nutzt man das?

Bitte schaut für eine ausführliche Beschreibung in das README des Projekts unter URL: https://github.com/Tronde/rh_errata_monitor. Oder nutzt die Hilfe eines der Scripte:

$ python3 rh_errata_monitor.py --help
usage: rh_errata_monitor.py [-h] [--filters FILTERS] [--state-file STATE_FILE] [--initial-days INITIAL_DAYS] [--format {json,csv,md}] [--output OUTPUT] [--exit-code]
                            [--dry-run] [--verbose]
                            {monitor,list-products,search} ...

Monitor Red Hat Errata Search API for new errata.

positional arguments:
  {monitor,list-products,search}
    monitor             Check for new errata per filter (default)
    list-products       List available product names from the API
    search              One-off stateless errata search

options:
  -h, --help            show this help message and exit
  --filters FILTERS     Path to INI filter config file (default: filters.conf)
  --state-file STATE_FILE
                        Path to JSON state file (default: .errata_state.json)
  --initial-days INITIAL_DAYS
                        On first run (no state), look back this many days (default: 30)
  --format {json,csv,md}
                        Output format (default: md)
  --output OUTPUT       Write report to file in addition to stdout
  --exit-code           Exit with code 2 when new errata are found
  --dry-run             Show queries without hitting the API
  --verbose, -v         Enable debug logging

examples:
  rh_errata_monitor.py monitor
  rh_errata_monitor.py list-products
  rh_errata_monitor.py list-products --search satellite
  rh_errata_monitor.py search --product "Red Hat Satellite" --after 2024-01-01
  rh_errata_monitor.py search --synopsis '"Ansible Automation Platform" "Setup Bundle"'
  rh_errata_monitor.py monitor --format json --output /tmp/errata.json

Die folgenden beiden Codeblöcke zeigen ein kurzes Beispiel für eine Filterdatei und einen Aufruf, den ich benutze, um eine Markdown-Ausgabe für meine Agenda zu generieren.

$ cat filter.conf 
# Red Hat Errata Monitor -- Filter Configuration
#
# Each [section] defines a named filter that the monitor checks on every run.
# Available keys:
#
#   product  = Exact product name as listed by 'list-products' command
#              Maps to: fq=portal_product_names:("...")
#
#   synopsis = Free-text search terms matched against errata synopsis/content
#              Use quotes for exact phrases: "Satellite 6" "release"
#              Maps to: q=...
#
# Both keys are optional.  If both are set, results must match BOTH (AND logic).
# If neither is set, all errata are returned (not recommended).
#
# Run 'list-products' to discover valid product names:
#   python3 rh_errata_monitor.py list-products
#   python3 rh_errata_monitor.py list-products --search satellite

# -- Red Hat Satellite -------------------------------------------------------

[satellite-releases]
# All errata for the "Red Hat Satellite" product that mention "Satellite 6"
product = Red Hat Satellite
synopsis = Satellite 6

[satellite-capsule]
product = Red Hat Satellite Capsule

# -- Red Hat Enterprise Linux ------------------------------------------------
[RHEL]
product = Red Hat Enterprise Linux for x86_64

Ich möchte also Errata für den Red Hat Satellite, Capsules und RHEL abrufen, was wie folgt aussehen kann (Ausgabe gekürzt):

$ python3 rh_errata_monitor.py search --filters filter.conf --after 2026-09-24
### satellite-releases (0 errata since 2026-09-24)

  - none

### satellite-capsule (0 errata since 2026-09-24)

  - none

### RHEL (50 errata since 2026-09-24)

  - [RHBA-2026:73791 - New Application Stream container images](https://access.redhat.com/errata/RHBA-2026:73791) - None
  - [RHSA-2026:73766 - Important: pki-core security update](https://access.redhat.com/errata/RHSA-2026:73766) - Important
  - [RHSA-2026:73765 - Important: dogtag-pki security update](https://access.redhat.com/errata/RHSA-2026:73765) - Important
  - [RHBA-2026:73746 - New Application Stream container images](https://access.redhat.com/errata/RHBA-2026:73746) - None
  - [RHEA-2026:73547 - multiple NVIDIA kernel module packages bug fix and enhancement update](https://access.redhat.com/errata/RHEA-2026:73547) - None
  - [RHEA-2026:73546 - multiple NVIDIA kernel module packages bug fix and enhancement update](https://access.redhat.com/errata/RHEA-2026:73546) - None
  - [RHSA-2026:73512 - Moderate: gawk security update](https://access.redhat.com/errata/RHSA-2026:73512) - Moderate
  - <AUSGABE GEKÜRZT>

**Total: 50 errata since 2026-09-24 across 1 filter**

Ich lasse mir hier die Errata ausgeben, die nach dem 24.09.2026 veröffentlicht wurden. Während es für den Satellite und dessen Capsules nichts neues gibt, sind 50 Errata für RHEL veröffentlicht worden. Ich habe die Ausgabe hier im Blog gekürzt, das Format ist jedoch ersichtlich.

Diese Liste kann ich nun per Copy&Paste in das Tool übernehmen, mit dem ich die Agenda für meinen TAM-Call generiere.

Wie stabil ist das Projekt?

Bei dem was ihr aktuell auf GitHub findet, handelt es sich um ein Pre-Release. Ich nutze es seit einigen Tagen und bisher hat es meinen Rechner nicht gestört.

Für die Filter nutze ich die Produktnamen aus der API und Filter die Strings aus dem Abschnitt Synopsis. Gerade letzteres ist Fehlerbehaftet und kann zu ungenauen bzw. fehlerhaften Ausgaben führen. Falls euch Fehler auffallen, freue ich mich, wenn ihr diese meldet.

Falls ihr dieses Projekt nützlich findet, lasst es mich gerne wissen. Dazu könnt ihr gern einen Kommentar unter diesem Beitrag hinterlassen oder einen Stern auf GitHub vergeben. Die CONTRIBUTING.md enthält Informationen, wie ihr darüber hinaus zum Projekt beitragen könnt.

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. kernel, openssl, samba, 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.

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:

• GitHub: https://github.com/Tronde/query_out_of_support_appstreams
• Codeberg.org: https://codeberg.org/Tronde/query_out_of_support_appstreams

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.

Mit Open Responses gibt es nun erstmals einen Vorschlag für einen Open-Source-Standard für ein herstellerunabhängiges JSON-API, über das Clients mit LLMs kommunizieren können.