vulncheck/TESTERTEXT.md

TrueVuln — Update auf dev (Netdisco-Connector: Switche & Router als Assets, Aruba-, Cisco- und Extreme-Firmware-CVEs)

git pull
docker compose build
docker compose up -d
docker compose exec backend alembic current   # erwartet: 052 (head)

Migration noetig (052) — die laeuft aber schon beim Containerstart (entrypoint.sh), deshalb oben nur die Kontrolle. Ein zusaetzliches alembic upgrade head direkt nach up -d rennt gegen den Start-Lauf und bricht mit "expected to match one row when updating '050' to '051'" ab; die Migration ist dann trotzdem durch, nur eben im anderen Prozess.

Weder der Cisco- noch der Extreme-Teil bringt eine neue Migration mit — 052 bleibt head. Wer die Netdisco-Karte schon getestet hat, muss also nur bauen und neu starten.

Backend und Frontend.

---

Was neu ist

Unter Settings → Netdisco (switches & routers) gibt es einen Connector wie den fuer vCenter und IGEL. Er liest den deviceinventory-Report der Netdisco-API und legt jedes dort bekannte Geraet als Asset an — mit Hostname, IP, Standort, Modell, Seriennummer und Firmware-Version. Fuer sechs Firmware-Linien werden daraus CVE-Findings: die drei HPE-Aruba-Linien, Cisco IOS XE / IOS XR und neu Extreme Networks EXOS (Switch Engine).

Warum ueberhaupt: ein Switch laeuft ohne Agent, keine MDM kennt ihn, und ein Nessus-Scan ohne SNMP-Zugangsdaten sieht einen offenen Port und keine Version. Die Geraete, an denen alles andere haengt, waren damit die einzigen ohne jede Abdeckung — nicht "sauber", nur nie angeschaut. Netdisco fragt sie ohnehin per SNMP ab und kennt die Firmware.

Konfiguration

Feld	Bedeutung
Host / Port	Default 5000 — der Netdisco-eigene Webserver
HTTPS	aus per Default: der eingebaute Webserver kann kein TLS. Anhaken, wenn ein Reverse-Proxy davor steht (dann auch den Port anpassen)
Verify SSL	nur mit HTTPS relevant — aus, wenn der Proxy ein internes CA-Zertifikat traegt
API-Key	empfohlen. Wird als Authorization: <key> geschickt, ohne Bearer
Username / Passwort	Alternative: wird einmal an POST /login geschickt, das genau so einen Key zurueckgibt

Key oder Zugangsdaten reichen — es ist dasselbe Verfahren, nur von zwei Seiten: der Login erzeugt den Key. Beides leer laeuft auch, aber nur fuer eine Instanz ganz ohne Authentifizierung (die oeffentliche Demo). Produktiv gehoert ein Key rein.

Nightly um 02:40 UTC, direkt nach dem IGEL-Sync und vor dem App-CVE-Scan um 03:20. "Test" und "Sync now" wie bei den anderen Karten; der Lauf landet im Sync-Ledger unter Scan Jobs.

Der Test meldet "N devices, M of them on a firmware line with CVE coverage" — vorher stand da "of them Aruba firmware". Dieselbe Zahl, nur zaehlt sie ab sofort auch die Cisco- und Extreme-Geraete mit.

Cisco IOS XE / IOS XR — exakt statt verglichen

Das ist der inhaltlich interessante Teil, und er funktioniert anders als alles andere im Dashboard: hier wird nicht verglichen, sondern nachgeschlagen.

Cisco veroeffentlicht fuer diese Produkte keine Ranges. Beide Quellen zaehlen die betroffenen Releases einzeln auf:

Quelle	CVE-2026-20267 (IOS XE Hardening, Aug 2026)
NVD	267 einzelne cpeMatch-Eintraege, exakt cpe:2.3:o:cisco:ios_xe:17.15.4c, nirgends ein versionStart/versionEnd
CVEListv5	268 blanke version-Eintraege, defaultStatus: unknown

"Betroffen" ist damit Mengenzugehoerigkeit. Vergleichen waere hier nicht ungenauer, sondern schlicht falsch: Cisco liefert 17.15.4, .4a, .4b, .4c und .4d als fuenf verschiedene Releases aus, und ein Record nennt einige davon und andere nicht — als Zahl gelesen sind alle fuenf (17,15,4). Ein Router auf 17.15.4c haette so jede CVE mitbekommen, die nur 17.15.4 nennt.

Drei Konsequenzen, die beim Testen auffallen werden:

• Es steht keine Fix-Version am Finding. Ein Cisco-Record listet, was kaputt ist, und sagt nichts darueber, was es nicht ist — die "fixed in 17.15.6" steht nur auf Ciscos Advisory-Seite, und die ist bewusst nicht angebunden (siehe unten). Das Finding hat trotzdem seinen Weg zurueck: sobald das Geraet auf ein Release geht, das der Record nicht auffuehrt, trifft nichts mehr und die Reconcile schliesst es.
• Ein nicht gelistetes Release wird nicht gemeldet. defaultStatus ist unknown, nicht unaffected — was Cisco nicht aufgezaehlt hat, hat Cisco nicht beurteilt, und das lesen wir als "kein Verdikt". Ein brandneuer Rebuild wird also eher zu wenig gemeldet als falsch. NVDs eigene CPE-Daten entscheiden das genauso.
• Gross-/Kleinschreibung und fuehrende Nullen sind egal. Cisco schreibt denselben Build als 17.09.05a und 17.9.5a, und 3.2.0SG heisst in der CPE 3.2.0sg. Beide Haelften normalisieren ueber dieselbe Funktion, damit sie nicht auseinanderlaufen.

Beide Quellen tragen, und keine ist ueberfluessig. Stand 08.09.2026: die IOS-XE-Charge (CVE-2026-20267…20273) ist bei NVD vollstaendig angereichert, waehrend die IOS-XR-Charge einen Monat spaeter (CVE-2026-20274…20280) dort noch auf "Awaiting Analysis" mit null CPE-Eintraegen steht und strukturiert nur in Ciscos eigenen Records existiert. Umgekehrt gibt es auch: CVE-2019-12660 schreibt sein betroffenes Release in den Produktnamen ("Cisco IOS XE Software 3.2.11aSG", Version "unspecified") — die kennt nur NVD.

Die Produkt-Anker sind hier wichtiger als irgendwo sonst: Cisco legt jedes Produkt unter einem Hersteller ab und schreibt sie als getrennte Bloecke in denselben Record. CVE-2025-20363 fuehrt fuenf davon — IOS (2005 Versionen), IOS XR (13), IOS XE (456), ASA (220) und Firepower (94). Lose gematcht bekaeme ein Router die Release-Liste einer Firewall.

Extreme Networks EXOS — gefloorte Ranges, und was ich NICHT pruefen konnte

Extreme ist von den dreien der einfache Fall: Versionen sind blanke Zahlen (31.7.2.4), und Extreme schreibt saubere Ranges — jede mit eigener Untergrenze. CVE-2026-8169 fuehrt vier davon in einem Record:

ab Version	betroffen bis unter
0	31.7.4
32.0.0	32.7.4.15
33.0.0	33.1.100
33.2.0	33.7.1

defaultStatus ist hier unaffected (anders als bei Cisco) — ein Release ausserhalb aller vier ist also eines, das Extreme geprueft und freigegeben hat. Der Aruba-Branch-Guard laeuft hier bewusst nicht mit: die erste Zeile mit der Untergrenze 0 ist Extremes eigene Aussage "alles unter 31.7.4, egal auf welcher Linie" — mit Branch-Guard waeren genau die alten Switche rausgefallen, um die es geht.

Beide Quellen, und hier traegt NVD die Hauptlast. Extremes eigene CNA meldet erst seit 2025. Alles davor — CVE-2023-43119/43120/43121 (Chalet: Directory Traversal und Rechteausweitung), CVE-2024-27453, CVE-2020-18305 — liegt in CVEListv5 nur als MITRE-Platzhalter mit vendor: "n/a", also voellig ohne strukturierte Daten. Umgekehrt standen CVE-2026-8169 und -8170 am 08.09.2026 bei NVD noch auf "Awaiting Analysis" mit null CPE-Eintraegen, waehrend Extremes Record die vier Ranges oben bereits sauber angab.

Dazu eine NVD-Eigenheit, die man kennen muss: dieselbe Firmware liegt dort unter zwei Produktnamen, und die CVEs sind auf beide verteilt. Beide werden abgefragt (live geprueft am 08.09.2026):

CPE	enthaelt
cpe:2.3:o:extremenetworks:extremexos	CVE-2024-27453, CVE-2020-18305, die 2017er-Charge
cpe:2.3:o:extremenetworks:exos	CVE-2023-43118…43121

Unter dem jeweils anderen Namen taucht davon nichts auf — mit nur einer der beiden CPEs waere die Haelfte unsichtbar geblieben.

Das ist der Teil, den ich nicht selbst verifizieren konnte — dafuer braucht es ein echtes Geraet. Laut SNMP::Info-Quellcode (Layer3::Extreme) meldet ein EXOS-Switch Hersteller extreme und OS-Slug xos, und die Version liest das Modul per /Version\s+([^ ]+)/i aus dem sysDescr. Genau darauf baut die Zuordnung auf. Falls eure Geraete etwas anderes melden, sagt der Test es sofort: Asset-OS steht dann nicht als ExtremeXOS da, sondern als roher Slug, und der Zaehler "on a firmware line with CVE coverage" zaehlt sie nicht mit.

Zwei Dinge werden dabei normalisiert, beide beim Einlesen: der ganze sysDescr-Satz, falls Netdisco ihn mitliefert (ExtremeXOS (X440G2-24t-10GE4) version 31.7.2.4 → 31.7.2.4), und der Patch-Anhang eines Patch-Builds (22.7.1.1-patch1-11 → 22.7.1.1). Den nennt keine der beiden Quellen je als Grenze — Extreme behebt diese Faelle ueber das Release der Obergrenze, nicht ueber einen Patch darunter.

Wie die Aruba-Erkennung entscheidet

Drei Aruba-Firmware-Linien, die HPE alle unter einem Hersteller ablegt und deren Nummern sich ueberschneiden:

Asset-OS	Firmware	Geraete
ArubaOS-CX	10.13.1005	6000/6300/8300
ArubaOS-Switch	16.11.0016	ProVision: 2530, 2930F, 3810, 5400R
ArubaOS	8.13.1.1 / 10.7.2.2	Mobility Controller / Gateways

Ein CX-Switch auf 10.13.1005 und ein Controller auf 10.7.2.2 sind beide "10.x" und haben sonst nichts gemeinsam — quer gematcht bekaeme der Switch ein Controller-Image als Empfehlung. Deshalb: jede Familie mit eigenem Schluessel, eigenem verankerten Produkt-Regex und eigener NVD-CPE. Welche Familie ein Netdisco-Geraet ist, muss aus drei Angaben zusammenpassen (SNMP-OS-Slug, Hersteller, Form der Versionsnummer) — sonst wird nichts behauptet. Fuer Cisco gilt dieselbe Dreier-Regel.

Dazu ein Branch-Guard: HPE schreibt pro Record eine Range je Release-Zweig (CVE-2026-73749 fuehrt 10.18, 10.17, 10.16, 10.13 und 10.10 nebeneinander), also muss ein Eintrag ohne eigene Untergrenze denselben Zweig (major.minor) haben wie die installierte Version.

Beide Quellen, wie ueberall hier: NVD hat brauchbare CPE-Ranges fuer die drei ArubaOS-Switch-CVEs von 2023, waehrend die aktuellen AOS-CX-Faelle (CVE-2026-73749, -44880) dort unangereichert liegen und nur als HPEs eigene CNA-Records existieren.

Die Buchstaben vor der Version sind egal — WC., YA., PL. benennen die Hardware-Linie, nicht die Version. Verglichen wird 16.11.0016; die Original-Zeichenkette steht in der Asset-Beschreibung, weil man genau die auf HPEs Download-Seite wiederfindet.

Bei Cisco ist es umgekehrt: die Buchstaben sind dort die Version. 17.15.4 und 17.15.4c sind zwei Releases, und genau deshalb wird bei Cisco exakt verglichen und bei Aruba numerisch.

Bewusst nicht drin

• Keine Hersteller-Bulletins. Weder HPEs eigene (hpesbnw*) noch Ciscos Security Advisories. Sie tragen dieselben CVEs, die die CNA-Records bereits strukturiert angeben. Bei Cisco haetten sie eine Sache mehr — die Fix-Version —, aber sec.cloudapps.cisco.com zu scrapen ist eine dritte Quelle mit eigenen Ausfallarten. Kommt rein, wenn die fehlende Fix-Version jemanden tatsaechlich blockiert.
• Kein EoL/EoM. Genau das waere fuer einen Switch die wichtigste Meldung — eine Firmware-Linie ohne Sicherheitspatches ist nicht mehr patchbar. Aber HPE veroeffentlicht diese Daten pro Hardware-Produkt im Support-Portal, nicht pro Firmware-Linie, und endoflife.date fuehrt ArubaOS ueberhaupt nicht. Ein erfundenes Datum wuerde echte Assets auf Verdacht stilllegen. Sobald es eine Quelle gibt, die EoM je OS-Release sagt, ist der Rest bereits da.
• Extremes Fabric Engine (VOSS) ist nicht dabei — und zwar aus einem Inventar-Grund, nicht aus Datenmangel. Die CVEs gibt es (CVE-2025-11192 hat sowohl CPE als auch CNA-Range). Aber SNMP::Info hat keine VOSS-Klasse: ein VSP wird als Layer3::Passport gefuehrt und meldet OS passport, Hersteller avaya — exakt dasselbe wie ein Avaya/Nortel-ERS-Switch, dessen 5.9.x-Firmware mit Fabric Engine nichts zu tun hat. Auf der Netdisco-Zeile unterscheidet die beiden nichts, und "vor 9.3" wuerde auf einen ERS mit 5.x losgelassen die komplette ERS-Flotte melden. Sobald sich die Zeilen unterscheiden lassen, sind es ein paar Zeilen Arbeit — sagt Bescheid, wenn ihr VSPs im Bestand habt.
• ExtremeWare (der alte Slug extremeware, Firmware bis 2010) ebenfalls nicht: andere Produktlinie, und NVDs Grenzen dafuer enden bei 11.1.
• Klassisches Cisco IOS (12.x/15.x) ist nicht dabei. Es nummeriert Releases als 15.2(7)E3; NVD maskiert die Klammern in der CPE, und kein Versionsschema hier liest das. So ein Geraet bekommt weiterhin Asset und OS-String (cisco ios) und kein CVE-Verdikt. IOS XE und IOS XR sind abgedeckt.
• Alles Uebrige (Cumulus, NX-OS, …) bekommt ebenfalls Asset und OS-String ohne CVE-Verdikt. Jede Familie braucht eigenes kuratiertes Matching; ein generischer Versionsvergleich ueber Hersteller hinweg ist genau die Art Scanner, die eine Seite voller falscher Findings produziert.
• "All versions"-Eintraege in den ArubaOS-Switch-Records werden nicht indiziert. Sie haben keine Obergrenze, lassen sich also weder vergleichen noch durch ein Update innerhalb des Zweigs schliessen — ein Finding ohne erreichbaren Fix ist Rauschen. Auf so einem Zweig wird eher zu wenig als falsch gemeldet.

Nebenbefunde, mitgefixt

Zweimal dieselbe Falle, einmal beim Aruba- und einmal beim Cisco-Update, jeweils einen Buchstaben weiter:

1. Die Apple-Muster matchten ios als Teilstring. Netdisco nennt die Firmware eines Cisco-Switches genau so ("ios", als Asset-OS "cisco ios") — jedes Cisco-Geraet im Bestand waere gegen Apples iPhone-Ranges geprueft worden, und IOS 15.2 liegt unter jeder iOS-Grenze, die je geschrieben wurde.
2. Und "os x" matchte als Teilstring in "cisco iOS XE" — da steht es drin: i-os -xe. Jeder Cisco-Router waere als Mac gelesen worden: gegen macOS-Ranges verglichen (17.15.4c liegt unter jeder macOS-26-Grenze, haette also getroffen) und gleichzeitig um seine eigenen Cisco-Findings gebracht, weil der Plattform-Filter sie als "falsche Plattform" verworfen haette.

Beide Muster sind jetzt verankert bzw. wortgrenzen-geprueft; iOS 18.1, iPadOS, iPhone OS, Mac OS X 10.15 und macOS 15.1 treffen weiterhin.

Nachtrag aus dem Test: Geraete ohne Namen, und der fehlende Quellfilter

Gemeldet mit Screenshot, drei Punkte, davon zwei derselbe Fehler.

Assets, die "10" oder "192" heissen. Nicht jedes Geraet antwortet Netdisco einen Namen — eine AudioCodes-Media-Gateway und ein LANCOM-Router im Testbestand tun es nicht. Der Sync faellt dann auf die kanonische IP zurueck, hat davon aber die Kurzform genommen, so wie er es bei einem FQDN tut (sw-12.example.local → sw-12). Auf einer Adresse angewandt bleibt davon das erste Oktett uebrig: 192. Ab sofort ist ein namenloses Geraet die volle IP-Adresse; eine Kurzform wird nur noch aus einem echten Geraetenamen gebildet.

Und deshalb auch die vermischte Zeile. Der abgeschnittene Name war nicht nur haesslich, er war ein Suchschluessel: das zweite namenlose Geraet im selben /8 fand ueber hostname = "192" das Asset des ersten und wurde daraufgeschrieben. Im Screenshot deshalb ein Asset mit LANCOM als Hersteller und der Firmware 5.4.2.30 eines netgear-Switches — zwei Geraete, eine Zeile. Mit dem vollen Namen kann das nicht mehr passieren, jede Adresse ist eindeutig.

Die bereits falsch angelegten Assets muessen nicht von Hand aufgeraeumt werden: heisst ein Asset genau wie das erste Oktett der IP, an die es gepinnt ist, benennt der naechste Sync es auf die volle Adresse um. Das Geraet, das den Pin nicht haelt, bekommt dabei sein eigenes Asset. Eine falsche os_version auf dem geheilten Asset bleibt allerdings stehen, bis dessen eigenes Geraet wieder eine Version liefert — ein leerer Wert ueberschreibt nie einen vorhandenen. Wem das zu langsam ist: die beiden Zeilen einmal loeschen, der naechste Sync legt sie sauber neu an.

Netdisco fehlte im Quellfilter ueber der Inventarliste (und damit im CSV-Export, der genau diesen Filter mitnimmt). Ist jetzt drin. Der Filter geht dabei ueber die Pin-Spalte, nicht ueber die Quelle, unter der ein Asset einmal angelegt wurde — sonst faellt jeder Switch raus, den Wazuh oder Nessus zuerst gesehen hat. Nebenbei: dieselben Switche tauchten vorher unter "Manual" auf, weil sie keine der abgefragten Scanner-Verknuepfungen hatten. Auch das stimmt jetzt.

Vor dem Testen: einmal den CVE-Index bauen lassen

Der cvelistV5-Index hat eine neue Version (v34, wegen der Extreme-Produkte — vorher v33 fuer Cisco). Der erste "Sync now" direkt nach dem Update findet ihn noch nicht und macht dann nur die NVD-Haelfte — im Log steht dann "no cvelistV5 index yet — CVE pass deferred to the nightly app-CVE scan".

Praktisch heisst das: IOS-XE-Findings und die aelteren EXOS-Findings kommen sofort (NVD hat die Daten), IOS-XR und die EXOS-CVEs von 2026 erst nach dem Indexbau (NVD hat dort nichts). Entweder eine Nacht warten (01:30 UTC) oder den App-CVE-Scan einmal von Hand anstossen, der baut den Index selbst:

curl -X POST -H "Authorization: Bearer $TOKEN" \
  "http://localhost:8000/api/v1/vulnerabilities/app-cve-scan"

Bitte testen

1. Verbindung, drei Varianten. (a) Demo-Instanz ohne Zugangsdaten (netdisco-demo-jyxhs.ondigitalocean.app, Port 443, HTTPS an) → Test meldet 6 devices. (b) Eigene Instanz mit API-Key ueber HTTP:5000. (c) Falls vorhanden: hinter Reverse-Proxy mit HTTPS. Erwartung jeweils: Geraetezahl und wie viele davon auf einer Firmware-Linie mit CVE-Abdeckung liegen.
2. Falscher Key. Key verstellen → Test meldet klar "rejected (HTTP 401/403)" bzw. bei einer Login-Seite mit HTTP 200 "no JSON (a login page, most likely)" — nicht "0 Geraete".
3. Erster Sync. "Sync now" → Assets erscheinen im Inventar, Quelle NETDISCO, mit Standort, Modell und Firmware in der Beschreibung.
4. Die vier Aruba-Switche. Erwartung: der CX auf PL.10.13.1005 bekommt zwei Findings (CVE-2026-73749 und -44880, jeweils mit dem Fix des 10.13-Zweigs, nicht dem von 10.17); der CX auf PL.10.08.1010 bleibt sauber (kein Record fuehrt einen 10.08-Zweig); beide ProVision-Switche (WC.16.11.0016, YA.16.11.0027) bleiben sauber, weil sie ueber den 16.11-Grenzen liegen.
5. Der Cisco-Router. Das Testgeraet (C1121X-8PLTEP, ios-xe, 17.15.4c): Asset-OS steht als Cisco IOS XE da (nicht als ios-xe), Version 17.15.4c. Erwartete Findings: CVE-2026-20267 bis -20273 (die Hardening-Charge vom August) plus CVE-2019-12660 und CVE-2025-20363. Ohne Fix-Version — das ist so gewollt, siehe oben.
6. Der exakte Match, der eigentliche Punkt. Wenn moeglich ein zweites IOS-XE-Geraet auf einem anderen Rebuild derselben Zeile (z. B. 17.15.4 oder 17.15.4a) gegenpruefen: die Finding-Listen der beiden Geraete duerfen sich unterscheiden. Wenn beide identisch sind, obwohl die Releases verschieden sind, stimmt etwas nicht.
7. Firmware hochziehen. Einen betroffenen Switch oder Router aktualisieren (Cisco: auf ein Release, das in den Records nicht auftaucht, etwa 17.15.6), Sync → das Finding schliesst sich von selbst (Change History: "at/past the fix"). Das ist der Punkt, an dem sich zeigt, ob die Erkennung einen Weg zurueck hat.
8. Klassisches IOS und der Rest. Ein Geraet mit OS-Slug ios (12.x/15.x): Asset ja, OS cisco ios, aber keine Findings — und vor allem keine Apple- oder macOS-CVEs. Dasselbe fuer Cumulus & Co.
9. Keine macOS-CVEs auf Netzwerkgeraeten. Explizit gegenpruefen: auf keinem Cisco IOS XE- oder Cisco IOS XR-Asset darf eine macOS- oder iOS-CVE stehen. Das ist der Nebenbefund von oben.
10. Die Extreme-Switche — und zuerst: kommt die Zeile ueberhaupt richtig an? Nach dem Sync ein EXOS-Geraet im Inventar aufmachen. Erwartung: Asset-OS steht als ExtremeXOS da (nicht als xos oder extreme xos) und die Version als blanke Zahl (31.7.2.4; bei einem Patch-Build 22.7.1.1 statt 22.7.1.1-patch1-11). Steht dort etwas anderes, meldet euer Netdisco andere Slugs als angenommen — dann bitte die Zeile aus dem deviceinventory-Report schicken (vendor, os, version), das ist dann ein Zweizeiler.
11. Die EXOS-Findings. Ein Switch unterhalb der Grenzen (alles unter 31.7.4, oder 32.x unter 32.7.4.15) bekommt CVE-2026-8169 und CVE-2026-8170, beide mit Fix-Version — anders als bei Cisco, hier gibt Extreme sie an. Aeltere Stände zusaetzlich aus der NVD-Haelfte: ein Switch auf 22.6 etwa CVE-2023-43119/43120/43121, CVE-2024-27453 und CVE-2020-18305. Ein Switch auf 31.7.4 oder neuer bleibt bei den 2026ern sauber.
12. Ein VSP mit VOSS / ein Avaya-ERS, falls vorhanden: Asset ja, OS avaya passport, keine Findings. Das ist Absicht (siehe "Bewusst nicht drin") — wichtig ist vor allem, dass dort nichts Falsches auftaucht.
13. Umbenennen. Einen Switch in Netdisco umbenennen, Sync → dasselbe Asset uebernimmt den neuen Namen, es entsteht kein zweites.
14. Entfernen. Ein Geraet aus Netdisco loeschen, Sync → Asset wird inactive (mit Audit-Eintrag), nicht geloescht. Ein nur ausgeschalteter oder gerade nicht erreichbarer Switch bleibt active, solange Netdisco ihn noch fuehrt.
15. Ledger. Scan Jobs → der Lauf steht als netdisco drin, mit Statistik und im Fehlerfall als failed samt Mail. Hinweis: Laeufe von vor diesem Update zeigen in der Historie 0 bei "with firmware CVE coverage" — der Zaehler wurde umbenannt, alte Eintraege haben den alten Schluessel. Ab dem naechsten Sync stimmt die Zahl wieder.
16. Ohne Netdisco pruefbar (Regeln offline):

    venv/bin/python tests/test_aruba_firmware.py
    venv/bin/python tests/test_cisco_firmware.py
    venv/bin/python tests/test_extreme_firmware.py
    venv/bin/python tests/test_netdisco_inventory.py
    venv/bin/python tests/test_netdisco_nameless_device.py
    

17. Ein Geraet ohne Namen. Falls im Bestand: Asset heisst jetzt nach der vollen IP (192.168.1.6), nicht 192. Zwei namenlose Geraete = zwei Assets, jedes mit seinem eigenen Hersteller und seiner eigenen Firmware. Die alten 10/192-Zeilen aus dem letzten Test: einmal syncen, dann schauen, ob sie den vollen Namen tragen.
18. Quellfilter und Export. Inventar → Filter auf Netdisco: es kommen genau die Netdisco-Geraete, auch die, die Wazuh oder Nessus zuerst registriert hat. "Export CSV" bei gesetztem Filter enthaelt dieselbe Menge. Und: unter Manual darf jetzt kein Switch mehr stehen.