Security-Advisory-Feeds der Hersteller: 16 geprüfte RSS- und Atom-Adressen

Microsofts Security-Update-Feed enthielt am 19.08.2026 genau 4.912 Einträge — 3.913 verschiedene CVE-Nummern, der älteste vom 20.05.2026. Das ist ein Abo. Ein mittlerer Bestand braucht rund fünfundzwanzig davon, und die Adressen dafür muss man sich einzeln zusammensuchen. Hier stehen sie, sortiert nach dem, was du tatsächlich betreibst, und jede am selben Tag abgerufen und gezählt.

Wie diese Liste geprüft ist

Jede Adresse wurde am 19.08.2026 einmal abgerufen, und je Eintrag sind vier Angaben notiert: die Quelle mit ihrer Adresse, das Feed-Format, der Umfang des Dokuments in diesem Moment und das Prüfdatum. Was nicht mit XML geantwortet hat, steht nicht in den Tabellen.

Das Prüfdatum steht mit Absicht in jeder einzelnen Zeile — Feed-Adressen halten nicht ewig, und eine Zeile ohne Datum ist eine Behauptung ohne Haltbarkeit. Die Umfangsspalte ist ebenfalls keine Qualitätsnote. Sie sagt, wie weit ein Feed zurückreicht, und damit, wie lange dein Reader ausfallen darf, ohne dass dir etwas durchgeht.

Betriebssysteme und Browser

QuelleFormatUmfang am PrüftagGeprüft
Microsoft MSRCRSS 2.04.912 Einträge, ältester 20.05.202619.08.2026
Ubuntu (USN)RSS 2.010 Einträge, ältester 17.08.202619.08.2026
Debian (DSA)RSS 1.0 (RDF)30 Einträge, ältester 08.08.202619.08.2026
Google ChromeAtom25 Einträge, ältester 06.08.202619.08.2026

Die Ubuntu-Zeile ist die wichtigste. Zehn Einträge, und die deckten am Prüftag den 17. bis 18. August ab — knapp zwei Tage. Ein Reader, der einmal pro Woche läuft, sieht von dem, was Ubuntu veröffentlicht hat, einen Bruchteil. Bei Microsoft ist es genau umgekehrt: ein Eintrag je CVE, Revisionen mitgezählt, davon 1.233 mit einem Datum aus den vorangegangenen 31 Tagen. Wer diesen Feed ungefiltert abonniert, nimmt über tausend Meldungen im Monat mit, die meisten zu Produkten, die er nicht betreibt.

SUSE ist die Lücke in dieser Klasse. Die Sicherheitsseiten verweisen nur auf den allgemeinen SUSE-News-Feed; eine sicherheitsspezifische Adresse war am Prüftag im ausgelieferten HTML nicht zu finden.

Netzrand: Firewall, VPN, Router

QuelleFormatUmfang am PrüftagGeprüft
Fortinet PSIRTRSS 2.050 Einträge, ältester 11.03.202519.08.2026
Palo Alto NetworksRSS 2.025 Einträge, ältester 08.07.202619.08.2026
Cisco PSIRTRSS 2.050 Einträge, ältester 06.05.202619.08.2026

Fortinet nennt seine Datei ir.xmlund den Kanal „IR Advisories“, was nach Incident Response klingt. Die Kanalbeschreibung sagt, was es wirklich ist: die in Fortinet-Produkten behobenen Probleme, koordiniert vom Fortinet-PSIRT. Der Name führt in die Irre, der Inhalt nicht.

Speicher, Server und Anwendungen im Haus

QuelleFormatUmfang am PrüftagGeprüft
SynologyRSS 2.0439 Einträge, ältester 14.11.201319.08.2026
QNAPRSS 2.020 Einträge, jüngster 17.06.202619.08.2026
Proxmox (Ankündigungen)RSS 2.020 Einträge, ältester 09.04.202519.08.2026
Veeam (Knowledge Base)Atom20 Einträge, ältester 03.08.202619.08.2026
GitLabAtom204 Einträge, ältester 23.05.202319.08.2026
JenkinsRSS 2.0101 Einträge, ältester 15.01.202019.08.2026

Zwei Zeilen lohnen den zweiten Blick. Synologys Feed reicht bis November 2013 zurück — 439 Einträge, ein durchsuchbares Archiv statt eines Fensters, das man erwischen muss. QNAP hielt zwanzig Einträge, deren jüngster vom 17.06.2026 stammte, also zwei Monate vor der Prüfung. Ob zwei ruhige Monate bedeuten, dass nichts passiert ist, oder dass der Feed nicht mehr gefüllt wird, lässt sich von außen nicht entscheiden — und genau diese Mehrdeutigkeit ist der Grund, neben jede Adresse ein Prüfdatum zu schreiben.

Proxmox und Veeam haben überhaupt keinen sicherheitsspezifischen Feed: Proxmox meldet im Ankündigungs-Forum, Veeam in der Knowledge Base, beide Feeds transportieren also auch alles andere. Brauchbar, aber das Filtern wandert zu dir.

Open Source ohne Advisory-Feed

Viele Projekte veröffentlichen ihre Advisories nur auf GitHub, und GitHubs Atom-Adresse für Advisories antwortet ohne Anmeldung mit HTTP 406 — geprüft am 19.08.2026. Was für alle funktioniert, ist der Release-Feed: /releases.atom an die Repository-Adresse hängen, etwa bei nextcloud/server oder zabbix/zabbix, beide mit zehn Einträgen am Prüftag. Dabei gehört gesagt, was man bekommt: einen Release-Feed, keinen Advisory-Feed. Er meldet, dass eine Version existiert, nicht welche Lücke sie schließt. Für Mozilla und OpenSSL war im ausgelieferten HTML der jeweiligen Advisory-Seite gar keine Feed-Adresse zu finden.

Sammelquellen — zwei davon auf Deutsch

QuelleFormatUmfang am PrüftagGeprüft
CERT-Bund / BSI (deutsch)RSS 2.0250 Einträge, ältester 17.08.202619.08.2026
heise security Alerts (deutsch)Atom20 Einträge, ältester 11.08.202619.08.2026
CISA AdvisoriesRSS 2.030 Einträge, ältester 05.08.202619.08.2026

Der Feed des Warn- und Informationsdienstes von CERT-Bund ist der einzige in dieser Sammlung, der den Schweregrad schon in den Titel schreibt — die Einträge lesen sich als [NEU] [hoch] Oracle MySQL: Mehrere Schwachstellen, auf Deutsch. Er ist zugleich der lauteste: Von seinen 250 Einträgen trugen 118 das Datum des 17. und 113 das des 18. August, der Rest den Prüftag selbst. Das sind gut hundert Meldungen an einem gewöhnlichen Tag, quer über alle Hersteller.

Ein Aggregator ersetzt den Hersteller-Feed nicht. Er kommt später, er ist gröber, und er entscheidet für dich, was eine Meldung wert ist. Er ersetzt aber sehr wohl fünfzehn Feeds von Herstellern, die du nur am Rand betreibst — und genau dafür ist er der richtige Tausch.

Drei Arten, wie ein Feed-Abo stirbt

Erstens: Die Adresse ist weg. HTTP 404, dein Reader zeigt einen Fehler, du merkst es. Das ist der harmlose Fall.

Zweitens: Die Adresse antwortet, aber mit einer Webseite.Der Hersteller baut die Website um, der alte Feed-Pfad liefert jetzt die neue Advisory-Seite, und der Server antwortet mit HTTP 200. Die meisten Reader lesen das als „keine neuen Einträge“ und schweigen; das Abo sieht lebendig aus und liefert nichts. Der ältere Sicherheitspfad von Synology zeigt am 19.08.2026 genau das — 200, und HTML. Zwei Befehle trennen die Fälle, und geprüft wird der Content-Type, nicht der Statuscode:

curl -sL -o /dev/null -w '%{http_code} %{content_type}\n' \
  https://ubuntu.com/security/notices/rss.xml
200 text/xml; charset=utf-8

curl -sL -o /dev/null -w '%{http_code} %{content_type}\n' \
  https://www.synology.com/en-global/support/security/rss
200 text/html; charset=UTF-8

Such dabei nicht nach application/rss+xml im Besonderen — Ubuntu liefert text/xml, Debian application/rss+xml, GitLab application/xml. Die Regel, die trägt, lautet: Es muss xml dastehen und es darf nicht html dastehen.

Drittens: Der Feed ist in Ordnung, aber kürzer als dein Abrufabstand. Elastic veröffentlicht seine Sicherheitsankündigungen über einen Forum-Feed. Am 19.08.2026 enthielt der 25 Einträge, und alle 25 trugen dasselbe Datum, den 13.08.2026 — ein einziger Veröffentlichungstag hatte den kompletten Feed gefüllt. Solche Feeds sind ein Schaufenster, kein Archiv: Wer den Tag verpasst, findet die Einträge schlicht nicht mehr.

Deshalb ist die vierteljährliche Nachprüfung keine Buchhaltung, sondern der eigentliche Betrieb: einmal im Quartal die beiden Befehle oben gegen jede abonnierte Adresse laufen lassen und den jüngsten Zeitstempel gegen die eigene Erinnerung halten.

Die Rechnung: rund fünfundzwanzig Abos

Zähl zusammen, was ein recht gewöhnlicher Bestand braucht, je Klasse eine Zeile:

  • Betriebssystem, eine Linux-Distribution, ein Browser — 3
  • Firewall, VPN-Gateway, Switch oder Router — 2 bis 3
  • Virtualisierung und Backup — 2
  • Speicher am Netz — 1 bis 2
  • Mail, Verzeichnisdienst, Datenbank — 3
  • Server-Anwendungen: Git, CI, Monitoring, Wiki, Reverse Proxy, Ticketsystem — 6
  • Arbeitsplatz-Software ohne eigenen Kanal: PDF, Archivierer, Fernwartung, Zweitbrowser — 4
  • Sammelquellen — 2 bis 3

Das landet je nach Zählweise zwischen 23 und 26, also: rund fünfundzwanzig. Das ist eine Rechnung, keine Messung — dein Bestand sieht anders aus. Was sich nicht ändert, ist die zweite Zahl dahinter. Fünfundzwanzig Adressen mal vier Prüfungen im Jahr sind hundert Nachkontrollen, und jede davon gehört zu der Sorte Aufgabe, die still einschläft.

Fünfundzwanzig Feeds pflegen oder eine Mail

Beides sind Aufwände, keine Glaubensfragen. Fünfundzwanzig Feeds im Reader kosten einen Vormittag Einrichtung und vier Nachprüfungsrunden im Jahr; dafür bekommst du die Formulierung des Herstellers selbst, ungefiltert, ohne jemanden dazwischen. Der andere Weg kostet das Anhaken einer Liste: patchletter verfolgt Versionsstände und schickt eine Mail, sobald eine neue Version erscheint — etwa auf der Produktseite zu FortiOS. Wer im Reader bleiben will, findet auf jeder Produktseite denselben Stand als eigenen Feed unter /de/software/<produkt>/feed.xml, per Autodiscovery verlinkt — der Reader-Weg bleibt also offen.

Der Unterschied gehört klar benannt: Ein Hersteller-Advisory-Feed meldet die Lücke, patchletter meldet die Version, die sie schließt. Das eine ersetzt das andere nicht. Was das zweite beantwortet, ist die Frage, die am Montagmorgen zuerst kommt — ist hier etwas anzufassen oder nicht. Was nachweislich ausgenutzt wird, steht auf der CVE-Seite, was aus dem Support läuft auf der End-of-Life-Übersicht.

Die ehrliche Einschränkung

Diese Liste ist die Momentaufnahme eines Tages. Mehrere der Adressen darin habe ich erst gefunden, nachdem eine ältere, weit verbreitete nicht mehr funktionierte, und es gibt keinen Grund anzunehmen, dass das aufhört. Behandle jede Zeile als gültig bis zu ihrem Prüfdatum und keinen Tag länger.

Es bleiben Lücken, die ich nicht schließen konnte. Red Hat, Broadcom (VMware) und Citrix liefern ihre Advisory-Übersichten per JavaScript nach; im HTML, das über die Leitung kommt, steht keine Feed-Adresse. Sophos war vom Prüfrechner aus gar nicht erreichbar. In keinem dieser Fälle heißt das, dass es keinen Feed gibt — es heißt, dass ich keinen belegen kann, und eine Liste, die sich die fehlenden Zeilen ausdenkt, ist schlechter als eine mit Löchern. Auch die Umfangsspalte misst den Tag und nicht den Hersteller: Ein Feed mit zwanzig Einträgen ist nicht schlechter als einer mit vierhundert, er ist kürzer, und das zählt nur im Verhältnis dazu, wie oft du tatsächlich hinsiehst.

Alle Feed-Angaben aus einem eigenen Abruf am 19.08.2026: jede Adresse einmal angefragt, danach HTTP-Status, Content-Type, Anzahl der item- beziehungsweise entry-Elemente sowie ältester und jüngster Zeitstempel im Dokument notiert. Feed-Adressen und ihre Inhalte ändern sich; das Prüfdatum in jeder Zeile ist die einzige Zusage, die dieser Text macht.