Der BSI-Warndienst meldet alles — so filterst du auf die Software, die du wirklich betreibst
Am 19. August 2026 um 08:39 UTC standen im öffentlichen Meldungs-Feed des BSI genau 250 Einträge, und der älteste davon war keine 48 Stunden alt. 204 dieser 250 waren gar keine neue Meldung — es waren Neuauflagen von Meldungen, die der Feed schon einmal ausgeliefert hatte, manche davon vielfach. Wer den Warn- und Informationsdienst je abonniert und nach zwei Wochen stillschweigend nicht mehr gelesen hat: an diesem Verhältnis liegt es.
Der Dienst ist nicht schlecht gemacht. Er ist vollständig auf eine Art, die keine einzelne Umgebung ist: IBM-Middleware, Siemens-Steuerungen, Android-Geräte und dein Datenbankserver bekommen dieselbe Sorgfalt. Daraus eine Arbeitsliste zu machen heißt filtern, und das Filtern bleibt an dir hängen. Hier steht, wie die Kennungen aufgebaut sind, welche drei maschinellen Bezugswege es gibt und an welcher Stelle jeder davon bricht.
Was die Nummer WID-SEC-2026-2903 sagt
Die Kennung besteht aus einem Dienst-Kürzel, dem Jahr und einem Zähler, der jeden Januar wieder bei eins beginnt. Am 19. August 2026 stand dieser Zähler auf 2903; der Zähler von 2025 war bei 2941 stehen geblieben. Im maschinenlesbaren Kanal trägt dieselbe Meldung eine zweite Kennung — WID-SEC-W-2026-2903, abgelegt als wid-sec-w-2026-2903.json — mit einem eingeschobenen Buchstaben für die Einstufung. Wer Meldungen über die Kennung indiziert, muss diesen Einschub normalisieren, sonst liegt dieselbe Meldung zweimal unter zwei Schlüsseln im Bestand.
Im öffentlichen Archiv lagen am 19. August 2026 für das Jahr 2026 genau 2857 dieser Dokumente, nummeriert von 0001 bis 2903. 46 Nummern der Folge fehlen schlicht: Diese Meldungen sind nicht als TLP:WHITE veröffentlicht, und das eingeschränkte Verzeichnis antwortet mit einem glatten 404. Eine Lücke in der Nummerierung ist also kein Abruffehler, und Code, der darauf einen Wiederholungsversuch startet, wiederholt bis in alle Ewigkeit.
Die Mengen erklären, warum das Mitlesen von Hand irgendwann aufhört zu funktionieren. Öffentliche Meldungen je Jahr in diesem Archiv: 2605 in 2023, 2666 in 2024, 2738 in 2025 — und 2857 in den ersten siebeneinhalb Monaten von 2026. Das angebrochene Jahr übertrifft das gesamte Vorjahr bereits. Diese Reihe lässt sich allerdings nicht über die Ordnernamen nach hinten verlängern: Im Ordner mit der Jahreszahl 2021 liegen 385 Dokumente, aber kein einziges mit einer 2021er-Nummer — die frühen Ordner sind keine Jahresmengen.
Der Bezugsweg, der dir nicht offensteht
Jeder Feed-Eintrag verlinkt auf eine lesbare Portalseite, und darüber hinaus gibt es drei maschinelle Wege: RSS, CSAF 2.0 und den ROLIE-Kategorien-Katalog. Nicht darunter ist der, den die meisten Anleitungen zuerst nennen: der E-Mail-Newsletter. Das BSI beschreibt den Advisory-Newsletter als Angebot für die Bundesverwaltung als geschlossene Benutzergruppe und verweist andere Organisationen auf den RSS-Feed. Wer ein mittelständisches Unternehmen betreut, plant also mit RSS oder CSAF, nicht mit einem Postfach-Abo.
Weg 1: RSS gegen eine Produktliste
Dass dieser Weg überhaupt trägt, liegt an den Titeln: Sie sind strukturiert. Das Muster ist Status, Stufe, Produkt, Wirkung — etwa [NEU] [hoch] GitLab: Mehrere Schwachstellen ermöglichen Manipulation von Dateien. Schreib die Produkte, die du betreibst, zeilenweise in eine Datei, und der ganze Filter besteht aus drei Befehlen:
curl -s https://wid.cert-bund.de/content/public/securityAdvisory/rss \ | grep -oE '<title>[^<]+' | sed 's/<title>//' \ | grep -F '[NEU] ' | grep -iEf meine-produkte.txt
Gegen den echten Feed am 19. August 2026 laufen gelassen, mit einer fünfzeiligen Datei aus postgresql, nextcloud, gitlab, proxmox und zabbix, ergab das genau eine Zeile — die GitLab-Meldung. 250 Einträge hinein, eine Aufgabe heraus.
Wo es bricht. Am Fenster. Diese 250 Einträge reichten nur bis zum 17. August 2026, 09:11 UTC zurück — keine zwei Tage. Wer wöchentlich abruft, verliert stillschweigend alles, was hinten herausgefallen ist. Also mindestens täglich abrufen und einen ausgefallenen Lauf als Datenverlust behandeln, nicht als Verzögerung.
Der zweite Bruch ist unauffälliger und kostet ausgerechnet die dringendsten Einträge. Zwei der 250 Titel folgten dem Muster mit zwei Klammern gar nicht, sie lauteten [NEU] [UNGEPATCHT] [hoch] …. Zwischen Status und Stufe steht eine zusätzliche Kennzeichnung, wenn es noch keinen Patch gibt. Ein Parser, der die zweite Klammer für die Stufe hält, legt genau die ungepatchten Meldungen unter einer Stufe ab, in die niemand schaut.
Weg 2: CSAF, wenn du CPEs abgleichen willst
Jede Meldung existiert zusätzlich als signiertes CSAF-2.0-Dokument unter einem vorhersagbaren Pfad. Die betroffenen Produkte herauszuziehen ist ein einziger Ausdruck:
curl -s https://wid.cert-bund.de/.well-known/csaf/white/2026/wid-sec-w-2026-2903.json \
| jq -r '[.. | objects | select(has("product_identification_helper"))
| .product_identification_helper.cpe] | unique[]'Für diese Meldung — neun CVEs in Oracle MySQL — kommen fünf Zeilen heraus, darunter cpe:/a:oracle:mysql:8.0.0-8.0.48.
Wo es bricht. Sieh dir die Zeichenkette noch einmal an. Das ist CPE-2.2-URI-Syntax, nicht die CPE-2.3-Schreibweise, die die meisten Inventarwerkzeuge ausgeben — und in vier der fünf Zeilen steht im Versionsfeld ein Bereich, also gar keine Version. Kein Gleichheitsvergleich gegen eine Bestandsdatenbank trifft sie jemals. Praktikabel ist: auf Hersteller und Produkt abgleichen, das Versionssegment vollständig ignorieren und die Versionsfrage selbst aus dem Meldungstext beantworten.
Der zweite Bruch ist das, was nicht im Dokument steht. In neun am 19. August 2026 stichprobenartig gezogenen Meldungen — von einer Hitachi-Meldung mit einer CVE bis zu einer Kernel-Meldung mit 405 — trug keine einzige einen CVSS-Wert oder eine CWE. Der Schweregrad ist ein einzelnes deutsches Wort für die gesamte Meldung: kritisch, hoch, mittel oder niedrig. In der Momentaufnahme über 250 Einträge waren das 4 kritisch, 115 hoch, 124 mittel, 7 niedrig. Wer nach einem Zahlenwert priorisiert oder je CVE statt je Meldung, braucht eine zweite Quelle.
Weg 3: der Kategorien-Katalog, den fast niemand benutzt
Zur CSAF-Auslieferung gehört ein ROLIE-Feed, der jede Meldung einmal auflistet — mit angehängten Kategorien: jede CVE, jeder Produktname, jeder Hersteller. Am 19. August 2026 standen darin 13.049 Einträge in rund 41 MB. Einmal holen, danach offline befragen:
jq -r '.feed.entry[]
| select([.category[].term] | map(ascii_downcase) | any(test("postgresql")))
| .id + " " + .title' bsi-wid-white.jsonDas ist der einzige Weg, der die Frage „alle Meldungen, die es je zu diesem Produkt gab“ beantwortet statt „was diese Woche passiert ist“.
Wo es bricht. Am Vokabular. Das Kategorien-Dokument führt 7752 verschiedene Produktbegriffe, und 3964 davon haben einen Vergleichsoperator im Namen stecken — Einträge wie Mattermost Mattermost < 7.9.6. Mattermost taucht unter 71 verschiedenen Begriffen auf, der Linux-Kernel unter 101. Unter den 286 Herstellerbegriffen stehen sechs Paare, die sich nur in der Groß- und Kleinschreibung unterscheiden, hp und HP darunter; unter den zwanzig Betriebssystem-Begriffen stehen Appliance und Applicance nebeneinander. Also: ohne Rücksicht auf Groß- und Kleinschreibung auf Teilzeichenketten prüfen, nie auf Gleichheit.
Es lohnt zu wissen, wie weit die drei Arten zu fragen auseinanderliegen. Für PostgreSQL: exakter Kategorienbegriff 38 Meldungen, Teilzeichenkette ohne Schreibungs-Rücksicht 40, Grep über den Titel 43 — und drei dieser Titeltreffer sind gar keine PostgreSQL-Meldungen, sondern ein cPanel/WHM-Bündel, eine Drupal-Core-Meldung und eine zu Azure Database for PostgreSQL. Der Titel ist Prosa. Die Kategorie ist ein Datenfeld. Filtere auf dem Feld.
Warum 204 von 250 Einträgen Wiederholungen waren
61 der 250 Einträge in der Momentaufnahme waren Linux-Kernel-Meldungen, fast alle mit [UPDATE] gekennzeichnet. Das ist keine Flut neuer Kernel-Lücken, sondern eine Handvoll langlebiger Meldungen, die neu herausgegeben werden, sobald eine Distribution ihre Rückportierungen ausliefert. WID-SEC-2026-1700 macht den Mechanismus sichtbar: erstmals am 27. Mai 2026 veröffentlicht, stand die Meldung am 17. August 2026 in Fassung 54 und führte 405 CVEs. Jede Fassung sagt, wer sie ausgelöst hat.
curl -s https://wid.cert-bund.de/.well-known/csaf/white/2026/wid-sec-w-2026-1700.json \ | jq -r '.document.tracking | .version, .revision_history[-1].summary'
Am 19. August 2026 kam dabei 54 heraus und Neue Updates von Amazon aufgenommen. Frühere Fassungen nennen Debian, Ubuntu, SUSE, Oracle Linux, Rocky. Daraus folgt die billigste Regel dieses Artikels: bei einem [UPDATE] zuerst die Fassungs-Zusammenfassung lesen, dann die Meldung. Nennt sie keine Distribution, die du betreibst, ist es nicht deine Aufgabe — und allein das räumt den Großteil der 204 ab. Lesen statt automatisch aussortieren: 52 der 54 Fassungen waren Distributions-Updates, eine nahm aber einen Proof of Concept zu einer einzelnen CVE auf — und das ist genau die Fassung, die eine Regel nicht wegwerfen darf.
Die ehrliche Einschränkung
Die Feed-Zahlen sind eine Momentaufnahme eines einzigen Zeitpunkts, und in diese zwei Tage fiel eine Oracle-Veröffentlichungswelle — die Produktmischung ist also nicht die einer gewöhnlichen Woche. Keine Momentaufnahme sind: die Archivmengen je Jahr, das 250er-Fenster, die CPE-Syntax und der Zustand des Kategorien-Vokabulars; das kannst du mit den Befehlen oben jederzeit nachprüfen. Eine zugesicherte Schnittstelle ist keiner dieser Wege — schreib deinen Parser also so, dass eine unerwartete Form protokolliert und nicht verworfen wird.
Die größere Einschränkung ist der Preis des Filterns. Auf die eigene Produktliste einzugrenzen heißt, den Rest bewusst nicht mehr zu sehen — und eine Lücke in einer Bibliothek, die in einem deiner Produkte mitgeliefert wird, trägt dessen Namen nicht zwangsläufig im Titel oder in der Kategorie. Ein Filter ist ein Mittel zur Vorsortierung. Er ist keine Zusicherung von Vollständigkeit, und nichts an diesen Daten verspricht eine.
Die Liste, die dir keiner der drei Wege abnimmt
Jeder Weg oben braucht dieselbe Eingabe, und sie ist der einzige Teil, der wirklich Arbeit ist: eine belastbare, aufgeschriebene Liste dessen, was du tatsächlich betreibst. Das Filtern erledigen zehn Zeilen Shell; ob es etwas bedeutet, entscheidet die Liste. Diese Liste führt patchletter. Du hakst im Katalog die Produkte an, die du betreust — an einer Produktseite wie der zu PostgreSQL siehst du, wie das aussieht — und bekommst eine Mail, sobald von einem davon eine neue Version erscheint. Davon getrennt zeigt die Seite mit den BSI-Hinweisen die CERT-Bund-Meldungen, die sich einem Produkt aus dem Katalog zuordnen ließen, jeweils mit Link auf das Original. Diese zugeordneten Meldungen sind eine Ansicht, keine Alarmierung — sie lösen keine Mails aus. Kostenlos, ohne Konto, Abmeldung mit einem Klick, gehostet in Deutschland.
Alle Zahlen am 19. August 2026 selbst abgerufen beim Warn- und Informationsdienst des BSI/CERT-Bund: dem öffentlichen RSS-Feed, der CSAF-Auslieferung samt Jahresarchiv, ROLIE-Feed und Kategorien-Dokument sowie den Dokumenten WID-SEC-W-2026-2903 und WID-SEC-W-2026-1700. Bezugswege und Zielgruppen nach der BSI-Seite zu den technischen Sicherheitshinweisen. Die Feed-Zahlen beschreiben diesen einen Zeitpunkt und bleiben bewusst stehen.