feat(triage): add the per-unit kernel posture table #19

Merged

Philipp Baumann merged 2 commits from fm/dse-security-reports-kernel-table into main

2026-10-28 06:49:59 +00:00

Philipp Baumann commented

2026-10-28 06:35:42 +00:00

Owner

Summary

The kernel reboot question was answered only in prose (the P4/P15 ranking statements); this change adds a generated table section "Kernel-Posture der Einheiten" to the triage report that answers it per unit.
One row per unit (same machine union and ordering as the Evidenzabdeckung table): the running kernel (uname -r) with its Trivy fix status, the retained non-running kernel inventory (dnf installonly_limit), which retained versions Trivy marks vulnerable, and whether a reboot is pending.
No derivation change was needed: the derived payload already exposes the complete kernel block per evidence unit (running, installed, vulnerableInstalled, rebootPending, runningFixed, runningVulnerable), confirmed against the published 2026-10-27 cache, and the table renders purely from it.

What changed

reports/defender-triage.typ — new table section "Kernel-Posture der Einheiten" plus render helpers (kernelPkgVr, kernelRetainedVrs, kernelFixStatusCell, kernelRebootCell), a documenting bullet in Grundlagen und Methode, and the table inventory in the file header comment.
AGENTS.md — the triage-report entry now lists the kernel-posture table and records that it renders from the existing kernel block with no derivation change of its own.

Behaviour change

Units without kernel evidence (the three Windows servers) show a named gap row ("keine SSH-Evidenz (Windows)"), never a blank or zero cell; on the 2026-10-27 round all eight Linux evidence units render data: the four el9 units run 5.14.0-687.60.1.el9_8 (retained 687.58.1/687.59.1, of which 687.58.1 vulnerable, no reboot pending) and the four el10 units run 6.12.0-211.68.1.el10_2 (retained 211.66.1/211.67.1, both vulnerable, no reboot pending).
The standard report is untouched and stays byte-identical.

Notes for the captain

ASP-DSE-PROD-WIREGUARD does carry full kernel evidence in the current round, so it renders with data, not with the gap this task brief anticipated.
P15 prose conflict (deliberately not edited, per the task brief): the P15 el9 paragraph still says Trivy finds its kernel CVEs against installed kernels 687.57.1 and 687.58.1 and that "mindestens eine Maschine hält noch 687.57.1 im Bestand", but the derived kernel posture of the 2026-10-27 round shows 687.57.1 no longer installed anywhere in the fleet (el9 retained inventory is 687.58.1/687.59.1, running 687.60.1, which matches what the new table shows). The wording of that paragraph is the captain's open decision (P15).

Validation

Synthetic lane: just all, just repro (byte-identical PDFs), just py-crosscheck (both derivation lanes byte-identical), just test (33 passed) — all green.
Real round restored from the published caches (derived-/evidence-/scans-/sbom-/network-2026-10-27, defender-config-2026-10-27.json, systems-az.json, samples/triage.csv), both reports re-rendered without re-collecting evidence or re-running the scanner; the standard report renders byte-identical to the published 2026-10-27 PDF, so no number moved.
Republished: the new defender-findings-2026-10-27.pdf and defender-triage-2026-10-27.pdf are in the artifacts dir, the previous copies were moved to artifacts/superseded/ (suffixed -1839 to keep the earlier superseded generation), and the 2026-10-26 PDFs are untouched.

Instructions-PR: none

## Summary The kernel reboot question was answered only in prose (the P4/P15 ranking statements); this change adds a generated table section "Kernel-Posture der Einheiten" to the triage report that answers it per unit. One row per unit (same machine union and ordering as the Evidenzabdeckung table): the running kernel (`uname -r`) with its Trivy fix status, the retained non-running kernel inventory (dnf `installonly_limit`), which retained versions Trivy marks vulnerable, and whether a reboot is pending. No derivation change was needed: the derived payload already exposes the complete `kernel` block per evidence unit (`running`, `installed`, `vulnerableInstalled`, `rebootPending`, `runningFixed`, `runningVulnerable`), confirmed against the published 2026-10-27 cache, and the table renders purely from it. ## What changed - `reports/defender-triage.typ` — new table section "Kernel-Posture der Einheiten" plus render helpers (`kernelPkgVr`, `kernelRetainedVrs`, `kernelFixStatusCell`, `kernelRebootCell`), a documenting bullet in Grundlagen und Methode, and the table inventory in the file header comment. - `AGENTS.md` — the triage-report entry now lists the kernel-posture table and records that it renders from the existing kernel block with no derivation change of its own. ## Behaviour change Units without kernel evidence (the three Windows servers) show a named gap row ("keine SSH-Evidenz (Windows)"), never a blank or zero cell; on the 2026-10-27 round all eight Linux evidence units render data: the four el9 units run 5.14.0-687.60.1.el9_8 (retained 687.58.1/687.59.1, of which 687.58.1 vulnerable, no reboot pending) and the four el10 units run 6.12.0-211.68.1.el10_2 (retained 211.66.1/211.67.1, both vulnerable, no reboot pending). The standard report is untouched and stays byte-identical. ## Notes for the captain - ASP-DSE-PROD-WIREGUARD does carry full kernel evidence in the current round, so it renders with data, not with the gap this task brief anticipated. - P15 prose conflict (deliberately not edited, per the task brief): the P15 el9 paragraph still says Trivy finds its kernel CVEs against installed kernels 687.57.1 and 687.58.1 and that "mindestens eine Maschine hält noch 687.57.1 im Bestand", but the derived kernel posture of the 2026-10-27 round shows 687.57.1 no longer installed anywhere in the fleet (el9 retained inventory is 687.58.1/687.59.1, running 687.60.1, which matches what the new table shows). The wording of that paragraph is the captain's open decision (P15). ## Validation - Synthetic lane: `just all`, `just repro` (byte-identical PDFs), `just py-crosscheck` (both derivation lanes byte-identical), `just test` (33 passed) — all green. - Real round restored from the published caches (`derived-/evidence-/scans-/sbom-/network-2026-10-27`, `defender-config-2026-10-27.json`, `systems-az.json`, `samples/triage.csv`), both reports re-rendered without re-collecting evidence or re-running the scanner; the standard report renders byte-identical to the published 2026-10-27 PDF, so no number moved. - Republished: the new `defender-findings-2026-10-27.pdf` and `defender-triage-2026-10-27.pdf` are in the artifacts dir, the previous copies were moved to `artifacts/superseded/` (suffixed `-1839` to keep the earlier superseded generation), and the 2026-10-26 PDFs are untouched. Instructions-PR: none

Philipp Baumann added 1 commit

2026-10-28 06:35:42 +00:00

feat(triage): add the per-unit kernel posture table 79df1facdf

This change will add a data-driven table section "Kernel-Posture der
Einheiten" to the triage report rendering, per unit, the running kernel
(uname -r) with its Trivy fix status, the retained non-running kernel
inventory (dnf installonly_limit), which retained versions Trivy marks
vulnerable, and whether a reboot is pending.

This change will render the table purely from the existing per-evidence-
unit kernel block of the derived payload (running/installed/
vulnerableInstalled/rebootPending/runningFixed) -- no derivation change,
both lanes stay byte-identical.

This change will show units without kernel evidence (the three Windows
servers) as named gaps, never as blank or zero cells, and document the
new generated table in AGENTS.md.

Philipp Baumann added 1 commit

2026-10-28 06:49:53 +00:00

Merge branch 'main' into fm/dse-security-reports-kernel-table 713cee0c6d

Philipp Baumann merged commit ee4168e104 into main

2026-10-28 06:49:59 +00:00

Philipp Baumann referenced this pull request from a commit

2026-10-28 06:50:00 +00:00

feat(triage): add the per-unit kernel posture table (#19)

Philipp Baumann deleted branch fm/dse-security-reports-kernel-table

2026-10-28 06:50:02 +00:00