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

```bash
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:

```bash
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):
    ```bash
    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.