Beide Fassungen. Der Punkt, der oben steht und nicht im Nebensatz: ob Netdisco
die EXOS-Zeile so ausliest, wie die Zuordnung es annimmt (vendor "extreme", os
"xos", Version aus dem sysDescr), ist von hier aus nicht pruefbar - das braucht
ein echtes Geraet. Der Testertext sagt das ausdruecklich, nennt die Herkunft
der Annahme (SNMP::Info Layer3::Extreme) und macht daraus einen konkreten
Handgriff: Asset-OS muss "ExtremeXOS" heissen und die Version blank sein, sonst
die deviceinventory-Zeile schicken. Sonst sieht "keine Findings" aus wie
"sauber".
Dazu die zwei Dinge, die beim Testen sonst als Fehler gelesen wuerden: dass
Extreme im Gegensatz zu Cisco eine Fix-Version angibt (verglichen statt exakt
nachgeschlagen), und dass die alten EXOS-CVEs sofort kommen, die 2026er aber
erst nach dem Indexbau - NVD hat fuer die noch keine CPE-Eintraege.
VOSS/ERS steht als eigener Pruefpunkt drin, nicht nur unter "bewusst nicht
drin": dort kann nur etwas FALSCHES auftauchen, und genau das soll jemand mit
echten Geraeten gegenpruefen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Beide Fassungen auf den Cisco-Stand gezogen: warum bei IOS XE/XR exakt
nachgeschlagen statt verglichen wird (beide Quellen zaehlen die Releases
einzeln auf, 267 bzw. 268 fuer CVE-2026-20267), was daraus folgt (keine
Fix-Version am Finding, ein nicht gelistetes Release wird nicht gemeldet),
warum klassisches IOS draussen bleibt, der "os x"-Nebenbefund, und der
Hinweis auf den Indexbau — v33 heisst, dass der erste Sync nur die
NVD-Haelfte macht, was bei IOS XR sichtbar ist und bei IOS XE nicht.
Testpunkte auf 13 erweitert: der Router aus dem Feldbericht mit seiner
erwarteten CVE-Liste, ein Gegentest auf einem anderen Rebuild derselben
Zeile (die Listen muessen sich unterscheiden), keine macOS-CVEs auf
Netzwerkgeraeten, und die dritte Offline-Suite.
Keine neue Migration — 052 bleibt head; steht jetzt oben, damit niemand
danach sucht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
entrypoint.sh migriert bei jedem Containerstart. Ein manuelles
"alembic upgrade head" unmittelbar danach laeuft gegen denselben Schritt:
beide lesen 050, einer schreibt 051, der andere findet beim UPDATE auf
alembic_version keine Zeile mehr und bricht mit "expected to match one row"
ab — obwohl die Migration angewandt ist. Anleitung prueft jetzt mit
"alembic current" statt nochmal zu migrieren.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Beide Fassungen auf das aktuelle Update gezogen: was die Karte kann, welche
drei Aruba-Familien erkannt werden und warum sie getrennt bleiben muessen,
was bewusst fehlt (Bulletins, EoM, Nicht-Aruba), der Apple-"ios"-Nebenbefund,
und neun Testpunkte samt der beiden Offline-Suites.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Field report 06.09.2026: two hosts in Intune AND Defender TVM, no Wazuh agent.
Defender saw the Microsoft Edge update and closed a dozen Edge CVEs at 02:10
("device remediated"). At 03:20 the app-CVE scan pulled those hosts' inventory
— Intune detectedApps, which had not caught up and still listed Edge
132.0.6199.32 — and the MSRC fixed-build pass it drives reopened every one of
them. Edge was really at 132.0.6199.62. Next night the same, until Intune
caught up: a change history describing our polling, not the host.
The brake existed. reopen_if_patched already refuses a reopen whose data is
older than the close — but the grace was keyed on the SCANNER, and 'app_scan'
and 'msrc' sat there as "reads a live inventory". That holds on a Wazuh host.
On an Intune host both read the one list already known to lag: they fetch
nothing themselves, they decide from whatever run_app_cve_scan handed them, and
by the time the decision is made the provenance was gone.
Key the grace on the INVENTORY instead. A scan declares whose list it is
deciding from (audit_events.scanning_inventory / use_inventory), and the two
relaying scanners inherit that lag; every other source keeps its own. The
Wazuh-login-refused fall-through, where Intune answered for a Wazuh host, is
covered by the same declaration — it used to count as live.
The numbers were also backwards: Intune stood at 1 day and Defender at 3.
detectedApps depends on the tenant's refresh policy and is routinely a week
behind, while the Defender software list follows device telemetry (the reason
defender_service feeds it to the app scan in the first place). So Intune goes
to 7 days, m365_check with it — same Graph list — and the Defender software
list declares no lag at all; the 3 days under "defender" describe the TVM CVE
feed and stay there.
Deliberately not done: letting Defender TVM override the app scan outright.
"Defender reports nothing" is not "the host is patched" — for software Defender
does not inventory, or a device that stopped reporting, that would bury a
genuine MSRC finding for good, and for Edge MSRC is the only machine-readable
source there is. Past its lag the reopen goes through, so a host that really
regressed still resurfaces. Nothing about how inventories are fetched changed.
Test: tests/test_reopen_stale_inventory.py — the field case, the reopen after
the lag, and a control that a Wazuh host keeps its immediate say.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Field report 06.09.2026, asset 36: the Wazuh API was dead — the Asset view
could not fetch that host's software inventory at all — and an app-CVE scan
started anyway closed exactly two CVEs on it as "App CVE scan no longer
detects this CVE". Nothing had been patched; the asset was ACTIVE, and the
next scan after Wazuh came back reopened both.
The auto-resolve guard asked only whether `packages` was non-empty, never
where the list came from. The inventory pick is
if asset.wazuh_agent_id and wazuh: ... else: intune detectedApps
and that host is registered in both. With the Wazuh login refused, the scan
fell through to Intune's detectedApps — a thinner list with different product
names that does not carry everything syscollector reports. Non-empty, so the
guard passed, and every product Intune does not list read as "no longer
detected". Only that one host, because every other one is Wazuh-only and got
no list at all.
Same shape for browser extensions: they come from the indexer, and a failed
fetch returned [] — "this host has no extensions" — so the reconcile closed
extension findings against a list that cannot contain them.
Track, per asset, which source OWNS the inventory and which one ANSWERED. A
mismatch (or a failed extension fetch) closes and prunes nothing, for the
app-scan reconcile and the MSRC package reconcile alike; detection still runs,
since a product Intune reports really is installed — only retracting needs the
host's own, whole inventory. The Wazuh client now separates a missing IT
Hygiene index (404 → [], as before, for < 4.14) from an unreachable indexer,
which raises.
Test: tests/test_partial_inventory_no_autoclose.py — the field case, the
extension case, and a control that a healthy inventory still closes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
vulncheckandClaude Opus 5