Security und CVE-Bewertung
8484 umgesetzt
- umgesetzt: Security-Ansichten teilen sich den einmal geladenen Asset-/Wazuh-Bestand für Inventar und Abdeckungsberechnung, statt dieselben JSON-Daten erneut zu laden
- umgesetzt: Evidenzbasierte CVE-Vorprüfung — deduplizierte offene Prüfkontexte erhalten aus identischem Wazuh-Systemkontext, exakt korrelierten OpenVAS-Treffern, QoD, Asset-Abdeckung und belegter Scannermaßnahme einen transparent begründeten nächsten Prüfschritt samt Evidenzvertrauen. Der Wert ist ausdrücklich weder Risikoscore noch automatische CVE-Entscheidung; ein fehlender Scannerfund gilt nie als Entwarnung.
- umgesetzt: Zentrale Security-Sicherheitslage
- umgesetzt: Wazuh-Agent-Zuordnung, Agent-Abdeckung und Agentstatus
80 weitere anzeigen
- umgesetzt: Evidenz-Abdeckungsmatrix je aktivem Compute-Asset mit normalisierter Plattform, Release und Architektur, ausschließlich den bereits implementierten autoritativen Herstellerquellen, deren letztem Erfolgs- und Fehlerzeitpunkt sowie konservativ sichtbaren Profil-, Abruf- und Ablauf-Lücken — . Daraus wird eine rein lesende, priorisierte Arbeitsliste abgeleitet: identische Plattform-/Release-/Architekturprofile werden dedupliziert, betroffene aktive Assets und CVE-Kontexte gebündelt und vorhandene, fehlende, fehlgeschlagene oder abgelaufene autoritative Quellen mit erklärbarer Priorität im Drill-down ausgewiesen. Die Liste verwendet nur gespeicherte Bestands- und Quellenmetadaten; sie erfindet keine Feeds und startet keine externen Aktionen
- umgesetzt: Vollständiges Laden der Wazuh-CVEs über mehrere Indexer-Seiten
- umgesetzt: Assetbezogene und assetübergreifende CVE-Arbeitslisten
- umgesetzt: Filter nach CVE, Paket, Schweregrad, Bewertung und Wiedervorlage
- umgesetzt: Sortierung und Pagination
- umgesetzt: Lokale CVE-Risikobewertung
- umgesetzt: Sammelbewertung der vollständigen Filtermenge ohne Checkbox-Auswahl
- umgesetzt: Bewertete CVEs standardmäßig ausgeblendet und optional einblendbar
- umgesetzt: Konsistentes Ersetzen einer vorhandenen Bewertung
- umgesetzt: Optionale Begründung
- umgesetzt: Wiedervorlage standardmäßig auf heute plus ein Jahr
- umgesetzt: Entfernung von „Manuelle Prüfung nötig“ nach einer Bewertung
- umgesetzt: Kennzahlen und Arbeitsansichten für unbewertete, bewertete und fällige CVEs
- umgesetzt: Konservative, selbst aktualisierende Gruppierung offener CVE-Funde nach CVE, Paket, Version, Betriebssystem, Release und Architektur — die Arbeitsliste zeigt eindeutige und mehrfach vorkommende Prüfkontexte, ohne Bewertungen automatisch auf andere Assets zu übertragen. Die dokumentierte Rolle und der Dienstekatalog eines Assets sind bewusst nicht Teil der Kontextidentität: Sie ändern nicht, ob eine installierte Paketversion laut Hersteller verwundbar ist, hatten technisch identische Systeme aber in getrennte Kontexte zerlegt. Die Kontext-Detailansicht weist die über alle Assets hinweg dokumentierten Dienste weiterhin aus, damit eine expositionsbezogene Sammelbewertung die Streuung vor der Bestätigung sieht
- umgesetzt: Prüfkontext-Detailansicht mit aktuellem Zielbestand, Asset-/Systemevidenz und ausdrücklich bestätigter Sammelbewertung — der Kontext wird beim Speichern neu berechnet, technisch abweichende Assets werden ausgeschlossen und jede Entscheidung wird auditiert
- umgesetzt: CVE-Prüfkontexte laden Asset-Dienste gebündelt und berechnen den assetbezogenen Fingerprint nur einmal je Asset, sodass die Datenbanklast nicht mehr mit der Anzahl der CVE-Funde wächst
- umgesetzt: Vollständige paginierte Prüfkontext-Arbeitsliste mit Suche, Schweregrad- und Wiederverwendungsfilter — einzelne und assetübergreifend identische Kontexte lassen sich priorisiert öffnen und kontrolliert bewerten
- umgesetzt: Offene Prüfkontexte speichern und aggregieren jetzt einen erklärbaren Blockierungsgrund. Der Herstellerresolver hinterlegt die Ursache einer offenen Entscheidung ausdrücklich als unresolved_cause, sodass PRISM „Paket keiner Herstellerquelle zugeordnet“, „Distribution oder Release unbekannt“, „Hersteller führt CVE/Paket nicht“ und „Herstellerfeed nicht auswertbar“ getrennt ausweist statt sie zu einem Sammelgrund zu verdichten. Fundstellen ohne jede Evidenz gelten ausdrücklich als „noch kein Evidenz-Audit gelaufen“ und werden nicht länger als fehlende Herstellerzuordnung gezählt; die Security-Übersicht trennt diese Abdeckungslücke sichtbar von tatsächlich bewerteten, aber unentschiedenen Kontexten und nennt den größten Block zuerst. Vor der Aufteilung persistierte Entscheidungen bleiben lesbar. Bewertungen werden dadurch nicht automatisch verändert
- umgesetzt: Modularer, assetbezogener Debian-/Ubuntu-Evidenz-Audit über ein separates read-only AWX-Playbook — PRISM erfasst Binär- und Quellpaket samt installierter Version per dpkg-query und bewertet diese zusätzlich gegen den offiziellen Debian-Security-Tracker-Feed beziehungsweise Canonicals Ubuntu-OVAL-Feed. Nachweislich fehlende oder laut Vendor bereits reparierte Pakete werden automatisch aus dem aktiven Bestand entfernt und vom Vendor bestätigte verwundbare Versionen als betroffen dokumentiert. Ein reiner Wazuh-Paketversions-Treffer ohne eindeutige Herstellerbewertung gilt nicht mehr automatisch als bestätigte Betroffenheit; solche sowie nicht im Feed auflösbare Fälle bleiben mit explizitem Prüfauftrag offen. Die Fundstellen werden je Asset nach eindeutigem Paket gebündelt: AWX fragt jedes installierte Paket nur einmal ab und PRISM überträgt das Ergebnis anschließend auf alle zugehörigen CVEs. Das vollständige Paket-/CVE-Manifest verbleibt dabei in PRISM und AWX liefert je Paket nur ein kompaktes Resultat zurück, damit große CVE-Gruppen nicht durch abgeschnittene Jobausgaben verloren gehen; die Batch-Grenze zählt Pakete statt CVE-Fundstellen. Der allgemeine AWX-Start und Relaunch des Evidenz-Templates ist ohne den von PRISM erzeugten Asset-/CVE-Kontext gesperrt; Remediation oder Risikofreigabe erfolgen nie automatisch
- umgesetzt: Auftragsbezogener Evidenzbericht mit sichtbarer automatischer Abdeckung, getrennten Mengen für Handlungsbedarf, manuelle Prüfung, entkräftete und technisch fehlende Funde — . Jede Entscheidung zeigt Asset, CVE, Paketstände, verständliche Begründung, Vertrauenswert und Herstellerquelle; AWX-Liveausgaben sind nur noch als eingeklappte technische Diagnose erreichbar. Fehlende, ungültige oder widersprüchliche Jobresultate werden konservativ als Fehler markiert und in der zentralen Aufgabenliste vorgelegt
- umgesetzt: Wazuh-Scannerbedingung, CVE-Beschreibung, CTI-/Herstellerreferenzen und Bewertungsquelle werden in PRISM übernommen. Der Evidenzbericht bündelt offene Funde je Asset und Paket zu konkreten Maßnahmen und zeigt pro Entscheidung den nächsten Schritt: Update/Fix einspielen, Einsatzkontext und Angriffsvoraussetzungen prüfen oder ohne unmittelbare Aktion beobachten
- umgesetzt: Browserunabhängiger Start der CVE-Evidenz-Audits über den PRISM-Scheduler mit sofortiger Rückmeldung, sichtbarem Startauftrag und automatisch aktualisiertem Laufzustand — die primäre CVE-Arbeitsliste ist auf „Aktion erforderlich“, „Manuell prüfen“, „Entkräftet“ und „Wiedervorlage“ reduziert, während die rohe Einzelfundliste als erweiterte Ansicht erhalten bleibt
- umgesetzt: Alte Kernel lassen sich gezielt entfernen: PRISM plant je Asset nur die Kernelpakete ein, die älter als der aktuell laufende Kernel sind. Der laufende bleibt, ein neuerer noch nicht gebooteter ebenfalls, und bei nur einem installierten Kernel geschieht nichts. Die Regel wird in PRISM entschieden; ein eigenes read-write AWX-Playbook entfernt ausschließlich namentlich übergebene Pakete und prüft vorher auf dem Host, ob der laufende Kernel noch dem erwarteten entspricht. Die Detailseite zeigt die Vorschau vor der Ausführung. Dies ist die einzige Remediation ohne Einzelfreigabe; der Neustart bleibt ausdrücklich freigabepflichtig. Der Start erfolgt aus der Detailseite „Nicht aktiv ausnutzbar“: PRISM friert den Plan in einen Auftrag ein, der Scheduler startet je System einen AWX-Job, und das strukturierte Ergebnis wird zurückgelesen. Ein technisch erfolgreicher Job ohne Ergebniszeile gilt ausdrücklich als nicht bestätigt. Bleibt danach ein Neustart offen, erscheint er als eigene, freigabepflichtige Aufgabe in der zentralen Aufgabenliste. Einrichtung in AWX beschreibt docs/runbooks/prism-kernel-cleanup.md
- umgesetzt: Die Security-Kennzahlen gruppieren nach erforderlicher Handlung statt nach internem Bewertungsstatus. Gemessen auf einer echten Umgebung lagen zwei Drittel aller „betroffenen“ Funde auf Kerneln, die installiert sind, aber nicht ausgeführt werden – nicht ausnutzbar und eine Aufräum-, keine Sicherheitsaufgabe. Die Übersicht zeigt deshalb gefundene CVEs, noch nie geprüfte, ohne automatische Entscheidung sowie Handlungsbedarf nach Dringlichkeit (laufender Kernel, Neustart nötig, Update einspielen) und eine grüne Karte ohne Handlungsbedarf (nicht betroffen, bereits behoben, Hersteller behebt nicht, nicht aktiv ausnutzbar). Jede Kategorie verlinkt auf eine Detailseite mit Treffern und Begründung. Die Einordnung ist rein lesend und verändert keinen Bewertungsstatus
- umgesetzt: Die Security-Sicherheitslage beantwortet zuerst die Frage „ist etwas Neues gefährlich geworden?“, bevor sie Bestandszahlen zeigt. Eine Neuigkeiten- Sektion leitet aus der unveränderlichen Entscheidungshistorie ab, was sich verändert hat: aktiv angegriffene Funde (CISA KEV), erneut zu prüfende Rückschritte, Scanner-Bestätigungen, neu bestätigte Betroffenheit und geklärte Fälle. Gleiche CVE über mehrere Systeme bleibt ein Eintrag, und ein Sammellauf wird gedeckelt statt die Liste zu fluten. „Nichts Neues“ ist eine ausdrückliche, beruhigende Antwort statt eines Leerzustands. Das Zeitfenster ist zwischen letztem Besuch, 24 Stunden, 7 und 30 Tagen umschaltbar; der Besuchszeitpunkt wird je Benutzer festgehalten und bei langer Abwesenheit auf 30 Tage begrenzt. Die Sektion ist rein lesend
- umgesetzt: Der Ablauf-Abschnitt klappt sich ein, solange alle Schritte grün sind: Eine Zeile mit drei Statuspunkten und der Zahl laufender Audits genügt dann. Braucht ein Schritt Aufmerksamkeit, öffnet er sich automatisch. Damit bleibt die Arbeitsliste im Normalfall ohne Scrollen erreichbar
- umgesetzt: Die Security-Sicherheitslage trennt drei Aktionen sichtbar voneinander: „Neuer Scan“ startet den inkrementellen AWX-Evidenz-Audit, „Re-Audit“ fragt auch unveränderte Paketkontexte erneut über AWX ab, und „Neubewertung“ entscheidet bereits erfasste Paketevidenz ohne AWX gegen die aktuellen Herstellerfeeds neu. Neubewertung und Probelauf laufen als browserunabhängige Hintergrundaufträge über den PRISM-Scheduler; ein zweiter Auftrag wird abgelehnt, solange einer läuft
- umgesetzt: Bereits erfasste Paketevidenz kann lokal gegen die aktuellen Herstellerfeeds neu bewertet werden (reevaluate_cve_evidence, mit --dry-run). Der AWX-Audit erfasst, was installiert ist; die Feeds entscheiden, ob es verwundbar ist. Erhält ein Feed die passende Meldung erst nach dem Audit, bleibt die Paketevidenz gültig, während ihre Entscheidung veraltet – und der paketinkrementelle Fingerprint ändert sich dabei nicht, sodass kein weiterer Audit sie erneut anfasst. Der Lauf schließt diese Lücke, ohne AWX erneut nach denselben Paketen zu fragen. Erneut bewertet werden ausschließlich Entscheidungen des Evidenz-Audits; ein menschliches Urteil bleibt unangetastet. Bleibt eine Entscheidung unverändert, wird zumindest ihr Blockierungsgrund präzisiert, sofern der Herstellerresolver inzwischen eine genauere Ursache liefert; das ist keine Entscheidung und erzeugt deshalb keinen Historieneintrag. Die Entscheidungslogik ist dafür aus dem Audit herausgezogen, damit beide Wege nicht auseinanderlaufen können
- umgesetzt: NVD und OSV werden nur noch für Fundstellen abgerufen, die bereits als betroffen bewertet sind. Beide Quellen verändern nachweislich keine Herstellerentscheidung, sondern werden erst nach dem Paketbefund als Kontext angehängt; ein flächendeckender Abruf verbrauchte damit Laufzeit und NVD-Rate-Limit für Kontexte ohne Nutzen. Debian, Ubuntu und CISA KEV bleiben Vollabzüge über alle Funde
- umgesetzt: NVD-CVE-Abfragen werden mit konfigurierbarem, schlüsselabhängigem Rate-Limit, begrenzten 429-Retries und sichtbarem Hintergrundfortschritt gegen API-Limits abgesichert; der optionale API-Schlüssel bleibt außerhalb von Code und Datenbank
- umgesetzt: Unveränderliche CVE-Entscheidungshistorie für Bewertungen aus Assetansicht, globaler Arbeitsliste, Prüfkontext und AWX-Evidenz-Audit — bestehende Bewertungen werden mit ihrem bisherigen Entscheidungsstand übernommen und eine Detailansicht erklärt Statusübergang, Begründung, Quelle, Evidenz, Vertrauenswert, Prüfer, Zeitpunkt, Ablauf und Wiedervorlage
- umgesetzt: Security-Übersichten unterscheiden unbewertete Funde, offene Prüfungen, bestätigte Betroffenheit, akzeptierte Risiken, nicht betroffene und behobene Funde mit direktem Drill-down statt der mehrdeutigen Sammelkennzahl „bewertet“
- umgesetzt: Die zentrale Security-Sicherheitslage ist als kompakte, aktionsorientierte Steuerungsansicht — Handlungsbedarf, Evidenz-Audit-Fortschritt, priorisierte Prüfkontexte und kontrollierte Remediation sind direkt erreichbar; Wazuh-Agentdetails bleiben getrennt und einklappbar verfügbar
- umgesetzt: Security-Sicherheitslage und CVE-Arbeitsbereich sind zu einer zentralen, kompakten Arbeitsansicht zusammengeführt: Quellenaktualisierung, Evidenz-Audit, Scannerstatus sowie filterbare und paginierte Prüfkontexte sind ohne Seitenwechsel bedienbar; die Einzelfund- und Sammelbewertung bleibt als bewusst nachgelagerte erweiterte Ansicht erhalten
- umgesetzt: Security-Filter verwenden eine automatisch invalidierte, pro Webprozess wiederverwendete Projektion des persistierten Wazuh-/Scannerbestands, statt bei jedem Seitenwechsel erneut alle CVE-Fundstellen aufzubauen. Laufende Quellenaufträge zeigen Phase, Fortschritt und Zwischenzähler; gebündelte Maßnahmen springen direkt zu den gefilterten Berichtsergebnissen
- umgesetzt: Security-Kennzahlen trennen den gesamten persistierten Entscheidungsbestand sichtbar vom Delta des letzten inkrementellen Evidenz-Audits. Lokale Security-Cache-Einträge werden als Evidenzdatensätze statt als Anzahl externer Quellen bezeichnet; laufende Audits sind eindeutig von der Nummer und dem Ergebnis des letzten Auftrags getrennt
- umgesetzt: Die Security-Sicherheitslage führt Quellenabgleich, Übernahme der aktuellen OpenVAS-Ergebnisse und inkrementellen Evidenz-Audit als dreistufigen, altersbewerteten Ablauf. Grün, Gelb und Rot zeigen unmittelbar, ob ein Stand aktuell, zeitnah zu erneuern oder vor dem nächsten Schritt zwingend zu aktualisieren ist. Die lokale Zahl wird ausdrücklich als Anzahl nutzbarer Hersteller- und CVE-Wissensdatensätze erklärt, nicht als Anzahl von Datenanbietern. Wazuh-Abdeckung und Agent-Rohbestand liegen ohne redundante Zweitdarstellung auf einer eigenen Detailseite.
- umgesetzt: Die konservative OpenVAS-Korrelation ist als sichtbarer Trichter von Scannerfund, Asset- und CVE-Zuordnung über den exakten Wazuh-Treffer und die QoD-Richtlinie bis zur automatisch bestätigten Betroffenheit erklärt. Damit ist direkt erkennbar, an welcher fachlichen Stufe Scannerwissen noch keine persistierte CVE-Entscheidung auslöst.
- umgesetzt: Greenbone-OpenVAS-NVTs liefern ihre strukturierten CVE-Referenzen, NVT-OID und solution_type mit dem Scannerfund; direkte NVT-CVE-Felder werden als kompatibler Fallback unterstützt und mit der bestehenden Freitext-Erkennung vereinigt. Dadurch können weitere belastbare Scanner-CVE-Korrelationen die unveränderte konservative Asset-/CVE-/QoD-Regel erreichen.
- umgesetzt: Eindeutige und manuell bestätigte Scanner-Hostzuordnungen lernen den normalisierten Host als Asset-Alias mit Herkunft und Zeitpunkt. Künftige Importe verwenden diese Aliasse, übernehmen alte bestätigte Zuordnungen beim nächsten Lauf nach und behandeln Alias-Konflikte weiterhin konservativ als mehrdeutig.
- umgesetzt: Asset- und Security-Kennzahlen führen den Wazuh-Rohbestand weiterhin nachvollziehbar mit, zählen lokal nachweislich nicht betroffene oder bereits behobene aktuelle Funde jedoch nicht mehr als aktive CVEs; bestätigte Betroffenheit und akzeptierte Risiken bleiben im relevanten Bestand
- umgesetzt: Debian-/Ubuntu-Kernelmeldungen werden im read-only Evidenz-Audit mit dem aktuell laufenden Kernel und dem Neustartbedarf abgeglichen. Signierte und Meta-Kernelpakete werden auf die eigentliche Herstellerquelle wie linux oder linux-hwe-* normalisiert; aktive, weiterhin installierte inaktive und Meta-Kernel werden nachvollziehbar getrennt. Ein inaktiver Kernel wird dabei nicht unsicher als „nicht betroffen“ entkräftet
- umgesetzt: Der read-only Evidenz-Audit erfasst zusätzlich das konfigurierte nächste Boot-Ziel: eine eindeutige GRUB-Einmalauswahl hat Vorrang vor gespeichertem Standard und Debians /vmlinuz-Ziel; nicht auflösbare Menüindizes werden nicht geraten. Der wartende Kernel bildet eine eigene Evidenzklasse, löst Neustartbedarf auch ohne Markerdatei aus und ist von der Altkernel- Bereinigung ausgeschlossen. Meldet Wazuh nur das Metapaket, kann dieses die konservative Herstellerentscheidung des belegten Boot-Ziels übernehmen
- umgesetzt: Der Evidenz-Audit reichert Vendor-Ergebnisse zusätzlich mit dem öffentlichen CISA-KEV-Katalog an. Ein KEV-Treffer wird als externe Exploitations-Evidenz mit Datum, Produkt, Begründung und erforderlicher Maßnahme gespeichert, darf den Paketstatus aber nicht allein verändern; der Katalog wird je Prozess gecacht und bei Nichterreichbarkeit konservativ übersprungen
- umgesetzt: Externe Security-Quellen sind vom Evidenz-Audit entkoppelt: CISA KEV, Debian- und Ubuntu-Vollfeeds sowie inkrementelle NVD-/OSV-Kontexte werden in einem persistenten Cache gespeichert. Der Audit arbeitet cache-only, ein manueller Hintergrundauftrag und der tägliche Lauf nach 01:00 Uhr verwenden denselben Refresh-Service; frische Kontexte werden wiederverwendet. Ob der Tageslauf noch aussteht, wird aus den persistierten Aufträgen abgeleitet, sodass ein Neustart des Schedulers keinen zusätzlichen Lauf auslöst.
- umgesetzt: Feed-Änderungen invalidieren automatisierte Evidenzbewertungen gezielt nur für die betroffenen CVE-/Paket-Kontexte. Die persistierte Bewertung und ihre Entscheidungshistorie bleiben erhalten; evidence_expires_at erzwingt beim nächsten Audit lediglich eine erneute Prüfung. Unveränderte Kontexte bleiben durch die bestehende inkrementelle Wiederverwendung geschützt.
- umgesetzt: Canonicals offizieller Ubuntu-OSV-Bulkfeed wird durch den getrennten Quellenauftrag lokal und pro CVE verdichtet gespeichert. Der Evidenz-Audit kann damit Paket-/Release-Kombinationen, die Canonical ausdrücklich nicht als betroffen aufführt, entkräften und installierte Versionen gegen vorhandene Fix-Versionen entscheiden; gelistete Kombinationen ohne eindeutige Fix-Version bleiben weiterhin konservativ in der manuellen Prüfung.
- umgesetzt: Canonicals OpenVEX-Bulkfeed wird für die im PRISM-Bestand vorkommenden CVEs und unterstützten Ubuntu-Releases ebenfalls lokal verdichtet. Explizite Herstellerzustände für betroffen, nicht betroffen und behoben fließen automatisch in die Bewertung ein; under_investigation bleibt ohne unsichere Schlussfolgerung als manueller Prüfauftrag erhalten.
- umgesetzt: Wiederholte Evidenz-Audits arbeiten paketinkrementell: Ein eigener Fingerprint aus Asset, CVE-/Paketversion, Evidenzrichtlinie und zugeordneten Laufzeitprüfungen erlaubt die Wiederverwendung gültiger Paketkontexte. Neue oder geänderte Pakete werden weiterhin an AWX übergeben, ohne bis zu 250 unveränderte Pakete desselben Asset-Batches erneut abzufragen.
- umgesetzt: Laufzeitabhängige Kernel-Evidenz wird trotz unveränderter Paketfingerprints bei einem neuen Evidenz-Audit erneut abgefragt. Ein Neustart kann den zuvor laufenden verwundbaren Kernel ohne Paketänderung zu einem inaktiven Kernel machen; eine kürzlich erfolgreiche Paketabfrage darf diesen Zustandswechsel deshalb nicht verdecken. Gleichzeitig lädt die Security-Inventur nur die tatsächlich benötigten Vendor-, Kernel-, Blockierungs- und Richtlinienfelder aus der großen Evidenzstruktur, ohne pro Fund eine nachgelagerte Datenbankabfrage auszulösen.
- umgesetzt: Der nachvollziehbare CVE-Entscheidungsbericht kann mit den aktiven Asset-, Ergebnis- und Suchfiltern als UTF-8-CSV exportiert werden.
- umgesetzt: Status und Herkunft der lokalen Security-Quellen werden transparent aufgeschlüsselt: Die Sammelkennzahl ist eindeutig als Anzahl lokaler Cache-Datensätze beziehungsweise Evidenzkontexte statt als Anzahl externer Anbieter bezeichnet und ein Drill-down zeigt CISA KEV, Debian, Ubuntu, NVD und OSV getrennt mit Cache-Schlüssel beziehungsweise Release, verfügbaren, veralteten und fehlerhaften Einträgen, letztem erfolgreichen Abruf, Datenstand, Ablaufzeitpunkt und letzter Fehlermeldung. Auftragsstatus und fachliches Ergebnis sind getrennt darzustellen, damit ein technisch erfolgreich abgeschlossener Aktualisierungsauftrag mit einzelnen fehlgeschlagenen Quellenkontexten wird dadurch nicht mehr als vollständiger Import missverstanden.
- umgesetzt: Der Betriebsstatus der Herstellerdaten bewertet nur noch die Quellen, von denen der aktuelle CVE-Bestand tatsächlich abhängt. „Aktuell“, „veraltet“, „fehlerhaft“ und „fehlt“ überschneiden sich nicht mehr; ein abgelaufener Eintrag zählt nie gleichzeitig als verwendbar. Auf einer echten Umgebung gehörten 15 von 38 abgelaufenen Einträgen zu Fundstellen, die niemand mehr bearbeiten kann – sie werden getrennt als historisch ausgewiesen und färben die Ampel nicht mehr gelb. Abruffehler bleiben unabhängig davon sichtbar, weil ein fehlgeschlagener Download auch ohne Bezug zum aktuellen Bestand ein Betriebsproblem ist
- umgesetzt: Die Security-Übersicht verwendet den bereits aufgebauten Wazuh-Bestand auch für den Herstellerstatus. Zuvor wurden bei jedem kalten Seitenaufruf alle 15.566 Fundstellen zweimal projiziert; der überflüssige zweite Durchlauf verursachte in der Produktionsmessung allein rund 6,6 Sekunden Wartezeit
- umgesetzt: Abgelaufene Herstellerdaten entscheiden nicht mehr: Debian- und Ubuntu-Feeds werden in diesem Zustand ausdrücklich verweigert, sodass ein Fund mit erklärtem Grund offen bleibt statt auf veralteter Grundlage entkräftet zu werden. NVD-, OSV- und KEV-Kontext bleibt lesbar, wird aber als veraltet gekennzeichnet, weil überholter Kontext für die Priorisierung weiterhin besser ist als keiner
- umgesetzt: Die Herstelleraktualisierung kennt dieselben zwei Betriebsarten wie der Evidenz-Audit. „Nur Änderungen“ lädt fehlende und abgelaufene Quellen des aktuellen Bestands nach, „Alles neu“ erneuert zusätzlich die globalen Kataloge. Läufe bleiben pro Durchgang begrenzt, melden aber keinen vollständigen Import mehr, solange relevante Restmengen offen sind: Der Auftrag bleibt eingeplant und der nächste Durchlauf ermittelt die Restmenge neu aus Ablaufzeitpunkt und Zielmenge. Dadurch übersteht er einen Prozessneustart ohne gespeicherten Zeiger und bleibt abbrechbar
- umgesetzt: „Alles neu“ im Evidenz-Audit erreicht jetzt auch Paketkontexte, deren Bewertung noch gültig ist. Vorher entschied die Kandidatenauswahl vor dem Force-Pfad und schloss genau die Kontexte aus, die erneut geprüft werden sollten. Manuell getroffene Bewertungen bleiben auch bei einem erzwungenen Lauf unangetastet
- umgesetzt: Einzelne CVE-Entscheidungen lassen sich revisionsfähig als PDF und als UTF-8-CSV exportieren. Die gefilterte Arbeitsliste besitzt ebenfalls einen druckbaren Bericht; Berichtssnapshots zeigen die Entwicklung seit der vorherigen Ausgabe mit Diagrammen und Flottenbezug
- umgesetzt: Alle Security-Zahlen nennen ihre Einheit und stellen Maßnahme vor Menge: „12 Pakete aktualisieren · betrifft 56 CVEs“ statt einer nackten Zahl. Ein Neustart wird dabei je Maschine gezählt, alles andere je Paket, weil ein einzelnes veraltetes Paket hunderte CVEs tragen kann, aber nur eine Maßnahme ist. Die Kategorie-Detailseite weist dieselbe Trennung je System aus
- umgesetzt: Maßgeblich für „ist ein Update einspielbar“ ist die release-spezifische Herstellerangabe, nicht die genannte Fix-Version. Debian nennt auch die Version aus unstable oder einem neueren Release, obwohl für das installierte Release nichts zurückportiert wurde; ein vollständig gepatchtes System meldete dadurch Arbeit, die apt gar nicht anbieten kann. Der Entscheidungsbericht benennt diesen Fall ausdrücklich
- umgesetzt: Bestätigte Funde ohne veröffentlichte Fix-Version bilden eine eigene Kategorie „Noch kein Fix verfügbar“ und zählen nicht als Handlungsbedarf: Die neueste vom Hersteller angebotene Version ist bereits installiert, es gibt nichts einzuspielen. Sie verschwinden nicht, sondern stehen unter „Beobachten“; sobald der Hersteller eine Fix-Version nennt, wandern sie bei der nächsten Bewertung automatisch zu „Update einspielen“
- umgesetzt: Der Ablauf-Abschnitt bietet auch im eingeklappten Zustand „Jetzt bewerten“ an, damit die häufigste Aktion ohne Aufklappen erreichbar bleibt
- umgesetzt: Der CVE-Entscheidungsbericht erklärt sich in fünf Schritten fester Reihenfolge: Systembefund, Herstellerurteil, Scannerbestätigung, Priorisierungskontext und nächste Aktion. Ein Schritt ohne Daten sagt ausdrücklich, dass nichts vorliegt; ein fehlender Scannerfund wird als „kein Beleg für Sicherheit“ benannt. Technische Rohdaten bleiben einklappbar erreichbar (ADR 0003 Phase 4)
- umgesetzt: Die Kategorie-Detailliste ist sortierbar – der Schweregrad nach Risiko statt alphabetisch – und zeigt die betroffenen Systeme als anklickbare Filter, weil eine Suchmaske nicht beantworten kann, welche Hosts betroffen sind
- umgesetzt: Die Greenbone-Lösungsevidenz wird vollständig genutzt: Der Lösungstyp aus den NVT-Tags wird persistiert, und der CVE-Prüfkontext zeigt die vom Scanner vorgeschlagene Maßnahme samt Typ, auslösendem Test, NVT-OID und Erkennungsqualität. Bei mehreren Treffern gewinnt die höchste QoD. Der Vorschlag ist als Netzwerkperspektive gekennzeichnet, verändert keinen Bewertungsstatus, und ein fehlender Scannertreffer entkräftet nie (ADR 0003 Phase 3)
- umgesetzt: Der Wazuh-Systembefund ist je Fundstelle nachvollziehbar: Die Detailseite einer Kategorie zeigt neben Paket, Version und Architektur auch die Bedingung, die den Befund ausgelöst hat, sowie die Herstellerquelle, die Wazuh dafür herangezogen hat, und den Erkennungszeitpunkt. Fehlt eine dieser Angaben, wird sie ausdrücklich als fehlend ausgewiesen und nie als Entwarnung gelesen (ADR 0003 Phase 2)
- umgesetzt: Interne Quellen haben Vorrang vor externen: Wazuh liefert je Fundstelle bereits CVSS-Score, Schweregrad, Scannerbedingung und Beschreibung – gemessen für alle 15566 Fundstellen der Entwicklungsumgebung. NVD und OSV werden deshalb nur noch dort abgerufen, wo intern kein CVSS-Score vorliegt. Der in ADR 0003 geplante NVD-Bulkimport entfällt damit; der Nachtrag zur ADR hält die Messung und die geänderte Entscheidung fest
- umgesetzt: OPNsense- und FreeBSD-Paketfunde werden gegen den offiziellen FreeBSD- VuXML-Katalog geprüft. PRISM speichert nur die verdichteten CVE-, Paket- und Versionsbereiche im lokalen Security-Cache und entscheidet ausschließlich bei exakter Paketzuordnung und eindeutig vergleichbarer pkg-Version. VuXML-Sonderversionen, fehlende Bereiche und veraltete Kataloge bleiben ausdrücklich als manuelle Prüfung offen; ein fehlender Treffer erzeugt keine Entwarnung.
- umgesetzt: OPNsense-Firewalls ohne Wazuh-Agent können denselben Katalog über den bestehenden read-only AWX-Vertrag nutzen. Das Playbook liest mit pkg query höchstens 4.096 installierte Pakete, verändert weder Paket- noch Repository- Zustand und transportiert die vollständige Liste nur im begrenzten AWX- Jobresult zur lokalen Zuordnung. PRISM verwirft sie danach; persistiert werden Paketanzahl und Fingerprint sowie höchstens 250 exakte betroffene oder wegen pkg-Sonderversionen offene VuXML-Nachweise; die allgemeine Paketliste wird nicht gespeichert. Ein unvollständiges Inventar, ein veralteter Feed oder eine nicht eindeutig vergleichbare Version bleibt fail-closed und erzeugt keine Entwarnung.
- umgesetzt: Langfristig laufende Gunicorn-Worker protokollieren alle konfigurierten 250 realen HTTP-Aufrufe ihren aktuellen, bisherigen und seit der ersten Probe gewachsenen RSS strukturiert und ohne Request-, Benutzer- oder Assetdaten. Ab 64 MiB Wachstum wird die Probe als Warnung ausgegeben; Intervall und Schwelle sind konfigurierbar. Die letzten 14 Tage werden kompakt persistiert und je Worker-Laufzeit ausgewertet. Erst drei aufeinanderfolgende Proben über der Schwelle erzeugen eine zentrale Aufgabe; Einzelspitzen bleiben sichtbar, aber alarmieren nicht. Die geschützte Statusseite zeigt aktuellen RSS, Peak, Wachstum und Empfehlung. max-requests mit Jitter wird weiterhin nur nach einem realen Produktionsalarm und Ursachenprüfung aktiviert.
- umgesetzt: Weitere autoritative Herstellerhinweise außerhalb von Debian Security Tracker, Ubuntu OVAL, Red Hat Product Security und SUSE Product Security OVAL sowie dokumentierte kompensierende Maßnahmen als nachvollziehbare Bewertungsgrundlage speichern. Ein generischer, PRISM-gesteuerter read-only Vertrag für Dienst-, Modul-, Port- und Konfigurationsprüfungen ist — die Laufzeitevidenz wird strukturiert mit true, false oder null gespeichert, verändert den Vendor-Status aber noch nicht automatisch. CISA KEV ist als Kontextquelle — NVD-/OSV-Kontext wird je CVE/Paketversion gecacht und als externe Evidenz mit CVSS/CWE-Metadaten sowie OSV-Treffern gespeichert; diese Quellen verbessern die Priorisierung, verändern den konservativen Herstellerstatus aber nicht automatisch. Nicht erreichbare Quellen bleiben sichtbar. Weitere Red-Hat-CVE-Daten werden inkrementell je benötigter CVE gecacht und für RHEL gegen die installierte RPM-EVR aufgelöst. Rocky wird CVE-bezogen aus der offiziellen Apollo-Errata-API, AlmaLinux aus dem offiziellen JSON-Errata-Feed bewertet; nur Hauptversion, Binärpaket und RPM-EVR mit eindeutigem Treffer entscheiden. Red-Hat-Daten bleiben für beide reiner Upstreamkontext. Rockys Errata-loses Notfall-security-Repository bleibt konservativ offen. SLES-Service-Packs werden nur gegen ihren offiziellen, produktgenauen SUSE-OVAL-Feed und die installierte Binärpaket-EVR entschieden; fehlende Paket- oder Service-Pack-Zuordnungen bleiben offen. Windows-CVEs werden gegen öffentliche MSRC-CSAF-Advisories entschieden, sofern Produktlinie, Release, Architektur, Installationstyp und vierteiliger Build eindeutig passen; installierte und ausstehende KBs werden dabei strukturiert und begrenzt erhoben. Ein leerer Updatekatalog ist keine Entwarnung. Weitere distributions- und herstellerspezifische Quellen werden nur für tatsächlich im Bestand vorhandene Plattformen priorisiert. Große Ubuntu-, AlmaLinux- und SUSE-Vollfeeds werden pro Worker-Durchlauf begrenzt verarbeitet; Fortschritt und Restmenge bleiben am Auftrag erhalten, der nach einem Neustart anhand atomar gespeicherter Feed-Snapshots fortsetzt. Ein Teilstand wird nie als vollständiger Refresh markiert
- umgesetzt: Maschinenlesbare Ergebnisse wie „betroffen“, „nicht anwendbar“ und „manuelle Prüfung nötig“ sind mit Begründung und Evidenz vorhanden. Kompensierende Maßnahmen werden als eigener, weiterhin überwachter Status mit Art, Beschreibung, Nachweis, Vertrauenswert, Prüfer und Ablaufdatum persistiert und unveränderlich in der Entscheidungshistorie festgehalten. Sie lassen sich optional an vorhandene, manifestgebundene Laufzeitregeln koppeln. Deren Ergebnis wird als technisch bestätigt, nicht bestätigt oder unklar historisiert; ein negatives oder fehlendes Ergebnis erzeugt eine Prüfaufgabe und niemals eine automatische Entwarnung. Weitere Herstellerquellen bleiben offen. Fachliche Laufzeitregeln lassen sich deterministisch nach CVE, Paket, Plattform und Release begrenzen; die exakte Zuordnungsgrundlage wird aus dem gestarteten Manifest in der Evidenz historisiert und erzeugt keine automatische Entwarnung
- umgesetzt: Eine selektive Security-Änderungshistorie je Asset erfasst fachliche Zustandsänderungen aus CVE-Evidenz-Audits, Wazuh-bestätigten Patchjobs und Kernelbereinigungen. Sie zeigt Zeitpunkt, Ausführungsart, Quelle, Anlass und kompakte Vorher-/Nachher-Werte. Unveränderte Läufe, Polling und reine Telemetrie erzeugen ausdrücklich keinen Eintrag
- umgesetzt: Erfolgreich bestätigte Security-Patchjobs und Kernelbereinigungen planen automatisch einen erzwungenen, assetgenauen Wiederholungs-Audit ein. Mehrere gleichzeitige Änderungen werden in einem Auftrag zusammengefasst; ein bereits laufender Audit erhält einen nachfolgenden Auftrag, sodass kein Trigger verloren geht. Unbeteiligte Assets werden nicht erneut geprüft
- umgesetzt: Assets ohne Wazuh-Agent bleiben als eigene Abdeckungslücke sichtbar und werden auf Debian/Ubuntu sowie RHEL, Rocky Linux, AlmaLinux und SLES optional im gebündelten read-only AWX-Audit erfasst. PRISM speichert nur Paketanzahl, anonymisierten Paketstand und die Zahl der Aktualisierungskandidaten. Daraus entsteht ausdrücklich keine CVE- oder „nicht betroffen“-Entscheidung
- umgesetzt: Neue, verschwundene und fachlich geänderte externe Scanner-Evidenz wird inkrementell verarbeitet. Sinkt die QoD unter die Freigabegrenze oder ändert sich die CVE-/Asset-Zuordnung, wird eine zuvor automatisch bestätigte Scanner-Entscheidung konservativ zur manuellen Prüfung geöffnet
- umgesetzt: Unsichere und widersprüchliche Laufzeit-Vorprüfungen werden als zentrale Security-Aufgabe mit direktem Sprung in die CVE-Entscheidung vorgelegt. Die Aufgabe verlangt ausdrücklich eine manuelle Prüfung; sie trifft weder eine Risikofreigabe noch startet sie eine Remediation
- umgesetzt: Eine herstellerneutrale Schwachstellenscanner-Schnittstelle und ein erster Greenbone-/OpenVAS-GMP-Adapter bilden die Grundlage für externe Scan-Evidenz. Der Adapter kann Verbindung, vorhandene Ergebnisse und den Status genau eines explizit freigegebenen Tasks lesen sowie diesen Task kontrolliert starten; Scanner-Tasks oder deren Konfiguration verändert er nicht. Asset-Zuordnung, persistenter Import und eine konservative Zuordnung über eindeutige Asset-Adresse beziehungsweise Hostname sind — . Scannerfunde werden idempotent mit CVE-Referenzen, Schweregrad, Port, Lösung und Beobachtungszeit gespeichert, verändern bestehende CVE-Entscheidungen aber nicht automatisch. Die Security-Übersicht und eine filterbare Detailansicht zeigen aktuelle, zugeordnete, offene und über identisches Asset plus CVE mit Wazuh korrelierte Funde. Offene Asset-Zuordnungen erscheinen gebündelt in der Aufgabenliste. Eine erklärbare Evidenzstufe unterscheidet gemeinsame Scanner-/Wazuh-CVEs, Scannerfunde mit hoher Erkennungsqualität, bloß zugeordnete Funde und offene Zuordnungen. Gemeinsame Asset-/CVE-Evidenz priorisiert zusätzlich die offene CVE-Arbeitsliste und zeigt QoD, betroffene Assets sowie beobachtete Ports, ohne den Bewertungsstatus zu verändern. Mehrdeutige Asset-Zuordnungen werden nicht geraten: PRISM speichert die erkannten CMDB-Kandidaten, weist sie in Übersicht und Arbeitsliste gesondert aus und lässt die Zuordnung offen. Ein berechtigter Benutzer kann einen dieser Kandidaten kontrolliert bestätigen oder die Zuordnung wieder lösen; Auswahl, Benutzer und Zeitpunkt werden auditiert und spätere Imports überschreiben eine bestätigte Zuordnung nicht still. Eine streng begrenzte automatische Bestätigung von Betroffenheit ist für exakt dasselbe Asset und dieselbe CVE — wenn Wazuh den aktuellen Paketfund meldet und der externe Scanner mindestens QoD 95 erreicht. PRISM speichert Scannerfund, Port, Bericht, Lösung, QoD und Ablaufdatum als unveränderliche Entscheidungsevidenz. Scannerfunde dürfen niemals automatisch „nicht betroffen“, „behoben“ oder „Risiko akzeptiert“ setzen und überschreiben keine vorhandene manuelle oder herstellerbasierte Bewertung. Verschwindet ein so automatisch bestätigter Fund aus einem späteren Scannerbericht, setzt PRISM ihn konservativ wieder auf „Prüfung erforderlich“ und protokolliert den Statuswechsel; das bloße Ausbleiben gilt nicht als Behebungsnachweis. Die Security-Übersicht und Scanner-Arbeitsliste weisen diese erneut zu prüfenden Entscheidungen gesondert aus. Auf der Integrationsdetailseite kann PRISM außerdem genau einen explizit konfigurierten Greenbone-Task kontrolliert starten. Taskstatus und Fortschritt werden vorab gelesen; aktive Tasks werden weder in der Oberfläche noch bei der serverseitigen Startprüfung doppelt gestartet. Der Start wird auditiert. Ziele, Scan-Konfigurationen, Zeitpläne und Berichte bleiben unverändert unter Greenbone-Verwaltung.
- umgesetzt: Verschwundene Wazuh-Fundstellen werden als behoben verbucht. Wazuh liefert einen Ist-Stand: Ein gepatchtes Paket wird nicht mehr gemeldet, und dieses Ausbleiben ist der Nachweis. Der Scheduler gleicht nach jedem Durchlauf ab und setzt betroffene Bewertungen mit Zeitpunkt, Grund und Eintrag in der Entscheidungshistorie auf behoben. Die Erhebung muss dafür verfügbar sein **und** weiter Funde tragen – ein System, das nichts meldet, gilt als Lücke in der Abdeckung, nie als aufgeräumt. Manuelle Urteile und akzeptierte Risiken bleiben unberührt. Beim ersten Lauf am 5. August 2026 wurden so 391 längst geschlossene Fundstellen nachgebucht, 40 Systeme übersprungen.
- umgesetzt: Der Evidenz-Audit mit Policy-Version 10 ist über den Bestand gelaufen (5. August 2026, 07:28). Von 16.547 Fundstellen tragen 15.467 die aktuelle Policy; 1.080 stehen noch auf älterer oder fehlender Evidenz und werden beim nächsten Durchlauf nachgezogen. Die korrigierte Bewertung entfernter Pakete und unbekannter Kernelzustände wirkt damit auf dem produktiven Bestand: 11.129 Fundstellen sind belegt nicht betroffen, 2.964 bestätigt betroffen, 1.621 offen, 823 behoben und 10 als Risiko akzeptiert.