Schonfrist schrumpft: Lücken werden schneller öffentlich, Patches kommen später

Darum geht es

Wer eine Sicherheitslücke findet, meldet sie normalerweise zuerst dem Hersteller und schweigt eine Weile. In dieser Zeit soll ein Patch entstehen und bei den Nutzern ankommen. Diese Schonfrist nennt man koordinierte Offenlegung. Jahrzehntelang galten 90 Tage als Richtwert. Gerade verkürzen mehrere wichtige Stellen gleichzeitig ihre Fristen, und alle nennen denselben Grund: Sprachmodelle finden Lücken schneller und bauen aus einem veröffentlichten Patch fast sofort einen funktionierenden Angriff.

Unsere These: Die Fristen werden kürzer, die tatsächliche Reparatur dauert aber länger. Zwischen dem Tag, an dem Angreifer Bescheid wissen, und dem Tag, an dem der Patch auf dem Gerät landet, wächst der Abstand. Wir legen die neuen Regeln nebeneinander, stellen ihnen die gemessenen Zahlen gegenüber und zeigen, wer bei 30 Tagen nicht mitkommt.

Die neuen Regeln: Project Zero, GNOME, CISA

Google Project Zero hat am 13. November 2026 sein seit 2021 geltendes Modell „90+30“ abgeschafft. Bisher hatten Hersteller 90 Tage für einen Fix. War er fertig, folgten 30 Tage „Soak Time“, also Zeit, in der Nutzer das Update einspielen konnten, bevor Details öffentlich wurden. Auf Antrag gab es außerdem eine Nachfrist von 14 Tagen. Jetzt gilt „Full X“: Eine Lücke wird X Tage nach der Meldung veröffentlicht, ob gepatcht oder nicht. Derzeit sind das 90 Tage, ab dem 2. Februar 2027 noch 60 und ab dem 3. Januar 2028 nur noch 30. Die Nachfrist und die Sonderregel für Varianten bereits gemeldeter Fehler fallen weg. Wie schwer eine Lücke wiegt, spielt für den Zeitpunkt keine Rolle mehr. Begründung des Teams: Die Schwere ändere zwar die Folgen eines Angriffs, aber nicht die Wahrscheinlichkeit, dass Angreifer den Fehler finden.

Zur Begründung schreibt Project Zero, Sprachmodelle hätten die Zeit stark verkürzt, die man braucht, um aus einem Patch zurückzurechnen, welcher Fehler darin behoben wurde. Eine Zeit von null zwischen Patch und Angriff sei ein „vernünftiges, wenn auch unvollkommenes Modell“ für das Verhalten von Angreifern. Die Soak Time vermittle deshalb nur ein „falsches Gefühl von Geheimhaltung“. Dazu kommt die Menge: Früher fand das Team ein paar Lücken im Jahr, heute mehrere pro Woche. Einzelverhandlungen über Fristverlängerungen seien so nicht mehr zu bewältigen. Hersteller sollen stattdessen den Patch Gap verkleinern, also die Zeit zwischen dem fertigen Fix und seiner Installation beim Nutzer.

GNOME ist schon weiter. Michael Catanzaro, der die Sicherheitsmeldungen des Desktop-Projekts seit November 2020 mit Unterstützung von Red Hat betreut, kündigte am 20. Juli an: Meldungen, die ab dem 1. August 2026 eingehen, werden nach 30 statt 90 Tagen veröffentlicht, oder früher, sobald der Fix da ist. Seine Begründung:

„Nicht-KI-Meldungen sind inzwischen eher ungewöhnlich, deshalb ergibt es keinen Sinn mehr, für sie zu optimieren.“

Die meisten Maintainer reparierten ohnehin binnen ein bis drei Wochen oder gar nicht. Den Weg des Linux-Kernels, mutmaßlich KI-generierte Meldungen sofort öffentlich zu machen, lehnte er als „unfreundlich gegenüber Maintainern“ ab.

Die US-Cybersicherheitsbehörde CISA hat am 10. Juni die Direktive BOD 26-04 erlassen. Sie ersetzt die älteren Direktiven 19-02 und 22-01 durch ein Raster aus vier Fragen: Ist das System aus dem Internet erreichbar? Steht die Lücke im KEV-Katalog, der Liste nachweislich ausgenutzter Lücken? Lässt sich der Angriff vollständig automatisieren? Erlangt der Angreifer teilweise oder volle Kontrolle? Je nach Antwort gelten laut Tenable drei, 14 oder 60 Tage oder „beim nächsten Upgrade“. Für die gefährlichsten Fälle verlangt die Direktive drei Tage plus forensische Prüfung, ob das System schon kompromittiert ist. Eine Entschärfung (Mitigation) zählt ebenfalls. Bis zum 7. Dezember 2026 müssen die Behörden das umsetzen. CISA schreibt selbst, der KI-Einsatz von Angreifern könne die Reaktionszeit der Verteidiger „weiter verkürzen“.

Die Fristen im Überblick

Wichtig dabei: Nur Project Zero und GNOME haben wirklich verkürzt. ZDI und CERT/CC haben wir auf ihren eigenen Seiten geprüft, Änderungen gibt es dort keine. Beim BSI nennen Sekundärquellen für die CVD-Leitlinie von 2022 eine übliche Spanne von 45 bis 90 Tagen. Ob das BSI nachsteuert, ist offen.

Was die Zahlen sagen: Die Schere geht auf

Die Reihe von Flashpoint reicht weiter zurück: 2020 vergingen im Schnitt noch 745 Tage bis zum ersten Angriff, das ist rund das 17-Fache von heute. Mandiants negativer Wert bedeutet, dass Angreifer im Mittel schon vor Veröffentlichung oder Patch zuschlagen. Laut Verizon ist das Ausnutzen von Lücken mit 31 Prozent inzwischen der häufigste Einstiegsweg bei Datenpannen, noch vor gestohlenen Zugangsdaten mit 13 Prozent.

Nachgerechnet: 2024 lagen zwischen typischer Behebung (32 Tage) und typischem ersten Angriff (115 Tage) noch rund 83 Tage Vorsprung für die Verteidiger. 2025 ist der Vorsprung bei 43 gegen 44 Tage praktisch verschwunden. Nach den Moody's-Daten sind bekannte ausgenutzte Lücken im Median sogar 87 Tage lang sichtbar, also rund sechs Wochen länger, als es bis zum ersten Angriff dauert.

Unsere Einschätzung: Die Zahlen sind nicht direkt vergleichbar. Flashpoint nennt einen Durchschnitt ab Veröffentlichung, Verizon einen Median, der laut Berichten erst mit der Entdeckung im eigenen Netz beginnt. Die Richtung ist trotzdem eindeutig, und sie passt zu den neuen Fristen: Diese setzen die Finder unter Druck, schneller zu veröffentlichen, während sich bei den Betreibern die Arbeit staut. Verizon erklärt den Anstieg unter anderem damit, dass Organisationen im Median 16 statt 11 KEV-Lücken gleichzeitig abarbeiten mussten.

Wer bei 30 Tagen nicht mitkommt

Android: Zwischen Google und dem Nutzer stehen Chiphersteller und Gerätehersteller. Eine Studie auf der Konferenz NDSS 2024 maß über alle untersuchten Samsung-Geräte im Schnitt 140 Tage zwischen dem Patch-Level im Android Security Bulletin und der fertigen Firmware, bei Xiaomi 32 Tage. Laut einer Google-Studie mit 567.000 Update-Datensätzen lassen sich 89,7 Prozent der Lücken auf ungepatchten Android-Geräten ohne Zutun des Nutzers und mit geringem Aufwand ausnutzen. Hinzu kommt: Die monatlichen Bulletins enthalten inzwischen nur noch Lücken mit hohem Risiko, die meisten Fixes kommen quartalsweise. Das alternative Android-System GrapheneOS berichtete im Juli, Google portiere die meisten intern gefundenen Lücken nur noch zurück, wenn sie kritisch sind, und dann nur nach Android 16 und 17. Als Grund nennt GrapheneOS eine Flut KI-gefundener Lücken. Das ist die Darstellung von GrapheneOS, eine offizielle Bestätigung von Google liegt uns nicht vor.

Router und Embedded-Geräte: Hier gibt es oft gar keinen Update-Weg, den der Nutzer selbst steuern kann. Bei Providerroutern müssen Fixes laut Berichten erst durch monatelange Integrations- und Testketten. Project Zero hat selbst schon 2025 auf diesen Upstream Patch Gap hingewiesen: Der Chiphersteller hat den Fix längst fertig, die Gerätehersteller haben ihn aber noch nicht eingebaut. Für Hardware stellt das Team weiterhin seltene Ausnahmen wie bei Spectre und Meltdown in Aussicht, aber keine Regel.

Linux und Distributionen: Der Kernel selbst ist schnell, ein Fix darf höchstens sieben Tage zurückgehalten werden. Langsam ist die Kette dahinter. Microsofts KI-System MDASH schickte, wie wir berichtet haben, 59 Kernel-Fehlerberichte, 55 davon bis zum 1. September. Bis zum 11. November waren Fixes für 38 Berichte im Hauptzweig angekommen. Bei einem Drittel stand also auch nach mehr als zehn Wochen noch kein Fix im Mainline-Kernel, von Distributionen und Geräten ganz zu schweigen. Torvalds sieht beim Testkernel 7.4-rc2 nur im BPF-Bereich, dass Korrekturen schneller kommen als neue Meldungen. Die meisten anderen Bereiche seien noch nicht so weit.

Ehrenamtsprojekte: Hier ist der Mensch der Engpass. Catanzaro hört am 1. November auf, und GNOME hat keinen Nachfolger für die Sicherheitsmeldungen. Kernel-Entwickler Lorenzo Stoakes hat, wie berichtet, Reviewer-Rollen abgegeben, weil nach seiner Schätzung mindestens die Hälfte der Patches „KI-Slop“ sei, also lieblos automatisch erzeugter Code. Sebastian Pipping widersprach GNOME öffentlich: Andere Projekte sollten die 30 Tage nicht übernehmen, denn sie würden zum Problem, sobald mehrere Fälle gleichzeitig eintreffen. Auf Hacker News nannten Kommentatoren die vorgesehenen 30 Tage für Project Zero „unnötig hart“ und fragten, was mit Fehlern passiere, die sich grundsätzlich schwer beheben lassen. Project Zero berichtet selbst, Hersteller hätten gewarnt, harte Fristen könnten dazu führen, dass Teams nach Fristablauf statt nach Schwere priorisieren oder gleich aufgeben.

Der EU-Faktor: Cyber Resilience Act

Seit dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Lücken über ENISAs Single Reporting Platform melden: eine Frühwarnung binnen 24 Stunden, eine Meldung mit erster Bewertung binnen 72 Stunden und einen Abschlussbericht 14 Tage nach Verfügbarkeit des Fixes. Für Verwalter von Open-Source-Software, im Gesetz „Stewards“ genannt, gilt die Pflicht ab dem 11. Dezember 2027, gut drei Wochen bevor Project Zero auf 30 Tage geht.

Interessant ist ein Detail in Anhang I Teil II Nr. 4 des CRA. Hersteller müssen Informationen zu behobenen Lücken veröffentlichen, dürfen das aber in „hinreichend begründeten Fällen“ aufschieben, „bis Nutzer die Möglichkeit hatten, den Patch einzuspielen“. Das Gesetz sieht also genau die Soak Time vor, die Project Zero gerade abgeschafft hat. Unsere Einschätzung: Ein Widerspruch im juristischen Sinn ist das nicht, denn der CRA bindet Hersteller und nicht die Forscher, die eine Lücke finden. In der Praxis wird es aber häufiger vorkommen, dass ein europäischer Hersteller Details zurückhalten darf, die Project Zero längst veröffentlicht hat. Wird die Lücke danach ausgenutzt, beginnt für den Hersteller die 24-Stunden-Meldefrist.

Was Nutzer und Admins jetzt tun sollten

• Automatische Updates einschalten und Browser, Smartphone und Rechner nach Updates wirklich neu starten. Bei Android unter „Sicherheitspatch-Ebene“ prüfen, wie alt der Stand ist.
• Beim Gerätekauf auf Update-Zusagen achten, nicht nur auf deren Dauer, sondern auch darauf, wie schnell Patches kommen. Router ohne Herstellersupport ersetzen.
• Admins: Inventar zuerst. Laut Flashpoint bringt eine vollständige Übersicht aller Geräte und Systeme mehr als jedes neue KI-Werkzeug. Die vier Fragen der CISA eignen sich auch außerhalb von US-Behörden zum Priorisieren: aus dem Internet erreichbar, im KEV-Katalog, automatisierbar, volle Kontrolle möglich.
• Den Veröffentlichungstermin einplanen. Project Zero listet seit 2025 auf seiner Transparenzseite etwa eine Woche nach jeder Meldung Hersteller, Produkt und Frist. Mit festen Fristen steht der Veröffentlichungstag damit von Anfang an fest. Allein im Oktober 2026 kamen dort 23 neue Einträge hinzu, die meisten zu Apple.
• Mitigations vorbereiten, also Workarounds wie das Abschalten eines Dienstes, für die Fälle, in denen der Patch später kommt als die Veröffentlichung.
• Hersteller in der EU: Den Zugang zur CRA-Meldeplattform einrichten, bevor der erste Ernstfall eintritt. Laut Help Net Security gibt es dort zum Start keine API, man meldet über ein Webformular.

Einordnung

Die neuen Fristen sind eine nachvollziehbare Reaktion. Wenn KI-Werkzeuge einen Patch in Minuten bis Stunden auswerten, schützt Geheimhaltung nach dem Patch kaum noch. Project Zero hat außerdem recht damit, dass ein Problem erst gelöst ist, wenn der Fix auf dem Gerät des Nutzers läuft. Belegt ist allerdings nur ein Teil: Die Begründung mit einer Patch-zu-Exploit-Zeit von null ist ausdrücklich ein Modell und keine Messung. Die Messungen zeigen dagegen, dass die Behebung langsamer wird.

Unsere Einschätzung: Kürzere Fristen erhöhen den Druck auf die, die schnell sein können, also große Softwarehersteller mit eigenen Update-Kanälen. Für Android-Gerätehersteller, Router, Embedded-Geräte und Ehrenamtsprojekte machen sie die Lücke zwischen Wissen und Schutz eher größer, solange sich die Update-Ketten nicht ändern. Ob die Rechnung aufgeht, wird sich ab Februar 2027 zeigen, wenn die 60-Tage-Frist greift, und spätestens Anfang 2028. Dann fallen 30 Tage Project Zero und CRA-Meldepflichten für Open-Source-Stewards zeitlich fast zusammen. Offen ist auch, ob die KI, die Lücken findet, die Reparatur genauso beschleunigt. Für den BPF-Bereich des Kernels deutet Torvalds das an, für den Rest noch nicht.