From 27c3579743cbef9a48ebb276fddb37c3026ef87f Mon Sep 17 00:00:00 2001 From: Thore Cimbal Date: Fri, 21 Aug 2026 12:00:00 +0000 Subject: [PATCH] =?UTF-8?q?docs:=20Gate=201=20decided=20for=20#0051=20?= =?UTF-8?q?=E2=80=94=20and=20Authentik=20measured=20before=20touching=20it?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two decisions from sorb: narrow the target set to what is actually operated rather than tidying the registry, and start with Authentik. The narrowing stays derived — a registry repository counts only while one of its tags is running, which drops the two build artefacts and 61 of the 62 critical findings with them, without turning the target set back into something anyone maintains. Scanning the target image before upgrading turns a guess into a number. The running 2026.2.3 carries 27 critical and 477 high; 2026.8.0 carries 5 and 21. One upgrade removes twelve percent of all critical findings in running images and seventeen percent of the high ones — the largest single lever in the backlog. What remains is perl-base and libxml2, neither of which has a fix. A correction travels with it. I claimed Authentik's backup had never been restored because the monthly drill does not carry it. #0030 did restore it, 325,149 rows, and its exclusion from the automated run is a reasoned decision written into the manifest. Partial measurement, then assertion — the same class of error as that morning. --- STATUS.md | 2 +- docs/design/2026-08-21-cve-remediation.md | 64 ++++++++++++++++++++++- 2 files changed, 64 insertions(+), 2 deletions(-) diff --git a/STATUS.md b/STATUS.md index d7ff388..d89ab3f 100644 --- a/STATUS.md +++ b/STATUS.md @@ -86,7 +86,7 @@ Bedeutung der Meilensteine: siehe [roadmap.md](roadmap.md). | Design | Gate | Title | |---|---|---| -| [2026-08-21-cve-remediation](docs/design/2026-08-21-cve-remediation.md) | gate-1 | Design: Den CVE-Bestand abarbeiten (#0051) | +| [2026-08-21-cve-remediation](docs/design/2026-08-21-cve-remediation.md) | gate-2 | Design: Den CVE-Bestand abarbeiten (#0051) | ## ADRs (27) diff --git a/docs/design/2026-08-21-cve-remediation.md b/docs/design/2026-08-21-cve-remediation.md index bccc08b..31b712f 100644 --- a/docs/design/2026-08-21-cve-remediation.md +++ b/docs/design/2026-08-21-cve-remediation.md @@ -1,6 +1,6 @@ --- type: design -status: gate-1 +status: gate-2 date: 2026-08-21 size: L related: @@ -116,3 +116,65 @@ Kein UI-Anteil; das Ergebnis ist im bestehenden Dashboard *Security / CVE-Übersicht* ablesbar. > **STOP — Freigabe für Gate 1.** + +> **Gate 1 freigegeben durch sorb, 2026-08-21**, mit zwei Entscheidungen: +> +> 1. **Haufen C:** Zielmenge auf das einengen, was **wirklich betrieben wird** — +> nicht Registry aufräumen (also gegen meine Empfehlung). +> 2. **Begonnen wird mit Authentik.** + +### Nachtrag zu Gate 1 — wie Haufen C ohne neue Pflegeliste eingeengt wird + +Die Einengung darf die Zielmenge nicht wieder zu etwas machen, das jemand +pflegt (ADR-0026). Ableitbar ist sie trotzdem: + +> **Ein Registry-Repo zählt nur, wenn mindestens einer seiner Tags gerade +> läuft.** + +Damit fallen `element-desktop-build` und `windows-vm` heraus — beide werden +nirgends betrieben — und mit ihnen **61 der 62 CRITICAL** aus Haufen C. Was +bleibt, sind Rückroll-Ziele echter Dienste (`axion-backup:v1`, 1 CRITICAL), und +genau die waren der Zweck der Regel „letzte drei je Repo". + +Kein neuer Datenbestand: Die laufende Menge kennt die Herleitung bereits. + +### Nachtrag zu Gate 1 — Authentik, vor dem Anfassen gemessen + +⚠️ **Zuerst eine Korrektur an mir selbst.** Ich hatte behauptet, Authentiks +Sicherung sei nie zurückgespielt worden, weil die monatliche Probe sie nicht +führt. Falsch: **#0030 hat sie geprobt** — 325.149 Zeilen zurückgespielt. Der +Ausschluss aus dem *automatischen* Lauf ist eine begründete Entscheidung, die +im Manifest steht (Flows und Provider liegen als Blueprints deklarativ im Repo; +für den Rest gibt es Stufe 3 in `notfallhandbuch/notfall.sh`). Der Rückweg ist +belegt. Der Fehler war eine Teilmessung mit anschließender Behauptung — +dieselbe Klasse wie am Vormittag desselben Tages. + +**Ausgangslage:** `ghcr.io/goauthentik/server:2026.2.3`, ausgerollt per +HelmRelease (Chart-Fassung = App-Fassung), Server und Worker seit 2026-07-28. +Aktuell ist **2026.8.0** (erschienen 2026-08-18). Dazwischen liegt die +Fassungsreihe **2026.5.0–2026.5.6**. + +**Was das Update einbringt — am Zielimage gemessen, nicht geschätzt.** Trivy +kann ein Image prüfen, das nirgends läuft; der Scan lief lokal: + +| `ghcr.io/goauthentik/server` | CRITICAL | HIGH | +|---|---|---| +| **2026.2.3** (läuft) | 27 | 477 | +| **2026.8.0** (Ziel) | **5** | **21** | +| Delta | **−22** | **−456** | + +Die verbleibenden fünf sind 4× `perl-base` und 1× `libxml2`, beide ohne Fix — +das neue Image hat die übrigen Perl-Pakete abgeworfen (vorher 16 CRITICAL allein +aus `perl`, `perl-base`, `libperl5.40`, `perl-modules-5.40`). + +**Damit entfernt ein einziges Update 12 % aller laufenden CRITICAL und 17 % der +laufenden HIGH.** Das ist der größte Einzelhebel im gesamten Rückstand. + +**Verallgemeinerbar:** *Vor jedem Update das Zielimage scannen.* Das macht aus +„ein Update hilft vermutlich" eine Zahl — und aus einem Update, das nichts +brächte, eine ersparte Änderung. Gehört in das Runbook (Abnahmekriterium 4). + +⚠️ **Offen für Gate 2:** ob der Sprung über **2026.5** gestuft werden muss. +Zwischen 2026.2 und 2026.8 liegt eine volle Fassungsreihe mit eigenen +Datenbank-Migrationen; Authentik-Upgrades überspringen Fassungsreihen nicht +folgenlos. Das ist zu belegen, nicht anzunehmen.