EUVD: die Datenbank, die dein Scanner nicht kennt

06.08.2026

Thema: alle Beiträge zu Docker

Europa betreibt seit Mai 2025 eine eigene Datenbank für Schwachstellen. Die API ist offen und ohne Token, aber kein verbreiteter Scanner bindet sie ein. Ein Scan liefert 504 CVE und null EUVD.

Inhaltsverzeichnis

• Die Antwort vorweg
• Was die EUVD ist
• Die API ist offen, ohne Token
• Kein verbreiteter Scanner bindet sie ein
• Nachgemessen: 504 CVE, null EUVD
• Warum das kaum wehtut, und trotzdem zählt
• Dein Scanner ist eine Quellenauswahl
• Fazit
• Quellen

Europa betreibt seit Mai 2025 eine eigene Datenbank für Schwachstellen. Dein Scanner kennt sie nicht.

Das ist kein Skandal und kein Argument gegen die Datenbank. Es ist ein gutes Beispiel für etwas, das im Umgang mit solchen Werkzeugen regelmäßig schiefgeht: Man hält die Ausgabe eines Scanners für die Wirklichkeit, dabei ist sie eine Quellenauswahl.

Die Antwort vorweg

Ein Scanner sagt dir nicht, was verwundbar ist. Er sagt dir, was in den Quellen steht, die er abfragt.

Konkret, gemessen am 1. August 2026: Ein trivy-Scan über ein Debian-nginx liefert 511 Schwachstellen-Kennungen, davon 504 CVE und null EUVD. Die EUVD-Kennungen existieren, sind offen abrufbar und werden von keinem verbreiteten Scanner ausgegeben.

Inhaltlich verlierst du dadurch wenig, weil die EUVD auf CVE abbildet. Als Befund über die Werkzeugkette ist es trotzdem lehrreich.

Was die EUVD ist

Die European Vulnerability Database, kurz EUVD, wird von der ENISA betrieben, der EU-Agentur für Cybersicherheit. Sie ist seit Mai 2025 öffentlich, ist das europäische Gegenstück zur amerikanischen NVD und ausdrücklich als Baustein des Cyber Resilience Act gedacht.

Der Punkt dahinter ist nicht, dieselben Daten ein zweites Mal zu führen. Der Punkt ist, dass die Kennungen von europäischen Stellen vergeben werden. Ein Beispiel aus dem Einzelabruf:

curl -s "https://euvdservices.enisa.europa.eu/api/enisaid?id=EUVD-2026-51526" \
  | jq '{id, assigner, baseScore, epss}'

{
  "id": "EUVD-2026-51526",
  "assigner": "CERT-PL",
  "baseScore": 8.6,
  "epss": 0
}

assigner: CERT-PL, also das polnische CERT. Genau das ist die Substanz hinter dem Wort Souveränität in diesem Zusammenhang: nicht eine Kopie, sondern eine zweite Stelle, die Kennungen vergeben darf, unter europäischer Zuständigkeit. Wer sich daran erinnert, wie eng es im Frühjahr 2025 um die Finanzierung des CVE-Programms stand, versteht, warum das mehr ist als Symbolpolitik.

Die API ist offen, ohne Token

Technisch ist die EUVD erfreulich unaufgeregt. Keine Registrierung, kein API-Schlüssel, kein Rate-Limit-Header, den man erst verstehen muss:

curl -s https://euvdservices.enisa.europa.eu/api/lastvulnerabilities | jq '.[0]'

# gekuerzt auf drei Felder
{
  "id": "EUVD-2026-50404",
  "aliases": "GHSA-x85f-hvgg-4944\nCVE-2026-20316\n",
  "baseScore": 5.3
}

Am 1. August 2026 geprüft, alle ohne Zugangsdaten:

Ein einzelner Eintrag trägt 14 Felder, darunter baseScore mit Vektor und CVSS-Version, epss, datePublished, dateUpdated, assigner, references und eben aliases.

Zwei Beobachtungen dazu, beide reproduzierbar.

Der exploitedvulnerabilities-Endpunkt ist der interessanteste. Genau um aktiv ausgenutzte Schwachstellen geht es in der CRA-Meldepflicht ab dem 11. September 2026. Am Messtag standen dort vier Einträge, alle vier mit CVE-Alias:

curl -s https://euvdservices.enisa.europa.eu/api/exploitedvulnerabilities \
  | jq '{n: length, mit_cve: ([.[] | select(.aliases | test("CVE-"))] | length)}'

{
  "n": 4,
  "mit_cve": 4
}

Der Such-Endpunkt antwortet bei mir nicht. Drei Versuche hintereinander, jedes Mal 429 mit dem Text Too many concurrent search requests. Please try again shortly., während lastvulnerabilities im selben Atemzug sauber mit 200 antwortet. Das sieht nach einer serverseitigen Begrenzung gleichzeitiger Suchanfragen aus, nicht nach einem Fehler auf meiner Seite. Ob das dauerhaft so ist oder eine Tagesform war, kann ich von außen nicht sagen. Für den Bau eines Werkzeugs, das auf Suche angewiesen ist, wäre es die erste Frage.

Kein verbreiteter Scanner bindet sie ein

Und jetzt der Befund, der mich überrascht hat: Kein verbreiteter Scanner gibt EUVD-Kennungen aus.

Portale und Aggregatoren wie Vulners oder Vulnerability-Lookup führen die EUVD durchaus. Das ist aber ein Nachschlagewerk und kein Scanner: Es hilft dir, wenn du eine Kennung schon hast, nicht dabei, sie in deinem Image zu finden.

Nachgemessen: 504 CVE, null EUVD

Nachprüfen lässt sich das ohne Vertrauen in irgendeine Ankündigung. Ich habe ein Debian-nginx gescannt und die Kennungen nach Präfix ausgezählt:

trivy image --format json --output vulns.json nginx:1.27
jq -r '.Results[]?.Vulnerabilities[]?.VulnerabilityID' vulns.json | sed 's/-.*//' | sort | uniq -c

    504 CVE
      5 TEMP
      2 DSA

511 Kennungen, davon 504 CVE, fünf Debian-Zwischenkennungen für noch nicht final zugewiesene Fälle, zwei Debian Security Advisories. Keine einzige EUVD-Kennung. Getestet mit trivy 0.72.0 gegen nginx:1.27, Digest sha256:6784fb0834aa7dbbe12e3d7471e69c290df3e6ba810dc38b34ae33d3c1c05f7d.

Warum das kaum wehtut, und trotzdem zählt

Erstens ist die Lücke inhaltlich klein. Die EUVD bildet über das aliases-Feld auf CVE und GHSA ab. Wer nach CVE arbeitet, sieht dieselben Schwachstellen unter einem anderen Namen. Es fehlt keine Information, es fehlt eine Kennung.

Zweitens ist sie trotzdem bemerkenswert. Europa baut sich eine eigene Datenbank als Teil einer Verordnung, und die Werkzeuge, mit denen die Betroffenen tatsächlich arbeiten, sprechen sie über ein Jahr nach dem Start noch nicht. Wer die EUVD heute im Prozess haben will, muss selbst abfragen. Die API macht das leicht, aber es ist eben Eigenbau.

Und drittens, der Punkt, um den es mir eigentlich geht: Diese Lücke ist nur sichtbar, wenn man weiß, dass es die Datenbank gibt. Nichts in der Ausgabe eines Scanners deutet darauf hin, dass eine Quelle fehlt. Eine Liste mit 504 Einträgen sieht vollständig aus.

Dein Scanner ist eine Quellenauswahl

Das ist dieselbe Beobachtung wie im Vergleich von Docker Scout und Trivy: Zwei Werkzeuge, dasselbe Image, verschiedene Zahlen, weil sie aus verschiedenen Datenbanken speisen und unterschiedlich zählen. Die EUVD ist der nächste Beleg dafür, nur diesmal von der anderen Seite: nicht eine Quelle, die anders zählt, sondern eine, die gar nicht erst abgefragt wird.

Daraus folgt kein Werkzeugwechsel. Es folgt eine Frage, die man einmal pro Werkzeug beantworten sollte:

1. Aus welchen Quellen speist mein Scanner? Bei Trivy steht das in der Dokumentation zur Datenbank, und die Datenbank selbst kommt als OCI-Artefakt aus einer Registry
2. Wie oft wird die Datenbank aktualisiert, und was passiert, wenn das Update ausfällt? Ein Scanner mit veralteter Datenbank meldet nicht weniger, er meldet still Falsches
3. Welche Kennungsräume gibt es, die ich nie zu sehen bekomme? EUVD ist einer. Herstellereigene Advisories sind ein anderer

Das ist wieder die erste der zwei Säulen: Ein Werkzeug, das man nicht versteht, liefert keine Sicherheit, sondern eine Zahl. Wer weiß, woher die Zahl kommt, kann eine fehlende Quelle einordnen. Wer es nicht weiß, hält die Ausgabe für vollständig.

Fazit

1. Die EUVD ist real, offen und ohne Token erreichbar. Betrieben von der ENISA seit Mai 2025, ausdrücklich als Baustein des CRA
2. Die Kennungen vergeben europäische CERTs. Der geprüfte Eintrag kam von CERT-PL. Das ist der eigentliche Gehalt, nicht die Datenhaltung
3. Kein verbreiteter Scanner bindet sie ein. Trivy und Grype haben seit über einem Jahr offene Feature-Requests, ohne Pull Request
4. Nachgemessen: 504 CVE, null EUVD in einem Debian-nginx, trivy 0.72.0
5. Inhaltlich ist die Lücke klein, weil aliases auf CVE abbildet. Praktisch ist sie ein Lehrstück darüber, dass eine Scanner-Ausgabe immer eine Quellenauswahl ist
6. Der Such-Endpunkt antwortete reproduzierbar mit 429, die Listen-Endpunkte mit 200. Wer darauf ein Werkzeug bauen will, sollte das vorher prüfen

Wer wissen will, ab wann er selbst melden muss und wen die Pflicht überhaupt trifft, findet das im Beitrag zum Cyber Resilience Act. Und praxisnahe Antworten auf die häufigsten Docker- und Kubernetes-Probleme gibt es in meinem Newsletter. Kein Spam, kein Beratersprech.

Quellen

• European Vulnerability Database der ENISA und die API-Dokumentation
• Verordnung (EU) 2024/2847 (Cyber Resilience Act), Artikel 14 zur Meldepflicht bei aktiv ausgenutzten Schwachstellen
• Offene Feature-Requests zur EUVD: Trivy Discussion 8958 und Grype Issue 2601
• Messungen in diesem Beitrag vom 1. August 2026, trivy 0.72.0 gegen nginx:1.27, Digest sha256:6784fb0834aa7dbbe12e3d7471e69c290df3e6ba810dc38b34ae33d3c1c05f7d

© 2026 Trutz Software Consulting GmbH. CC BY 4.0: Dieser Text darf mit Namensnennung weiterverwendet und bearbeitet werden, auch kommerziell. Code-Beispiele darin stehen unter Apache 2.0. Ausgenommen sind Marke und Logo sowie gekennzeichnete Zitate Dritter. Was das genau heißt.

Newsletter

Erhalte praxisnahe Tutorials, Best Practices und echte Lösungen für die häufigsten DevOps-Probleme direkt in Dein Postfach.

Datenschutz: Deine E-Mail-Adresse wird DSGVO-konform in Deutschland gespeichert. Keine Spam, nur relevante Inhalte. Eine E-Mail alle 1 bis 2 Wochen.