CVE-Überwachung mit freien Mitteln: vier Bauarten und wo jede bricht

Von 9.770 CVE-Einträgen, die im Juli 2026 veröffentlicht wurden, tragen 4.884 keine maschinenlesbare Angabe, welches Produkt betroffen ist. Ein Abo auf „nginx“ oder „Fortinet“ kann bei diesen Einträgen gar nicht auslösen — nicht weil das Werkzeug schlecht wäre, sondern weil im Datensatz nichts steht, worauf es passen könnte. Die erste Entscheidung beim Aufbau einer CVE-Überwachung aus freien Mitteln ist deshalb nicht die nach dem Werkzeug. Es ist die nach der Bauart.

Vier Bauarten, nicht vierzig Werkzeuge

Alles andere ist eine Abwandlung. Die Bauart entscheidet mehr als das Produkt: Ein Scanner kann eine Appliance nicht überwachen, die er nie anfasst, und ein Abo kann von einer Bibliothek nichts wissen, die du vergessen hast.

Bauart eins: der rohe Behörden-Feed

Kostenlos, ohne Konto, ohne Lizenzfrage, maschinenlesbar — und ohne jede Ahnung, wer du bist.

• CISA KEV — eine JSON-Datei, 1.670 Einträge in Katalogversion 2026.08.18. Drei Bedingungen für die Aufnahme: eine vergebene CVE-ID, ein belastbarer Beleg für Ausnutzung in freier Wildbahn und eine klare Gegenmaßnahme.
• NVD-API 2.0 — 362.257 CVE-Einträge am 19.08.2026, zurückgezogene ausgenommen. Ohne Schlüssel fünf Anfragen je 30 Sekunden, mit Schlüssel fünfzig; die Doku empfiehlt sechs Sekunden Pause zwischen den Aufrufen.
• BSI CERT-Bund WID — deutschsprachige Advisories als RSS, Schweregrad im Titel und als Kategorie.
• ENISA EUVD — die europäische Datenbank mit eigenen Kennungen und eigener API. Die NIS2-Richtlinie beauftragt die ENISA mit ihrem Betrieb.

Die Bruchstelle ist Wiederholung ohne Bezug. Der BSI-Feed hat keinen Produktfilter. Am 19.08.2026 standen im RSS-Feed 250 Einträge, 204 davon mit [UPDATE] — Fortschreibungen von Meldungen, die du schon gelesen hattest. Vier von fünf Benachrichtigungen sind Wiedervorlagen, und keine davon ist auf deinen Bestand gefiltert. Ein roher Feed ist ein Bauteil, kein Dienst: Den Teil, der entscheidet, ob dich ein Eintrag angeht, musst du selbst schreiben.

Bauart zwei: das Abo auf Anbieter und Produkt

OpenCVE ist die Referenzumsetzung. Die eigene Doku sagt es knapp: Man abonniert Anbieter und Produkte, um den Technologien zu folgen, die man einsetzt. Die Plattform führt MITRE, Vulnrichment, NVD und Red Hat zusammen, benachrichtigt per Mail, Webhook oder Slack, ordnet Abos in Organisationen und Projekte und läuft per Docker auf dem eigenen Server. Für ein Team, das seinen Bestand kennt, ist das der kürzeste Weg von „eine CVE ist erschienen“ zu „jemand weiß Bescheid“.

Die erste Bruchstelle ist die Lizenz. OpenCVE steht unter der Business Source License 1.1 und ist damit keine von der OSI anerkannte Open-Source-Lizenz. Zum Change Date am 14.08.2030 wird daraus Apache 2.0. Bis dahin lautet die Zusatzgewährung wörtlich, man dürfe das Werk nutzen, „provided that you do not use the Licensed Work for a Security Monitoring and Alerting Service“ — was genau darunter fällt, definiert die Datei nicht. Wer darauf etwas aufbauen will, liest sie vorher selbst.

Die zweite Bruchstelle ist die Zuordnung. Ein Produkt-Abo greift nur, wenn im Datensatz steht, welches Produkt betroffen ist — und genau dieses Feld fehlt bei der Hälfte. Der Abschnitt über die gemeinsame Grenze erklärt, warum.

Warum Stichwort-Abos Fehlalarme erzeugen

Die bequeme Abkürzung ist, ein Wort zu abonnieren statt einer Kennung. Was das kostet, lässt sich messen. Drei Abfragen gegen die NVD-API am 19.08.2026, für eines der verbreitetsten Infrastrukturteile überhaupt: keywordSearch=nginx liefert 369 Einträge. virtualMatchString=cpe:2.3:a:f5:nginx liefert 41. cpe:2.3:a:nginx:nginx liefert 2.

In diesen Zahlen stecken zwei Lehren. Aus dem Wort kommen rund achtmal so viele Treffer wie aus beiden Kennungen zusammen, und die Zusatztreffer sind keine versteckten Lücken, sondern Einträge, in denen nginx als Kulisse auftaucht: der Reverse Proxy vor der eigentlich verwundbaren Anwendung, eine Schicht im Container-Image, ein Schritt in einem Angriffsweg. Und dasselbe Produkt liegt unter zwei Anbieterkennungen — wer nur eine abonniert, verliert die andere stillschweigend. Die Gegenprobe gehört dazu: keywordSearch=zabbix liefert 99 gegen 96 für die Kennung. Bei einem eindeutigen Namen verschwindet der Unterschied fast. Die Fehlalarmquote hängt am Namen, nicht am Werkzeug.

Anbieter-Abos greifen zu weit. Im Juli 2026 verteilten sich die Einträge unter der CPE-Anbieterkennung apache auf 40 verschiedene Produkte — Tomcat, Log4j, Camel, Superset, Thrift, mehrere Airflow-Provider. Wer „Apache“ abonniert, hat alle vierzig abonniert.

Versionsnummern lügen. Red Hat beschreibt das Problem für die eigenen Pakete: Manche Werkzeuge entschieden allein anhand der gefundenen Versionsnummer, und das führe zu Falschmeldungen, weil zurückportierte Sicherheitskorrekturen nicht berücksichtigt würden. Genau das — eine Korrektur einbauen, ohne die Versionsnummer zu erhöhen — machen Debian, Red Hat und SUSE den ganzen Tag.

Bauart drei: der Scanner am Artefakt

cve-bin-tool (GPL-3.0, bei Intel begonnen, heute unter dem Dach der OpenSSF) dreht die Frage um. Statt dich zu fragen, was du betreibst, liest es das aus der Sache selbst heraus. cve-bin-tool <verzeichnis> durchsucht Binärdateien nach Bibliothekssignaturen und Versionsnummern; cve-bin-tool --sbom cyclonedx --sbom-file bom.json nimmt stattdessen eine SBOM entgegen, in SPDX, CycloneDX oder SWID. 448 Checker sind an Bord, die Daten kommen aus NVD, Red Hat, OSV, der GitLab Advisory Database und von curl. Ein NVD-Key ist optional; voreingestellt ist der eigene Spiegel des Projekts.

Die Bruchstelle ist, dass es nur Signaturen und Versionsnummern sieht. Das Projekt schreibt es selbst: Es könne nicht erkennen, ob jemand eine Korrektur in eine verwundbare Version zurückportiert hat, und es funktioniere nicht, wenn Bibliotheks- oder Versionsangaben absichtlich verschleiert wurden; ebenso wenig sei garantiert, dass gemeldete Schwachstellen tatsächlich vorhanden oder ausnutzbar sind — oder dass alle vorhandenen gefunden werden. Ein Bauteil ohne Checker ist unsichtbar. Und ein Scan ist eine Momentaufnahme: Er beantwortet die Frage von heute, nicht die von nächster Woche.

Bauart vier: der Bestand liegt im Dienst

OWASP Dependency-Track (Apache-2.0) behebt das Momentaufnahme-Problem. Du lieferst einmal eine CycloneDX-SBOM ein; die Plattform beobachtet die Verwendung der Bauteile über alle Versionen aller Anwendungen im Portfolio und bewertet sie laufend neu gegen NVD, GitHub Advisories, OSV, OSS Index und weitere Quellen. Wird eine neue Lücke bekannt, braucht es keinen neuen Scan — der Bestand liegt schon vor.

Die Bruchstelle ist der Bestand selbst. Was nie eingeliefert wurde, existiert für den Dienst nicht, und das ist in einer normalen Umgebung das meiste: Firewalls, Hypervisoren, NAS-Geräte, Telefonanlagen und Drucker liefern keine SBOM. Rechnet man eine weitere Datenbank und einen weiteren zu patchenden Dienst dazu, passt diese Bauart zu Software, die du baust, weit besser als zu Software, die du nur betreibst.

Die Grenze, die alle vier teilen

Am 15.04.2026 hat die NVD ihr Verfahren umgestellt, und jedes nachgelagerte Werkzeug hat die Umstellung geerbt. Die Einreichungen stiegen zwischen 2020 und 2025 um 263 Prozent. Die NVD hat 2025 knapp 42.000 CVEs angereichert, 45 Prozent mehr als je zuvor — und kam trotzdem nicht hinterher. Seither werden drei Gruppen vorrangig angereichert: CVEs aus dem CISA-KEV-Katalog, mit dem erklärten Ziel eines Arbeitstages; CVEs für Software der US-Bundesverwaltung; und kritische Software nach Executive Order 14028. Alles andere läuft als „Lowest Priority — not scheduled for immediate enrichment“, und der gesamte Rückstand mit Veröffentlichungsdatum vor dem 01.03.2026 wurde auf „Not Scheduled“ gesetzt.

Die Anreicherung ist genau der Schritt, aus dem die CPE-Produktlisten entstehen. Daher die Zahl vom Anfang: Von 9.770 Einträgen aus dem Juli 2026 trugen 4.886 eine Produktliste und 4.884 keine — und die fehlenden liegen genau dort, wo die Anreicherung nicht gelaufen ist. Jeder Eintrag mit dem Status „Deferred“, „Awaiting Analysis“ oder „Received“ hatte keine — zusammen 4.800 Stück; die restlichen 84 standen auf „Undergoing Analysis“. „Deferred“ heißt offiziell: derzeit nicht für die Anreicherung eingeplant. Der Juni 2026 war mit 4.318 von 7.943 nur unwesentlich besser. CISAs Vulnrichment füllt die Lücke nicht: Seit dem 10.12.2024 fügt CISA dem angereicherten Datenbestand keine CPE-Zeichenketten mehr hinzu. Daraus folgen zwei Dinge — die Regel, dass keine Meldung nicht keine Lücke heißt, und die Beobachtung, dass die einzige Spur mit einer verbliebenen Zusage der Ausnutzungsnachweis ist.

Wo patchletter in dieser Aufstellung steht

patchletter ist die vierte Bauart in ihrer schmalsten Form: Du hakst die Produkte an, die du betreibst, und der Dienst hält diese Liste — seine reguläre Aufgabe ist, dir zu sagen, wenn eines davon ein neues Release herausgibt. Für die CVE-Frage gleicht er dieselbe Liste täglich gegen den KEV-Katalog ab, also gegen nachweislich Ausgenutztes und nichts Weiteres. Die Grenzen gehören vor den Nutzen. Es ist kein Scanner — es sieht deine Binärdateien nie und findet die vergessene Bibliothek nicht. Es ist kein Inventar — es kennt nur, was du angehakt hast. Und es ist bewusst kein vollständiger CVE-Feed: Die CVE-Seite spiegelt den KEV-Katalog gegen verfolgte Produkte, also nachweislich Ausgenutztes — eine Untergrenze, keine Obergrenze.

Wer baut statt abonniert, nimmt die andere Tür: die öffentliche REST-API. /api/v1/products/{slug}/cves liefert die Treffer eines Produkts mit knownExploited-Kennzeichen, Ransomware-Marker und CISA-Frist; /api/v1/cves dasselbe über alle verfolgten Produkte; /api/v1/openapi.json ist die maschinenlesbare Spezifikation. Lesender Zugriff braucht kein Konto und keinen Schlüssel. Zwischen rohem Feed und selbst betriebenem Scanner ist das die Schicht, die in der Tabelle oben sonst fehlt.

Die ehrliche Einschränkung

Keine der vier Bauarten beantwortet die Frage, auf die es ankommt: Bist du angreifbar? Das hängt an deiner Version, deiner Konfiguration, daran, ob das Modul geladen und der Port erreichbar ist — und davon weiß kein Feed etwas. Auch der KEV-Katalog ist kein Maß für Gefahr. 1.670 Einträge, gesammelt seit November 2021, sind eine sehr kurze Liste, und sie ist mit Absicht kurz: Drei Bedingungen müssen erfüllt sein, bevor etwas darauf landet. Was darauf steht, ist belegt. Was fehlt, ist nur unbelegt.

Alle Zahlen extern, abgerufen am 19.08.2026. Monatliche CVE-Menge, CPE-Abdeckung, die nginx- und zabbix-Vergleiche und die Apache-Produktzahl: NVD-API 2.0, abgefragt mit noRejected, keywordSearch und virtualMatchString, über den vollen Monat ausgezählt. Rate-Limits und Statusdefinitionen: NVD-Entwicklerseiten und NVD-Statusseite. Priorisierungsregeln, die 263 Prozent und die Anreicherungszahlen: NVD-Ankündigung vom 15.04.2026. KEV-Anzahl, Katalogversion 2026.08.18 und die drei Aufnahmekriterien: CISA. CPE-Hinweis: README von cisagov/vulnrichment. Lizenzbedingungen: LICENSE von opencve/opencve. Checker-Zahl: README von ossf/cve-bin-tool. Feed-Zusammensetzung: BSI-CERT-Bund-WID-RSS. Backporting-Zitat: Red Hat. Keine Zahl in diesem Artikel stammt aus dem eigenen Bestand.