Bildquelle: Bildquelle: Pexels / MART PRODUCTION / https://www.pexels.com/photo/a-man-looking-at-files-8872363/
Container-Scans brauchen mehr als NVD-Scores, sonst kippen Priorisierung und SLAs ins Leere
Viele Vulnerability-Programme im Container-Umfeld arbeiten noch mit einer stillen Grundannahme: Der CVE-Eintrag kommt von der CNA oder aus CVE, die eigentliche betriebliche Einordnung liefert danach die NVD mit CVSS, CPE-Mapping und ergänzenden Klassifikationen. Genau diese Annahme trägt seit Mitte April nicht mehr verlässlich. Für Security-, Plattform- und Cloud-Teams ist das keine Fußnote über Datenfeeds, sondern eine direkte Betriebsfrage. Wenn Scans, Priorisierung und Remediation-SLAs auf NVD-Anreicherung als Standardfall gebaut wurden, laufen Programme bei weniger angereicherten CVEs schneller in unklare Schweregrade, lückenhafte Paketzuordnung und schwerer belegbare Auditentscheidungen.
NIST hat am 15. April 2026 offiziell auf ein priorisiertes Anreicherungsmodell umgestellt. Voll priorisiert werden seitdem vor allem drei Gruppen: CVEs aus CISA-Katalogen bekannter Ausnutzung, CVEs für Software im Einsatz der US-Bundesverwaltung und CVEs für als kritisch definierte Software. Alle anderen Einträge bleiben zwar in der NVD sichtbar, laufen aber in eine niedrig priorisierte Schiene statt in flächendeckende sofortige Anreicherung. Zusätzlich will NIST eigene Severity-Scores nicht mehr routinemäßig doppeln, wenn die meldende CNA bereits einen Score geliefert hat. Auch bei später geänderten CVEs wird nicht mehr automatisch alles neu analysiert, sondern nur noch dann, wenn die Änderung das Enrichment materiell beeinflusst.
Das klingt zunächst wie ein Vorgang für Datenfeed-Betreiber. Für Container-Programme ist die Wirkung aber viel direkter. Container-Scans leben davon, Pakete, Layer und transitive Abhängigkeiten präzise gegen Advisory-Daten abzugleichen. Wenn ein CVE keine belastbare NVD-Anreicherung mehr bekommt, fehlen in klassischen NVD-zentrierten Ketten oft genau die Informationen, die bisher den Rest der Betriebslogik ausgelöst haben. Dann existiert die Schwachstelle zwar formal, landet aber operativ schwächer, später oder in anderer Form im tatsächlichen Remediation-Prozess.
Warum Container-Programme stärker betroffen sind als klassische Host-Listen
Docker beschreibt den Kern des Problems ziemlich nüchtern. Zwei NVD-Bausteine sind für Container-Scans besonders relevant: CPE-Zuordnungen zur betroffenen Software und CVSS-Werte zur Priorisierung. Fehlen CPE-Daten, kann ein Scanner, der primär auf CPE-Matching setzt, betroffene Pakete in Images schlechter oder gar nicht zuordnen. Fehlen Scores, rutschen Findings schneller in unscharfe Severity-Klassen oder außerhalb automatischer SLA-Routinen. Genau das ist in Container-Welten heikel, weil hier nicht ein einzelnes Paket auf einem Server betroffen ist, sondern ein Befund über Basis-Images und nachgelagerte Builds vervielfältigt werden kann.
Hinzu kommt, dass Container-Images mehrere Ebenen gleichzeitig mitbringen: Distribution, Systempakete, Laufzeit, Application Dependencies und oft weitere Artefakte aus der Build-Kette. Wenn ein Teil dieser Kette nur über grobe Produkt-Mappings statt über präzise Paketbezüge bewertet wird, steigen sowohl False Positives als auch blinde Flecken. Das war schon bisher ein Problem. Mit schmalerer NVD-Anreicherung wird daraus schneller ein Strukturproblem für Programme, die ihre Schwachstellenlage stark auf eine einzige Bewertungsquelle verdrahtet haben.
NIST selbst nennt dafür die Größenordnung. Laut der Mitteilung hat sich das CVE-Volumen zwischen 2020 und 2025 um 263 Prozent erhöht. 2025 habe NIST zwar fast 42.000 CVEs angereichert, aber selbst dieses Rekordniveau reiche nicht mehr aus, um den Eingang vollständig abzuarbeiten. Für Security-Teams bedeutet das: Die Verengung ist keine kurze Störung, sondern eine operative Realität, auf die Prozesse und Toolauswahl reagieren müssen.
Was robuste Scanner anders machen müssen
Die eigentliche Lehre lautet deshalb nicht, dass die NVD unwichtig geworden wäre. Sie bleibt relevant, aber sie darf nicht länger der alleinige Taktgeber sein. Docker Scout dokumentiert dazu einen Weg, der auch jenseits des Docker-Stacks als Prüffrage taugt: mehrere Advisory-Quellen statt nur NVD, Priorisierung von Vendor Advisories für passende Pakete und Paketabgleich über PURLs statt über breite CPE-Muster. In der Dokumentation ist das ausdrücklich beschrieben. Scout aggregiert mehrere Sicherheitsquellen und nutzt Package URLs, um Pakete präziser zu identifizieren. Wenn kein Score aus der bevorzugten Quelle vorliegt, kann ein Fallback aus einer anderen Quelle angezeigt werden; wenn gar kein CVSS vorhanden ist, bleibt das Finding ausdrücklich als unspezifiziert markiert statt künstlich sauber gerechnet.
Diese Details klingen technisch, sind aber operativ Gold wert. Ein gutes Programm muss künftig nachvollziehbar beantworten können, auf welcher Advisory-Quelle eine Severity beruht, was bei fehlender NVD-Bewertung passiert und ob ein Paket über einen präzisen Paketbezug oder nur über ein grobes Produktschema zugeordnet wurde. Genau daraus entsteht später auch Auditfähigkeit. Denn Auditoren und Management wollen im Zweifel nicht nur wissen, dass ein Scanner rot oder grün zeigt, sondern auf welcher Datenbasis die Risikobewertung zustande kam.
Die wichtigste Änderung betrifft nicht das Dashboard, sondern die Prozesslogik
Viele Teams werden den Effekt zuerst im Dashboard sehen: mehr unvollständig angereicherte Findings, mehr Rückfragen zu Prioritäten, mehr Ausnahmen rund um ungescorte CVEs. Die entscheidende Arbeit liegt aber hinter dem Dashboard. Erstens sollten Teams prüfen, ob Remediation-SLAs auf NVD-Enrichment-Daten oder auf CVE-Disclosure und vendorbasierter Bewertung beruhen. Zweitens braucht es eine saubere Fallback-Logik für Severity und Paketzuordnung, damit Findings nicht still aus der Betriebsroutine kippen. Drittens sollten offene Altfälle vor dem von NIST genannten Stichtag 1. März 2026 gegen die neue „Not Scheduled“-Logik überprüft werden, damit intern dokumentierte Ratings nicht unbemerkt auf veralteten NVD-Annahmen beruhen.
Viertens gehört die Lieferantenseite auf den Prüfstand. Docker formuliert dazu die richtigen Fragen, und sie gelten vendorübergreifend: Welche Advisory-Quellen nutzt ein Scanner jenseits der NVD? Wie wird „gepatcht“ definiert? Wird die Frist ab CVE-Veröffentlichung oder erst ab nachgelagerter Anreicherung gemessen? Lassen sich saubere Scan-Ergebnisse mit öffentlichen Quellen oder Dritttools plausibilisieren? Wer diese Fragen heute nicht beantworten kann, hat kein reifes Container-Sicherheitsprogramm, sondern nur ein lauffähiges Tooling.
Genau deshalb ist der NVD-Schwenk keine Randnotiz für Compliance-Folien. Er zwingt Container-Programme dazu, ihre eigene Datenabhängigkeit sichtbar zu machen. Das betrifft nicht nur Security-Scanner, sondern auch Policy Gates, Release-Freigaben, Exception Handling, Ticket-Priorisierung und Management-Reporting. Wenn Severity und Paketbezug nicht sauber getragen sind, wird aus scheinbar objektiver Schwachstellensteuerung schnell eine Routine mit zufälligen Lücken.
Fazit
Container-Scans brauchen seit April 2026 mehr als NVD-Scores, um belastbar zu bleiben. Wer weiterhin so arbeitet, als liefere die NVD flächendeckend dieselben Enrichment-Daten wie früher, riskiert blinde Flecken bei Paketzuordnung, unscharfe Priorisierung und angreifbare SLA-Logik. Die sauberere Antwort lautet nicht Panik, sondern Architekturarbeit: mehrere Advisory-Quellen, präziser Paketbezug, dokumentierte Fallbacks und eine ehrliche Prüfung der Frage, worauf die eigene Severity- und Patchroutine tatsächlich basiert.
Für Plattform-, Cloud- und Security-Teams ist das am Ende sogar eine hilfreiche Klärung. Nicht das lauteste Dashboard gewinnt, sondern das Programm, das seine Quellen, Zuordnungen und Ausnahmepfade sauber erklären kann. Genau daran entscheidet sich, ob Container-Sicherheit unter wachsendem CVE-Druck stabiler wird oder nur lauter.
