docs(triage): explain the WireGuard zero-row result and its risk profile #26

Merged

Philipp Baumann merged 1 commit from fm/dse-security-reports-explain-empty-export into main

2026-10-28 12:20:00 +00:00

Philipp Baumann commented

2026-10-28 12:19:12 +00:00

Owner

Summary

The report warns everywhere that a blank cell reads as clean, but the one unit with an empty result - ASP-DSE-PROD-WIREGUARD, zero rows in both Defender exports - was never fully explained, leaving exactly the misreading the report warns about. This folds the explanation into the existing sections (no new section): the unit's role, the explicit absence of the Python stack that dominates the estate's findings, the shared el9 kernel leftovers, the TCP-only boundary of the reachability probe against the unit's UDP tunnel, and the corrected zero-row framing in the findings report.

What changed

reports/defender-triage.typ (Systemlandkarte): state the unit's role where it is introduced - network service host, not an application host: the evidence RPM inventory carries wireguard-tools and dnsmasq (tunnel terminator, resolver software), and its failure or compromise hits the connections running through it, a different impact profile than a workbench.
reports/defender-triage.typ (Defender-Sensor je Einheit): make the no-Python-stack point explicit - the pip probe has zero hits for pyjwt, anyio, h11 and pillow, the four libraries that carry all twelve PROD-WORKBENCH rows, so the dominant finding class cannot arise on this host; keep the shared el9 kernel leftovers visible (running 5.14.0-687.60.1, retained 687.58.1 and 687.59.1, Defender silent on kernel findings for all four el9 units) - no rows and no kernel exposure are not the same statement - and note that the same kernel exposure weighs differently on a tunnel terminator.
reports/defender-triage.typ (Netzwerk-Reichweite): state the probe boundary - the port probe is TCP-only, the unit's own service is UDP by protocol design and can never answer a TCP connect, so the probe says nothing about tunnel reachability; that is a boundary of the measurement, not a finding about the service.
reports/defender-findings.typ: align the zero-row framing with the corrected reading of the triage report - units with evidence but zero export rows hold nothing above the export threshold (critical / CVSS above 9.5), which is not missing coverage, but zero rows are still never a clean finding (fixed in both places that carried the old "Abdeckungsluecke des Exports" wording, lines ~154 and ~250).

Behaviour change

Text-only change to the two report templates; no derivation, evidence or cache change. Rendered PDFs now explain the WireGuard empty result at its introduction point and in the sensor section, state the UDP/TCP probe boundary, and the findings report no longer frames zero-row units as export coverage gaps.

Notes for the captain (facts not yet machine-readable)

The role specifics beyond the RPM inventory - that the unit is the DNS resolver for 10.15.5.0/24, the only listener on that address serving dnsmasq on UDP and TCP 53, and that the tunnel on UDP 51820 carries that whole subnet - are verified read-only on 2026-10-28 but are not machine-readable in any cache or derived payload, and config/systems.json carries an empty role for this unit. The prose therefore stays at the cache-backed level (wireguard-tools + dnsmasq installed, tunnel UDP by design). To state the subnet-chokepoint specifics in the report, either the evidence probe needs a listener/subnet extension or the committed role baseline needs an entry.
Observation kept out of scope: the pre-existing sentence "die Trivy-only-Funde dort sind durchgehend mittelschwer" (kept verbatim, captain's wording) reads broadly, while the derived trivy-only payload for this unit also carries HIGH-severity rows (461 of 866 rows, 143 of 277 unique CVEs - e.g. grub2 CVE-2021-3695, openssl and kernel CVEs). The two CVEs named in the dispatch (CVE-2021-25220 on the bind/dhcp packages, CVE-2021-3507 on qemu-guest-agent) are indeed MEDIUM. Flagging this in case the "durchgehend mittelschwer" wording should be scoped.

Validation

just all, just repro (byte-identical both PDFs), just test (39 passed), just lint, just py-crosscheck (stdlib vs polars byte-identical) on the synthetic fixture lane.
Real 2026-10-28 round restored and re-rendered (just ingest, real triage.csv sidecar re-copied before the final derive), new sentences verified present in both rendered PDFs; artifacts republished, previous copies moved to artifacts/superseded/, the 2026-10-26 set untouched.

Instructions-PR: none

## Summary The report warns everywhere that a blank cell reads as clean, but the one unit with an empty result - ASP-DSE-PROD-WIREGUARD, zero rows in both Defender exports - was never fully explained, leaving exactly the misreading the report warns about. This folds the explanation into the existing sections (no new section): the unit's role, the explicit absence of the Python stack that dominates the estate's findings, the shared el9 kernel leftovers, the TCP-only boundary of the reachability probe against the unit's UDP tunnel, and the corrected zero-row framing in the findings report. ## What changed - `reports/defender-triage.typ` (Systemlandkarte): state the unit's role where it is introduced - network service host, not an application host: the evidence RPM inventory carries `wireguard-tools` and `dnsmasq` (tunnel terminator, resolver software), and its failure or compromise hits the connections running through it, a different impact profile than a workbench. - `reports/defender-triage.typ` (Defender-Sensor je Einheit): make the no-Python-stack point explicit - the pip probe has zero hits for pyjwt, anyio, h11 and pillow, the four libraries that carry all twelve PROD-WORKBENCH rows, so the dominant finding class cannot arise on this host; keep the shared el9 kernel leftovers visible (running 5.14.0-687.60.1, retained 687.58.1 and 687.59.1, Defender silent on kernel findings for all four el9 units) - no rows and no kernel exposure are not the same statement - and note that the same kernel exposure weighs differently on a tunnel terminator. - `reports/defender-triage.typ` (Netzwerk-Reichweite): state the probe boundary - the port probe is TCP-only, the unit's own service is UDP by protocol design and can never answer a TCP connect, so the probe says nothing about tunnel reachability; that is a boundary of the measurement, not a finding about the service. - `reports/defender-findings.typ`: align the zero-row framing with the corrected reading of the triage report - units with evidence but zero export rows hold nothing above the export threshold (critical / CVSS above 9.5), which is not missing coverage, but zero rows are still never a clean finding (fixed in both places that carried the old "Abdeckungsluecke des Exports" wording, lines ~154 and ~250). ## Behaviour change Text-only change to the two report templates; no derivation, evidence or cache change. Rendered PDFs now explain the WireGuard empty result at its introduction point and in the sensor section, state the UDP/TCP probe boundary, and the findings report no longer frames zero-row units as export coverage gaps. ## Notes for the captain (facts not yet machine-readable) - The role specifics beyond the RPM inventory - that the unit is the DNS resolver for 10.15.5.0/24, the only listener on that address serving dnsmasq on UDP and TCP 53, and that the tunnel on UDP 51820 carries that whole subnet - are verified read-only on 2026-10-28 but are not machine-readable in any cache or derived payload, and `config/systems.json` carries an empty `role` for this unit. The prose therefore stays at the cache-backed level (wireguard-tools + dnsmasq installed, tunnel UDP by design). To state the subnet-chokepoint specifics in the report, either the evidence probe needs a listener/subnet extension or the committed `role` baseline needs an entry. - Observation kept out of scope: the pre-existing sentence "die Trivy-only-Funde dort sind durchgehend mittelschwer" (kept verbatim, captain's wording) reads broadly, while the derived trivy-only payload for this unit also carries HIGH-severity rows (461 of 866 rows, 143 of 277 unique CVEs - e.g. grub2 CVE-2021-3695, openssl and kernel CVEs). The two CVEs named in the dispatch (CVE-2021-25220 on the bind/dhcp packages, CVE-2021-3507 on qemu-guest-agent) are indeed MEDIUM. Flagging this in case the "durchgehend mittelschwer" wording should be scoped. ## Validation - `just all`, `just repro` (byte-identical both PDFs), `just test` (39 passed), `just lint`, `just py-crosscheck` (stdlib vs polars byte-identical) on the synthetic fixture lane. - Real 2026-10-28 round restored and re-rendered (`just ingest`, real `triage.csv` sidecar re-copied before the final derive), new sentences verified present in both rendered PDFs; artifacts republished, previous copies moved to `artifacts/superseded/`, the 2026-10-26 set untouched. Instructions-PR: none

Philipp Baumann added 1 commit

2026-10-28 12:19:12 +00:00

docs(triage): explain the WireGuard zero-row result and its risk profile 6064c2233a

- State the unit's role where it is introduced in the Systemlandkarte:
  network service host (wireguard-tools, dnsmasq in the RPM inventory),
  not an application host, with a different impact profile than a
  workbench.
- Make the no-Python-stack point explicit in the mdatp health section:
  the four libraries carrying all twelve PROD-WORKBENCH rows have zero
  hits in this unit's evidence, so the dominant finding class cannot
  arise on it.
- Keep the shared el9 kernel leftovers visible: no rows and no kernel
  exposure are not the same statement, and the same kernel exposure
  weighs differently on a tunnel terminator.
- State the TCP-only boundary of the reachability probe: the tunnel is
  UDP by protocol design, so the probe says nothing about its
  reachability - a measurement boundary, not a service finding.
- Align defender-findings.typ with the corrected reading: units with
  evidence but zero export rows hold nothing above the export
  threshold; that is not missing coverage, but zero rows are never a
  clean finding.

Philipp Baumann merged commit 1112aabc09 into main

2026-10-28 12:20:00 +00:00

Philipp Baumann deleted branch fm/dse-security-reports-explain-empty-export

2026-10-28 12:20:00 +00:00

Philipp Baumann referenced this pull request from a commit

2026-10-28 12:20:02 +00:00

docs(triage): explain the WireGuard zero-row result and its risk profile (#26)