Samstag, Ticket aufgemacht. Montag, noch offen. CISA hat zwei Linux-Kernel-Einträge in den KEV-Katalog geschoben — und der Change-Slot in zwei Wochen ändert an der Exposition im Internet genau gar nichts.

Der Alert landet, während die Schicht noch Kaffee nachgießt. Zwei neue Einträge im Known-Exploited-Vulnerabilities-Katalog. Linux. Kernel. Aktive Ausnutzung laut CISA. Jemand legt ein Ticket an, priorisiert es „High“, hängt den Link an und schreibt: Patch im nächsten Wartungsfenster. Vierzehn Tage. Manchmal drei Wochen. Die Server, die von außen erreichbar sind, bleiben genau dort, wo sie sind: im Netz. Erreichbar. Ungepatcht. Und der Clou? Das Ticket fühlt sich wie Arbeit an. Es ist keines.

Wir bei digital-magazin.de sehen dieses Muster oft genug: KEV-Meldung, Jira-Karte, Sprint-Backlog — und die Annahme, dass Priorisierung schon Remediation wäre. Spoiler: Sie ist es nicht. Was CISA am Freitag, dem 18. September, veröffentlicht hat, ist kein Soft-Hinweis für die nächste Retrospektive. Es ist der Startschuss. Und wer glaubt, ein geplanter Change-Slot sei Härtung, verwechselt Dokumentation mit Verteidigung.

Was CISA in den KEV-Katalog gelegt hat

Laut CISA-Alert vom 18. September hat die Behörde zwei Schwachstellen in den Known Exploited Vulnerabilities Catalog aufgenommen — ausdrücklich auf Basis von Evidenz aktiver Ausnutzung. Die Labels sind knallhart und trotzdem absichtlich hochstufig:

CVE-2025-39964 — Linux Kernel Race Condition Vulnerability
CVE-2026-53266 — Linux Kernel Out-of-Bounds Write Vulnerability

Mehr technische Tiefe brauchen Sie für die operative Entscheidung nicht. CISA schreibt klar: Derartige Schwachstellen seien ein häufiges Angriffsvektor-Muster und bergen erhebliche Risiken für das föderale Unternehmensumfeld. Was fehlt in diesem Satz? Die Anleitung zum Nachbauen. Was drin ist: der Hinweis, dass aktive Ausnutzung bereits stattfindet — und dass der Katalog genau dafür da ist, Prioritäten zu erzwingen, nicht Debatten zu verlängern.

Race Condition. Out-of-Bounds Write. Zwei Labels, die in Security-Reviews oft wie Fachchinesisch wirken, bis jemand den Satz umdreht: Es geht um Kernel-Fehlerklassen, die nach erfolgreicher Ausnutzung typischerweise volle Kontrolle über das betroffene System bedeuten können. CISA sagt das nicht als Romanplot. CISA sagt es als Katalogkriterium. Und der Katalog ist der Ort, an dem „irgendwann patchen“ aufhört, eine akzeptable Antwort zu sein — jedenfalls für Organisationen, die Risk-based Vulnerability Management ernst nehmen.

Interessant ist auch, was der Alert nicht liefert: keine Package-Listen, keine Distro-Versionstabellen, keine „prüfen Sie, ob Sie verwundbar sind“-Kochrezepte. Das ist Absicht und zugleich eine Warnung an Schreibende und Lesende. Wer jetzt anfängt, Subsysteme zu sezieren oder Exploit-Pfade nachzuzeichnen, betreibt keine Verteidigung. Wer Vendor- und Distro-Advisories folgt, Inventar zieht und Exposition senkt, schon.

BOD 26-04: Für Behörden verbindlich — für alle anderen ein Spiegel

Parallel zum KEV-Eintrag verweist CISA auf die Binding Operational Directive BOD 26-04: Prioritizing Security Updates Based on Risk. Sie richtet sich an Federal Civilian Executive Branch Agencies — kurz FCEB. Verbindlich also für zivile Bundesbehörden in den USA. Für den Rest der Welt? Kein Gesetz. Aber ein ziemlich unangenehmer Spiegel.

Was BOD 26-04 laut CISA festlegt, lässt sich ohne Forensik-Kochbuch zusammenfassen:

Schnelle Remediation von hochriskanten KEV-CVEs auf öffentlich exponierten Assets, bei denen eine erfolgreiche Ausnutzung die totale Kontrolle über das Asset bedeuten kann
Zurückstellen von niedrigeren Risiken — also: nicht alles gleich dringend behandeln, sondern Risiko und Exposition trennen
Grundlegende Erwartungen, wann geprüft werden muss, ob Angreifende das System vor dem Patch bereits kompromittiert haben

Der letzte Punkt ist der Plot Twist, den viele Change-Tickets ignorieren. Patchen ohne Kompromittierungsprüfung davor und danach ist wie eine Tür abschließen, ohne zu schauen, ob schon jemand drinnen sitzt. Wenig überraschend: Genau das fordert BOD 26-04 als Erwartungshaltung — zumindest für die Behörden, an die sie bindet.

CISA betont ausdrücklich: BOD 26-04 gilt nur für FCEB. Gleichzeitig ermutigt die Behörde alle Organisationen, risk-basiertes Schwachstellenmanagement zu übernehmen und die Remediation von KEV-Katalog-Einträgen zu priorisieren. Das ist keine Höflichkeitsfloskel. Das ist die Einladung, denselben Standard zu nutzen, ohne dass jemand Ihnen die Directive vor die Tür legt.

Wer die Implementierungsseite nachlesen will: CISA stellt dazu Implementierungsleitlinien zu BOD 26-04 bereit — hochstufig, risk-basiert, ohne Exploit-Rezepte. Für den Alltag reicht die Kernbotschaft: öffentlich exponiert + KEV + totale Kontrolle nach Ausnutzung = vorne in der Queue. Alles andere darf warten. Der Change-Slot darf nicht das Argument sein, warum das Vorderste hinten landet.

Kurz zur Nominierung: Potenzielle KEV-Einträge brauchen laut CISA eine CVE-ID, Evidenz der Ausnutzung und klare Mitigationshinweise. Mehr muss man dazu nicht schreiben — und wer jetzt Nomination-Formulare zum CTA macht, hat den Punkt verfehlt. Der Punkt ist Remediation, nicht Formularpflege.

Wir bei digital-magazin.de haben BOD-Logik schon bei früheren KEV-Wellen beobachtet: Behörden bekommen Fristen. Unternehmen bekommen Ausreden. Der Unterschied ist kulturell, nicht technisch.

Plot Twist: Das KEV-Ticket patcht nichts

Stellen Sie sich den Montagmorgen vor. Das Ticket aus dem Samstag steht auf „Ready for Sprint“. Die Beschreibung zitiert CISA. Die Labels stimmen. Die Priorität ist „Critical“ oder „High“. Im Kommentarthread diskutiert man, ob man den Kernel-Update-Pfad mit dem nächsten Reboot-Fenster bündeln kann. Jemand fragt nach dem Freeze. Jemand anderes nach dem Rollback-Plan. Alles vernünftig. Alles dokumentiert. Alles noch offen.

Und genau hier liegt der Clou: Ein KEV-Ticket ist der Startschuss. Es ist nicht die Härtung. Es ist nicht die Remediation. Es ist nicht einmal die Expositionssenkung. Es ist eine Verwaltungsartefakt-Wahrheit: Jemand hat gelesen und etwas angelegt. Brisant wird es erst, wenn Internet-facing Linux-Systeme in derselben Woche noch denselben Angriffsraum bieten wie am Freitagabend — während das Ticket brav im Board hängt und auf den Slot wartet.

Vierzehn Tage Change-Slot gegen aktive Ausnutzung. Das ist keine Planung. Das ist eine Wette. Die Überraschung für viele Teams: Die Wette fühlt sich wie Governance an. Governance ohne Remediation ist Theater. Und Theater ist, was Angreifende nicht interessiert.

Pikante Nebenbemerkung: Viele Organisationen behandeln KEV wie ein Compliance-Häkchen. „Wir haben den Katalog abonniert.“ „Wir tracken.“ „Wir priorisieren.“ Priorisieren heißt in der Praxis oft: Ticket erstellen, SLA setzen, warten. BOD 26-04 dreht die Logik um — zumindest für FCEB und als Vorbild für alle anderen: Hochrisiko auf öffentlich exponierten Assets zuerst. Niedrigrisiko zurückstellen. Und prüfen, ob die Kompromittierung schon vor dem Patch passiert ist. Wer nur das Häkchen setzt, hat die These verfehlt.

These: Das Abhaken der KEV-Box und das Planen für „next Sprint“ verwechselt Priorisierung mit Remediation. Priorisierung ist die Reihenfolge. Remediation ist der Zustand danach. Dazwischen liegen Exposition, Patch, Reboot, laufender neuer Kernel — und die Frage, ob das System schon vor dem Update kompromittiert war.

Wenn Sie interne Vergleiche brauchen: Frühere KEV-Wellen um andere Stacks haben gezeigt, wie schnell Katalogeinträge operative Panik auslösen — und wie langsam dann die tatsächliche Flottenarbeit folgt. Bei uns auf digital-magazin.de etwa in Beiträgen wie dem zu Langflow im KEV-Kontext oder zu vCenter und dem Katalogdruck auf Admins. Der Kernel-Fall hier ist ein anderer Stoff. Er ist breiter. Er trifft mehr Flotten. Und er verträgt keine „wir schauen nächste Woche“-Romantik.

Was Verteidigung jetzt konkret heißt

Kein Exploit-Workshop. Keine Subsystem-Sezierungen. Keine Versionstabellen aus dem Bauch. Was bleibt, ist Arbeit — die unangenehme Sorte.

1. Inventar: Welche Linux-Systeme stehen im Internet?

Bevor jemand „wir patchen alles“ ruft, brauchen Sie die Liste der Systeme, die von außen erreichbar sind. Management-Interfaces. Bastion-Hosts. VPN-Endpunkte, die auf Linux laufen. Build-Agents mit öffentlicher IP. Alte Testmaschinen, die niemand abgeschaltet hat. Container-Hosts mit exponierten Ports. Das Inventar ist nicht sexy. Es ist die Voraussetzung, dass BOD-Logik überhaupt greift: öffentlich exponiert zuerst.

Wer kein Inventar hat, kann auch keinen risk-basierten Schnitt machen. Dann wird aus „priorisieren“ wieder „alles irgendwann“. Und „alles irgendwann“ ist der Change-Slot, der nie eng genug wird.

Praktisch heißt das: Asset-Quellen zusammenführen — CMDB, Cloud-Inventory, Scanner-Ergebnisse, Firewall-Regeln, Load-Balancer-Backends. Nicht als Projekt fürs Quartal. Als Aufgabe für diese Woche. KEV mit aktiver Ausnutzung wartet nicht auf saubere Datenmodelle.

2. Vendor- und Distro-Advisory folgen — nichts erfinden

Für CVE-2025-39964 und CVE-2026-53266 gilt die einfachste Verteidigungsregel, die trotzdem am häufigsten gebrochen wird: Vendor-/Distro-Advisory folgen. Keine Package-Namen aus dem Gedächtnis. Keine Versionsnummern aus Foren. Keine „bei uns war es immer dieses Paket“-Mythen. Offizielle Advisories der Distributionen und Vendoren lesen, freigegebene Fixes übernehmen, Changelog gegen die CVE-IDs halten.

Wenn Ihr Vendor noch nichts veröffentlicht hat, ist das ein Status — kein Freibrief, die Exposition zu ignorieren. Dann rücken Exposure-Reduktion und Monitoring nach vorne, bis der Fix da ist. Erfinden Sie keine Workarounds aus Blogposts, die Subsysteme sezieren. Das ist Angriffsnahe, keine Härtung.

3. Exposition senken, bevor der Slot kommt

Vierzehn Tage bis zum Reboot-Fenster? Dann ist die Frage nicht nur „wann patchen wir“, sondern „was können wir heute vom Internet nehmen“. Management-Ports schließen. Access-Listen enger ziehen. Jump-Hosts statt direkter Erreichbarkeit. Temporäre Abschaltungen von nicht kritischen Services. Network-Segmentation, die schon existieren sollte und oft nur auf Folien steht.

Exposure-Reduktion ist der Teil der Geschichte, den Change-Boards gerne überspringen, weil er keine elegante Ticket-Kategorie hat. Er ist trotzdem der Unterschied zwischen „wir warten auf den Slot“ und „wir verkürzen den Angriffsraum, während wir warten“.

Wenig überraschend: Teams, die Exposition erst nach dem Patch anfassen, entdecken dann oft, dass der Patch gar nicht der Engpass war — sondern die fehlende Übersicht, welche Systeme überhaupt hätten warten dürfen.

4. Kompromittierungsprüfung vor und nach dem Patch

Hier greift die BOD-26-04-Logik auch außerhalb von FCEB: Prüfen, ob Angreifende das System kompromittiert haben, bevor der Patch angewendet wurde — und erneut danach. Das ist Teil der Geschichte, nicht das Bonuskapitel.

Was das auf hoher Ebene bedeutet, ohne Forensik-Kochbuch:

Baseline-Vergleiche bekannter guter Zustände gegen aktuelle Artefakte
Auffällige Persistenz, unerwartete Accounts, verdächtige Scheduled Tasks / Cron-Jobs
Ungewöhnliche Netzwerkverbindungen von Hosts, die eigentlich still sein sollten
Logs rund um den Zeitraum vor dem Alert und vor dem Patch-Fenster
Nach dem Patch: erneut prüfen, ob der Zustand sauber ist — nicht annehmen, dass der Fix Vergangenheit löscht

Ein Patch entfernt die Schwachstelle im Codepfad. Er entfernt nicht automatisch eine bereits etablierte Präsenz. Wer das vergisst, hat den Spoiler der Directive nicht gelesen: CISA formuliert Erwartungen genau zu diesem Prüfen — weil Remediation ohne Kompromittierungsblick unvollständig ist.

Wir bei digital-magazin.de halten diesen Punkt für den am häufigsten unterschlagenen in KEV-Debatten. Alle reden über Fristen. Wenige reden über „war schon jemand drin“.

5. Neuer Kernel muss auch laufen

Patch installiert. Ticket auf „Done“. Monitoring grün. Und dann der Klassiker: Der Host läuft noch auf dem alten Kernel, weil niemand rebootet hat — oder weil der Reboot verschoben wurde, oder weil live-patching angenommen wurde, wo keines greift, oder weil die Flotte heterogen ist und jemand die falsche Maschine geprüft hat.

Verteidigung heißt hier: nachweisen, dass der neue Kernel tatsächlich aktiv ist. Nicht „Paket installiert“. Nicht „Advisory angewendet“. Sondern: laufendes System entspricht dem freigegebenen Fix-Stand. Ohne diesen Nachweis ist das Häkchen im Ticket eine Geschichte, die Sie sich selbst erzählen.

Das klingt pedantisch. Es ist pedantisch. Pedanterie ist in Kernel-Remediation keine Charakterschwäche. Sie ist der Clou zwischen „wir haben gepatcht“ und „wir sind remediiert“.

Warum der Samstag-zu-Montag-Abstand so wehtut

Zurück zur Szene. Samstag: Alert. Ticket. Link. Priorität. Montag: Stand-up. „Liegt im Sprint.“ Dienstag: Freeze-Diskussion. Mittwoch: Rollback-Szenario. Donnerstag: „Können wir mit dem anderen Kernel-Update bündeln?“ Freitag: Slot in einer Woche. Die Flotte? Noch immer dieselben Ports. Dieselbe Exposition. Dieselbe Annahme, dass aktive Ausnutzung höflich wartet, bis Ihr Change Advisory Board nickt.

Das ist der Plot Twist in Reinform: Der Prozess fühlt sich kontrolliert an. Die Kontrolle ist über den Prozess, nicht über den Angriffsraum. BOD 26-04 versucht genau diese Verwechslung zu durchbrechen — für Behörden mit Verbindlichkeit, für alle anderen mit der unangenehmen Frage: Warum sollten Sie langsamer sein als eine Directive, die Sie nicht bindet?

Natürlich gibt es legitime Gründe für Wartungsfenster. Verfügbarkeit. Abhängigkeiten. Zertifizierte Images. Cluster-Rollouts. Niemand verlangt Blind-Reboots um drei Uhr nachts ohne Plan. Was verlangt wird — von der Logik her, nicht vom deutschen Gesetz —, ist Ehrlichkeit: Wenn das Asset öffentlich exponiert ist und der KEV-Eintrag totale Kontrolle nach Ausnutzung impliziert, dann ist „nächster Slot in 14 Tagen“ keine neutrale Planung. Es ist eine bewusste Risikoakzeptanz. Die sollte dokumentiert, eskaliert und idealerweise verkürzt werden — nicht hinter einem Priority-Label versteckt.

Brisant wird es, wenn dieselbe Organisation gleichzeitig in Präsentationen „risk-based“ sagt und in der Praxis „slot-based“ handelt. Risk-based heißt: Exposition und Nachwirkung entscheiden die Reihenfolge. Slot-based heißt: der Kalender entscheidet. KEV mit Evidence of active exploitation verträgt Slot-based nur als Ausnahme mit klarer Begründung — nicht als Default.

Der Katalog als Startschuss, nicht als Checkbox

Hände mit Patch-Checkliste neben Laptop im ruhigen Serverraum — Change-Fenster und externe Logs: Remediation vor dem Scanner-Haken (Symbolbild)

CISA fügt dem KEV-Katalog laufend Einträge hinzu, die die Kriterien erfüllen. Das ist keine Überraschung. Die Überraschung ist, wie oft Organisationen den Katalog als Newsletter behandeln statt als Operations-Trigger. Ein neuer Linux-Kernel-Eintrag — geschweige denn zwei an einem Tag — ist kein Content für die Security-News-Runde. Es ist Arbeit an der Flotte.

Zum Vergleich lohnt ein Blick auf andere KEV-Wellen, die wir bei digital-magazin.de begleitet haben — etwa rund um Advisory-Druck und kritische Einstufungen. Der Mechanismus ist verwandt: Katalog, Evidenz, Druck auf Remediation. Der Stoff hier ist Linux und Kernel und die Breite der betroffenen Landschaften. Deshalb taugt Copy-Fail-Romantik oder Exploit-Deep-Dive als Leitnarrativ nicht. Leitnarrativ ist: Ticket vs. Zustand. Slot vs. Exposition. Priorisierung vs. Remediation.

Und ja: Genderneutrale Formulierung hilft hier auch kulturell. „Admins“, „Teams“, „Verantwortliche“, „Angreifende“ — die Sprache der Verteidigung sollte nicht so tun, als ob nur eine Rolle den Reboot drückt. Flottenarbeit ist Teamarbeit. Die Ausrede „die Linux-Leute machen das nächste Woche“ ist Teil des Problems, wenn niemand Ownership für Internet-facing Assets klar hat.

Was Sie heute tun können — ohne Exploit-Nähe

Eine kurze, harte Liste. Kein Roman. Keine Schlussfloskel. Die Schritte, die zwischen Samstag-Alert und Montag-Stand-up liegen sollten:

Alert lesen — CISA-Quelle, zwei CVE-IDs, Labels Race Condition / Out-of-Bounds Write, Evidenz aktiver Ausnutzung.
Internet-facing Linux inventarisieren — nicht „alle Server“, sondern die exponierten zuerst.
Vendor-/Distro-Advisory prüfen — offizielle Quellen, keine erfundenen Package-Mythen.
Exposition sofort senken, wo Patch noch nicht möglich ist.
Kompromittierungsprüfung planen und starten — vor dem Patch, nicht nur danach.
Patch + Nachweis laufender neuer Kernel — Ticket erst schließen, wenn der Zustand stimmt.
Erneut prüfen — nach dem Patch. Weil BOD-Logik das so vorsieht und weil Realität das so verlangt.

Wenn Ihr Change-Slot trotzdem zwei Wochen entfernt liegt: Eskalieren Sie die Risikoakzeptanz schriftlich. Nicht als Drama. Als Klartext. „Wir lassen diese exponierten Hosts X Tage ungepatcht, obwohl CISA aktive Ausnutzung für KEV-Einträge dokumentiert.“ Manche Boards werden unruhig. Gut so. Unruhe ist billiger als Incident-Response.

Zwischen Behördenfrist und Unternehmensalltag

FCEB-Agencies haben die Directive. Sie haben Erwartungen. Sie haben den Katalog als verbindlichen Priorisierungsrahmen für bestimmte hochriskante, öffentlich exponierte Fälle. Unternehmen außerhalb dieses Rahmens haben Wahlfreiheit — und damit die volle Verantwortung für die Konsequenzen der Wahl.

Manche werden argumentieren, sie seien „nicht so kritisch wie Behörden“. Pikante Gegenfrage: Sind Ihre internet-facing Linux-Hosts weniger interessant für Angreifende, nur weil Sie keine FCEB-Agentur sind? Der Katalog unterscheidet nicht nach Ihrer Branchenzugehörigkeit, wenn die Evidenz der Ausnutzung einmal da ist. Er listet. Sie entscheiden, ob Sie dem Listing folgen.

Andere werden sagen, Kernel-Updates seien „zu riskant für Hotfixes“. Dann ist die Antwort nicht „also warten wir“. Die Antwort ist: Exposure runter, Staging hochfahren, Rollback testen, Kompromittierungsblick schärfen, Slot vorziehen. Risiko gegen Risiko. Nicht Kalender gegen Katalog.

Und wieder andere werden das Ticket auf „Monitoring“ stellen und hoffen, dass IDS/EDR die Lücke schließt. Monitoring ist Sicht. Es ist kein Patch. Es ist auch kein Ersatz für die Prüfung, ob schon jemand drin war. Wer Monitoring als Remediation verkauft, schreibt Krimis mit offenem Ende — und hofft, dass niemand das letzte Kapitel liest.

Der Jira-Ticket-Effekt und warum er gefährlich beruhigt

Psychologisch ist das Ticket der Beruhiger. Es externalisiert Verantwortung in ein System, das Status anzeigt. „In Progress.“ „Blocked by Freeze.“ „Waiting for CAB.“ Jeder Status ist wahr und zugleich irrelevant für die Frage, ob der Host im Internet noch denselben Kernel-Stand fährt wie vor dem Alert.

Der Plot Twist bleibt: Das KEV-Ticket patcht nichts. Es speichert Intent. Intent ohne Expositionssenkung, ohne Advisory-Follow-through, ohne Kompromittierungsprüfung, ohne laufenden neuen Kernel ist Intent-Theater. Und Intent-Theater ist der Stoff, aus dem nachträgliche Postmortems gemacht werden — mit dem Satz „wir hatten es auf dem Schirm“.

„Auf dem Schirm“ ist kein Verteidigungszustand. „Remediated und geprüft“ ist einer. Dazwischen liegen Tage, in denen aktive Ausnutzung laut CISA bereits Evidenz hat. Das ist der Abstand, den Samstag und Montag so schmerzhaft machen: nicht die fehlende Information, sondern die fehlende Umsetzung.

Wenn Sie interne Playbooks schreiben, schreiben Sie den Satz groß: KEV-Eintrag = Startschuss, nicht Härtung. Dann die BOD-Logik darunter: öffentlich exponiert + hohe Nachwirkung zuerst; Kompromittierung vor und nach dem Patch prüfen; niedrige Risiken bewusst zurückstellen statt alles gleichzeitig zu versprechen.

Was dieser Text absichtlich nicht liefert

Keine Reproduktionsanleitungen. Keine Payload-Diskussion. Keine „so prüfen Sie, ob Sie verwundbar sind“-Ersatzangriffe. Keine Subsystem-Namen als Deep-Dive. Keine Package-Versionen aus dem Handgelenk. Keine zweite Story über andere Produkte. Der Fokus bleibt: CISA hat zwei Linux-Kernel-Schwachstellen mit den Labels Race Condition und Out-of-Bounds Write in den KEV-Katalog aufgenommen — wegen aktiver Ausnutzung. BOD 26-04 rahmt, wie Behörden damit umgehen sollen. Alle anderen dürfen denselben Rahmen übernehmen. Der Change-Slot ist kein Ersatz für Remediation.

Wer mehr technische Tiefe braucht, geht in die offiziellen Advisories der Vendoren und Distributionen. Wer mehr Directive-Kontext braucht, liest CISA. Wer mehr Operatives braucht, inventarisiert die eigene Flotte. Das ist langweiliger als Exploit-Folklore. Es ist auch die einzige Sorte Text, die Hosts wirklich schließt.

Samstag nochmal — ohne Happy End

Der Alert bleibt im Postfach. Das Ticket bleibt im Board. Die Hosts bleiben erreichbar, bis jemand Exposition, Patch und Prüfung wirklich durchzieht. CISA hat den Katalog aktualisiert. Die Labels stehen. Die Evidenz aktiver Ausnutzung steht. BOD 26-04 steht für Behörden — und als Spiegel für alle.

Ob Ihr Montag mit einem vorgezogenen Slot beginnt oder mit einer höflichen Lüge namens „priorisiert“, entscheiden Sie. Der Katalog wartet nicht auf Ihre Retrospektive. Angreifende auch nicht. Und das Jira-Ticket? Das patcht weiterhin nichts — außer dem Gewissen derjenigen, die Priorisierung mit Remediation verwechseln.

Vierzehn Tage Change-Slot gegen internet-facing Linux mit aktiver Ausnutzung: Das ist keine Härtung. Das ist eine Frist, die Sie sich selbst geben, während der Startschuss schon gefallen ist. Wer den Schuss hört und trotzdem nur den Kalender öffnet, hat den Clou der Geschichte verstanden — und trotzdem die falsche Seite gewählt.

Halten Sie die Reihenfolge gerade: Inventar der exponierten Linux-Systeme. Vendor-/Distro-Advisory. Exposition senken. Kompromittierung prüfen — vorher. Patchen. Neuen Kernel nachweisen. Kompromittierung prüfen — nachher. Ticket schließen. Nicht umgekehrt. Nicht „Ticket zuerst, Rest irgendwann“. Irgendwann ist der Moment, in dem aus einem KEV-Eintrag eine Postmortem-Folie wird.

Und wenn jemand im Stand-up sagt, man sei „auf Kurs“, fragen Sie nach dem Zustand der Hosts — nicht nach dem Status des Tickets. Der Unterschied ist der ganze Artikel.