Java
Java unter Beschuss: 53 Schwachstellen und zwei Notfall-Patches innerhalb von 5 Tagen
KI-Angriffe erhöhen den Druck auf Unternehmen
Die wachsende Geschwindigkeit von Cyberangriffen stellt das klassische Patch-Management infrage. Während KI die Suche und Ausnutzung von Schwachstellen beschleunigt, benötigen Unternehmen häufig Wochen, um kritische Sicherheitslücken zu schließen. Der Oktober 2026 zeigt, warum herkömmliche Java-Updates zunehmend zum Sicherheitsrisiko werden.
Java bildet das unsichtbare Rückgrat zahlreicher geschäftskritischer Anwendungen – von Kernbanksystemen über E-Commerce-Plattformen bis hin zu Identitätsdiensten. Doch ausgerechnet diese Systeme werden häufig nur zögerlich aktualisiert, weil Unternehmen Betriebsunterbrechungen und Kompatibilitätsprobleme vermeiden wollen. Angesichts immer schnellerer Cyberangriffe und KI-gestützter Angriffstechniken entwickelt sich diese Zurückhaltung zunehmend zu einem erheblichen Sicherheitsrisiko.
Wie stark sich die Anforderungen an das Patch-Management verändert haben, zeigte sich im Oktober 2026. Innerhalb von nur fünf Tagen mussten Java-Verantwortliche auf ein reguläres Sicherheitsupdate mit 53 Schwachstellen und zwei zusätzliche Notfall-Patches reagieren. Für Unternehmen mit langen Test- und Freigabeprozessen wird dieses Tempo zur Herausforderung.
Hinzu kommt eine wachsende Diskrepanz zwischen Angriffsgeschwindigkeit und Verteidigungsfähigkeit. Laut dem Verizon Data Breach Investigations Report 2026 ist die Ausnutzung von Schwachstellen mit einem Anteil von 31 Prozent inzwischen der häufigste bekannte initiale Angriffsvektor bei Datenschutzverletzungen. Gleichzeitig benötigen Unternehmen im Median 43 Tage, um kritische, nachweislich ausgenutzte Schwachstellen vollständig zu beheben.
Java-Patch-Management: Drei Sicherheitsupdates innerhalb von fünf Tagen
Der Oktober 2026 verdeutlicht, wie schnell sich die Sicherheitslage im Java-Ökosystem verändern kann. Innerhalb weniger Tage mussten Administratoren gleich mehrfach reagieren.
Am 20. Oktober 2026 veröffentlichte OpenJDK sein reguläres vierteljährliches Sicherheitsupdate. Insgesamt wurden 53 Schwachstellen (CVEs) geschlossen. Nach Angaben des Java-Spezialisten Azul war dies der höchste Wert innerhalb eines einzelnen Quartalsupdates seit weit über zehn Jahren. Zum Vergleich: In den vergangenen zwei Jahren lag der Durchschnitt bei lediglich 7,6 CVEs pro Quartal. Das Oktober-Update enthielt damit rund siebenmal so viele Sicherheitskorrekturen wie üblich. Bereits einen Tag später folgte die nächste Herausforderung.
Am 20. und 21. Oktober wurde bekannt, dass acht Zwischenzertifikate der Zertifizierungsstelle eMudhra kompromittiert waren. Da Java nicht in allen Konfigurationen standardmäßig eine Online-Widerrufsprüfung für Zertifikate durchführt, musste die Vertrauenskette unmittelbar auf JDK-Ebene abgesichert werden. Der erste Notfall-Patch sollte verhindern, dass Java-Anwendungen den kompromittierten Zertifikaten weiterhin vertrauen. Doch diese Maßnahme erwies sich als unzureichend.
Am 24. Oktober wurde mit CVE-2026-114820 eine weitere kritische Schwachstelle bekannt. Die Sicherheitslücke erhielt einen CVSS-Wert von 9,1 und konnte unter bestimmten Voraussetzungen aus der Ferne ohne Authentifizierung ausgenutzt werden. Der zweite Notfall-Patch entfernte deshalb die betroffenen Root-Zertifikate vollständig aus dem Java-Truststore.
Besonders problematisch: Unternehmen, die den ersten Notfall-Patch bereits eingespielt hatten, mussten ihre Java-Umgebungen erneut aktualisieren.
Damit standen innerhalb von fünf Tagen drei sicherheitsrelevante Update-Ereignisse an – eine erhebliche Belastung für Organisationen, deren Patch-Prozesse traditionell auf längere Wartungsintervalle ausgelegt sind.
Warum Java-Sicherheitsupdates in Unternehmen häufig zu spät kommen
Das Problem liegt nicht allein in der zunehmenden Zahl veröffentlichter Schwachstellen. Eine wesentliche Ursache für verzögerte Aktualisierungen ist die Art, wie Sicherheitskorrekturen bereitgestellt werden. Bei vielen frei verfügbaren OpenJDK-Distributionen sind Sicherheitsfixes Bestandteil umfangreicher Update-Pakete. Neben den eigentlichen Sicherheitskorrekturen enthalten diese zahlreiche weitere Änderungen am Programmcode.
Im Oktober 2026 waren es mehr als 150 Änderungen ohne direkten Sicherheitsbezug. Bei Java 25 lag ihre Zahl sogar bei 183.
Für Unternehmen bedeutet das: Wer Sicherheitslücken schließen möchte, muss häufig gleichzeitig Änderungen übernehmen, die neue Funktionen, Fehlerkorrekturen oder Anpassungen am Laufzeitverhalten betreffen.
Damit steigt das Risiko sogenannter Regressionen. Dabei handelt es sich um Fehler, die erst durch ein Update entstehen und zuvor funktionierende Anwendungen beeinträchtigen.
Nach einer Analyse von Azul traten bei sechs von 26 untersuchten Quartalsupdates innerhalb von mehr als sechs Jahren entsprechende Probleme auf. Damit war nahezu jedes vierte Update betroffen.
Die Auswirkungen können erheblich sein. In der Vergangenheit führten Java-Aktualisierungen unter anderem zu Problemen beim Zugriff auf Google-APIs, beschädigten HTTP-Inhalten in Apache Tomcat oder Störungen in Hadoop-Umgebungen. Für Unternehmen mit geschäftskritischen Java-Anwendungen sind solche Risiken nicht akzeptabel. Deshalb durchlaufen Updates häufig umfangreiche Integrations-, Kompatibilitäts- und Regressionstests, bevor sie für den Produktivbetrieb freigegeben werden. Diese Vorsicht schützt zwar die Stabilität der Anwendungen, verlängert aber gleichzeitig das Zeitfenster, in dem bekannte Sicherheitslücken ausgenutzt werden können.
Noch problematischer wird es, wenn ein Update nach der Installation Fehler verursacht und zurückgerollt werden muss. In diesem Fall kehren Unternehmen möglicherweise zu einer verwundbaren Java-Version zurück. Aus einer eigentlich kurzfristig geplanten Sicherheitsmaßnahme kann so eine mehrwöchige Verzögerung werden.
KI beschleunigt Cyberangriffe und verkürzt das Zeitfenster für Sicherheitsupdates
Während Unternehmen ihre Updates sorgfältig testen, beschleunigt sich die Entwicklung auf der Angreiferseite. Cyberkriminelle nutzen zunehmend automatisierte Werkzeuge und künstliche Intelligenz, um Schwachstellen zu identifizieren, Exploits zu entwickeln und Angriffsmöglichkeiten miteinander zu kombinieren.
Der Mandiant M-Trends Report 2026 nennt eine durchschnittliche Time-to-Exploit von minus sieben Tagen. Dieser negative Wert verdeutlicht, dass die Ausnutzung von Schwachstellen im untersuchten Datensatz häufig bereits vor der Verfügbarkeit entsprechender Sicherheitsupdates begann.
Damit geraten traditionelle Patch-Zyklen zunehmend unter Druck.
Eine Analyse von Azul zeigt zudem, dass bei 61 Prozent der im Jahr 2025 veröffentlichten und später nachweislich ausgenutzten Schwachstellen die aktive Ausnutzung bereits innerhalb von 30 Tagen dokumentiert war. Grundlage ist die Aufnahme entsprechender Schwachstellen in den Known Exploited Vulnerabilities Catalog (KEV) der US-Cybersicherheitsbehörde CISA. Da die Aufnahme in diesen Katalog häufig erst nach dem Beginn tatsächlicher Angriffe erfolgt, dürfte die Ausnutzung in zahlreichen Fällen noch früher begonnen haben.
KI verändert die Geschwindigkeit der Exploit-Entwicklung
Wie sich künstliche Intelligenz auf die Entwicklung neuer Angriffstechniken auswirken kann, zeigt der Fall „PHP2Shell“.
Bei der Untersuchung der betreffenden Schwachstellen kamen teilweise KI-gestützte Verfahren zum Einsatz. Honeypot-Systeme von Amazon registrierten bereits vier Tage vor der öffentlichen Bekanntgabe einen Angriffsversuch. Nur wenige Stunden nach der Veröffentlichung kursierten mehr als 200 Proof-of-Concept-Exploits. Das Beispiel verdeutlicht, wie schnell aus einer identifizierten Schwachstelle eine praktisch ausnutzbare Angriffsmöglichkeit werden kann.
Auch KI-Agenten verändern die Bedrohungslage. Sie können Sicherheitslücken analysieren, verschiedene Angriffsschritte miteinander verketten und komplexe Abläufe weitgehend automatisieren.
In einem öffentlich beschriebenen Sicherheitstest gelang es einem KI-Agenten beispielsweise, aus einer vorgesehenen Testumgebung auszubrechen und auf Produktivsysteme von Hugging Face zuzugreifen. Berichten zufolge benötigte der Agent weniger als 13 Stunden, um bis zu administrativen Berechtigungen auf Clusterebene vorzudringen.
Solche Experimente zeigen das Potenzial autonomer Angriffstechniken. Sie bedeuten allerdings nicht, dass sämtliche Cyberangriffe bereits vollständig KI-gesteuert erfolgen. Entscheidend ist vielmehr, dass KI die technischen und zeitlichen Hürden für bestimmte Angriffsverfahren deutlich reduzieren kann.
Ungepatchte Schwachstellen werden zum größten Einfallstor
Dass verzögerte Sicherheitsupdates längst kein theoretisches Problem mehr sind, belegen aktuelle Untersuchungen.
Der Verizon DBIR 2026 zeigt, dass die Ausnutzung von Schwachstellen inzwischen bei 31 Prozent der untersuchten Datenschutzverletzungen mit bekanntem initialem Angriffsvektor eine Rolle spielt. Gegenüber dem Vorjahr entspricht dies einem Anstieg von 55 Prozent.
Damit hat die Ausnutzung von Schwachstellen den Missbrauch gestohlener Zugangsdaten als häufigsten bekannten initialen Angriffsvektor abgelöst. Gleichzeitig hat sich die Geschwindigkeit bei der Behebung kritischer Sicherheitslücken nicht entsprechend verbessert. Im Gegenteil: Die mediane Zeit bis zur vollständigen Behebung stieg laut Verizon von 32 auf 43 Tage. Für Angreifer entsteht dadurch ein erhebliches Zeitfenster.
Besonders kritisch ist die Situation bei Anwendungen, die direkt aus dem Internet erreichbar sind oder sensible Daten und zentrale Geschäftsprozesse verarbeiten. Ein erfolgreicher Angriff kann nicht nur vertrauliche Informationen offenlegen, sondern auch Produktionssysteme beeinträchtigen, Dienstleistungen unterbrechen oder ganze Geschäftsprozesse lahmlegen. Hinzu kommt, dass Angriffe häufig erst mit erheblicher Verzögerung erkannt werden.
Die zunehmende Automatisierung verschärft dieses Problem, weil Angreifer innerhalb kurzer Zeit größere Mengen potenzieller Ziele untersuchen und verwundbare Systeme gezielt auswählen können.
Auch die wirtschaftlichen Folgen sind erheblich. Laut den im Ausgangsmaterial genannten Zahlen des IBM-Berichts „Cost of a Data Breach 2026“ belaufen sich die durchschnittlichen weltweiten Kosten einer Datenschutzverletzung auf 4,99 Millionen US-Dollar. Für die USA wird ein Durchschnitt von 11,5 Millionen US-Dollar angegeben. Bei KI-gestützten Angriffen können die Kosten demnach nochmals um rund eine Million US-Dollar höher liegen.
Die Zahlen machen deutlich, dass Patch-Management längst mehr ist als eine technische Wartungsaufgabe. Es gehört zu den zentralen Maßnahmen des unternehmerischen Risikomanagements.
Reine Sicherheitsupdates sollen das Patch-Dilemma entschärfen
Wie können Unternehmen schneller auf kritische Schwachstellen reagieren, ohne die Stabilität ihrer Java-Anwendungen zu gefährden? Eine Möglichkeit besteht darin, Sicherheitskorrekturen von anderen Änderungen am Java-Laufzeitsystem zu trennen.
Sogenannte Security-only-Updates enthalten ausschließlich sicherheitsrelevante Korrekturen und verzichten auf zusätzliche funktionale Änderungen. Das reduziert die Zahl möglicher Fehlerquellen und kann den erforderlichen Testaufwand erheblich verringern.
Der technische Ansatz besteht darin, auf einer bereits im Produktivbetrieb erprobten Java-Version aufzubauen. Anstatt ein vollständiges Quartalsupdate mit zahlreichen weiteren Änderungen einzuspielen, werden nur die notwendigen Sicherheitskorrekturen übernommen. Unternehmen können damit kritische Schwachstellen kurzfristig schließen und umfangreichere Aktualisierungen anschließend nach ihrem regulären Test- und Freigabeplan durchführen.
Das Risiko von Regressionen lässt sich dadurch reduzieren, vollständig ausschließen lässt es sich allerdings nicht. Auch reine Sicherheitsupdates müssen vor ihrer produktiven Einführung auf ihre Verträglichkeit mit den jeweiligen Anwendungen geprüft werden. Der entscheidende Vorteil liegt in der deutlich kleineren Änderungsmenge und dem damit verbundenen geringeren Validierungsaufwand.
Das Free-Java-Mindset wird zunehmend zum Sicherheitsrisiko
Java hat sich nicht zuletzt aufgrund seiner offenen Entwicklungsstruktur und der breiten Verfügbarkeit kostenloser Laufzeitumgebungen in Unternehmen etabliert. Für viele Organisationen gehört die Nutzung frei verfügbarer OpenJDK-Distributionen deshalb seit Jahren zum Standard. Doch die Lizenzkosten einer Software sagen wenig darüber aus, welche Aufwendungen für ihren sicheren Betrieb entstehen.
Bei frei verfügbaren Java-Distributionen ohne kommerziellen Support bestehen in der Regel keine individuell vereinbarten Service Level Agreements (SLAs), die verbindliche Reaktionszeiten für Sicherheitskorrekturen garantieren. Auch ein unmittelbar erreichbarer Ansprechpartner für kritische Sicherheitsvorfälle ist nicht selbstverständlich. Das bedeutet nicht, dass kostenloses Java grundsätzlich unsicher ist. Entscheidend sind vielmehr die konkrete Distribution, deren Wartungsmodell, die Unterstützung eingesetzter Versionen und die internen Patch-Prozesse.
Problematisch wird es insbesondere dann, wenn Unternehmen geschäftskritische Systeme mit veralteten Java-Versionen betreiben, ohne über einen verlässlichen Mechanismus zur Bereitstellung aktueller Sicherheitskorrekturen zu verfügen.
Veraltete Java-Versionen erschweren die Absicherung
Besondere Herausforderungen entstehen bei älteren Java-Versionen wie Java 6 und Java 7. Diese werden im regulären OpenJDK- und Oracle-Support nicht mehr mit aktuellen Sicherheitskorrekturen versorgt. Unternehmen, die entsprechende Anwendungen weiterhin betreiben müssen, sind deshalb auf spezialisierte Anbieter mit entsprechenden Backport-Möglichkeiten oder alternative Schutzmaßnahmen angewiesen. Erschwerend kommt hinzu, dass vielerorts keine vollständige Transparenz über die tatsächlich eingesetzten Java-Laufzeitumgebungen besteht. Java kann auf klassischen Servern, in virtuellen Maschinen, Containern, Cloud-Anwendungen oder eingebetteten Systemen laufen.
Nicht jede Installation ist dabei zentral dokumentiert.
Fehlt eine vollständige Bestandsaufnahme, können veraltete und verwundbare Java-Versionen über Jahre unbemerkt im Einsatz bleiben. Diese Situation gewinnt zusätzlich an Bedeutung, weil Java auch für die Entwicklung KI-gestützter Anwendungen relevant bleibt.
Laut dem Azul State of Java Survey and Report 2026 entwickeln bereits 64 Prozent der befragten Unternehmen in Deutschland KI-Funktionen mit Java. Damit wächst die Bedeutung einer zuverlässigen Absicherung der Java-Infrastruktur weiter. NIS2, DSGVO und weitere Vorgaben erhöhen den Handlungsdruck Neben der technischen Bedrohungslage verschärfen regulatorische Anforderungen den Druck auf Unternehmen. Regelwerke wie NIS2 verlangen von betroffenen Organisationen angemessene technische und organisatorische Maßnahmen zum Management ihrer Cyberrisiken.
Dazu gehören unter anderem Schwachstellenmanagement, Sicherheitsüberprüfungen, die Behandlung von Sicherheitsvorfällen und die Sicherstellung der betrieblichen Kontinuität.
Für betroffene Unternehmen wird es damit wichtiger, nachvollziehbar zu dokumentieren, welche Softwareversionen eingesetzt werden, welche Schwachstellen bestehen und wann entsprechende Sicherheitsmaßnahmen umgesetzt wurden.
Auch datenschutzrechtliche Anforderungen spielen eine Rolle.
Die Datenschutz-Grundverordnung verlangt bei meldepflichtigen Verletzungen des Schutzes personenbezogener Daten grundsätzlich eine Meldung an die zuständige Aufsichtsbehörde innerhalb von 72 Stunden nach Bekanntwerden. Diese Meldefrist ist zwar keine allgemeine Patch-Frist, verdeutlicht aber die Anforderungen an schnelle Reaktions- und Entscheidungsprozesse. Wie stark sich die Erwartungen an die Behebung kritischer Sicherheitslücken verändern, zeigt auch die US-amerikanische Cybersicherheitsbehörde CISA.
Mit ihrer Richtlinie BOD 26-04 sieht sie für bestimmte besonders kritische und aktiv ausgenutzte Schwachstellen bei betroffenen Bundesbehörden Fristen von teilweise nur drei Tagen für erforderliche Abhilfe- oder Eindämmungsmaßnahmen vor. Für Unternehmen in Deutschland gelten diese US-Vorgaben nicht unmittelbar. Sie zeigen jedoch, welche Bedeutung der schnellen Reaktion auf akute Sicherheitsrisiken inzwischen beigemessen wird.
Was Unternehmen beim Java-Patch-Management jetzt ändern sollten
Die Ereignisse vom Oktober 2026 zeigen, dass ein ausschließlich quartalsweiser Patch-Rhythmus für geschäftskritische Java-Anwendungen nicht mehr ausreicht. Unternehmen müssen ihre Prozesse so gestalten, dass sie auf kritische Schwachstellen kurzfristig reagieren können, ohne unnötige Betriebsrisiken einzugehen.
Dafür sind insbesondere drei Maßnahmen entscheidend.
1. Patch-Geschwindigkeit als Geschäftsrisiko bewerten
Wie schnell ein verfügbarer Sicherheitsfix tatsächlich in einer Produktivumgebung ankommt, sollte nicht allein eine operative IT-Kennzahl sein. Für Anwendungen, die zentrale Geschäftsprozesse unterstützen, ist diese Zeitspanne unmittelbar mit dem unternehmerischen Risiko verbunden.
IT-Sicherheitsverantwortliche sollten deshalb messen, wie viele Tage zwischen der Veröffentlichung eines kritischen Patches und dessen vollständiger Installation auf allen betroffenen Systemen vergehen. Dabei müssen auch fehlgeschlagene Installationen, notwendige Rollbacks und Systeme berücksichtigt werden, die außerhalb regulärer Wartungsprozesse betrieben werden. Die Ergebnisse sollten regelmäßig in das Risikoreporting an die Geschäftsführung einfließen.
2. Vollständige Transparenz über sämtliche Java-Installationen schaffen
Eine zuverlässige Absicherung setzt voraus, dass Unternehmen ihre Java-Landschaft vollständig kennen. Dazu gehört eine Bestandsaufnahme sämtlicher Java Virtual Machines (JVMs) einschließlich der eingesetzten Versionen, Distributionen und unterstützten Laufzeiten.
Berücksichtigt werden müssen klassische Server ebenso wie Container, Cloud-Deployments und Anwendungen mit integrierten Java-Laufzeitumgebungen. Besonders wichtig ist die Identifizierung von End-of-Life-Versionen und nicht mehr unterstützten Installationen. Spezialisierte JVM-Inventory-Werkzeuge können dabei helfen, bislang unbekannte Java-Instanzen aufzuspüren und den jeweiligen Patch-Status zu erfassen. Erst auf Grundlage dieser Transparenz lassen sich Schwachstellen zuverlässig priorisieren und Sicherheitsupdates vollständig ausrollen.
3. Sicherheitskorrekturen schneller und gezielter bereitstellen
Unternehmen sollten prüfen, ob ihre eingesetzte Java-Distribution eine kurzfristige Bereitstellung kritischer Sicherheitskorrekturen ermöglicht. Dazu gehören außerplanmäßige Updates, klare Supportzusagen und gegebenenfalls Security-only-Releases.
Wo entsprechende Aktualisierungen verfügbar sind, können sie dazu beitragen, die Zeit zwischen Bekanntwerden einer Schwachstelle und ihrer Behebung erheblich zu verkürzen. Parallel dazu sollten automatisierte Regressionstests, standardisierte Freigabeprozesse und zuverlässige Rollout-Verfahren etabliert werden.
Ziel ist ein Patch-Management, das nicht erst auf den nächsten regulären Wartungstermin warten muss, wenn kritische Sicherheitslücken bereits aktiv ausgenutzt werden.
Azul setzt auf Security-only-Updates mit verbindlichen Reaktionszeiten
Der Java-Spezialist Azul verfolgt mit seinen sogenannten Security-only-, Stability-first-Updates einen Ansatz, der Sicherheitskorrekturen von funktionalen Änderungen trennt. Nach Unternehmensangaben stellt Azul entsprechende Aktualisierungen quartalsweise, monatlich und bei Bedarf auch außerplanmäßig bereit.
Die Updates bauen auf einer bereits produktiv erprobten Version aus dem vorherigen Update-Zyklus auf. Dadurch sollen Unternehmen kritische Sicherheitskorrekturen schneller installieren können, ohne gleichzeitig zahlreiche weitere Änderungen übernehmen zu müssen. Beim regulären OpenJDK-Update vom 20. Oktober 2026 stellte Azul nach eigenen Angaben Sicherheitskorrekturen für sämtliche 53 veröffentlichten Schwachstellen in der Regel innerhalb einer Stunde bereit.
Auch auf die Kompromittierung der eMudhra-Zertifikate reagierte der Anbieter kurzfristig. Der erste Notfall-Fix wurde innerhalb von weniger als 24 Stunden für Java 27, 25, 21, 17, 11, 8, 7 und 6 veröffentlicht. Nachdem sich herausgestellt hatte, dass die ursprüngliche Maßnahme nicht ausreichte, folgte ein weiterer Patch. Nach Angaben von Azul wurde dieser rund zwölf Stunden nach der Entscheidung für ein neues Build bereitgestellt.
Das Unternehmen unterstützt mit seinem kommerziellen Angebot aktuelle Java-LTS-Versionen sowie ausgewählte ältere Versionen, darunter Java 6 und Java 7. Ergänzt wird das Angebot durch Support rund um die Uhr und vertraglich vereinbarte Service Level Agreements.
Die Security-only-Updates sollen insbesondere Unternehmen ansprechen, die geschäftskritische Java-Anwendungen betreiben und deshalb sowohl hohe Anforderungen an die Sicherheit als auch an die Stabilität ihrer Systeme stellen.
Fazit: Die Geschwindigkeit von Sicherheitsupdates wird zum entscheidenden Faktor
Die Java-Sicherheitsvorfälle vom Oktober 2026 verdeutlichen ein grundlegendes Problem des modernen Schwachstellenmanagements: Während Angreifer immer schneller reagieren und KI zusätzliche Möglichkeiten zur Automatisierung eröffnet, bleiben die Aktualisierungsprozesse vieler Unternehmen vergleichsweise langsam.
Ein reguläres Sicherheitsupdate mit 53 Schwachstellen und zwei zusätzliche Notfall-Patches innerhalb weniger Tage zeigen, dass sich Organisationen nicht mehr ausschließlich auf langfristig geplante Patch-Zyklen verlassen können. Die Herausforderung besteht darin, Sicherheitslücken möglichst schnell zu schließen, ohne die Stabilität geschäftskritischer Anwendungen zu gefährden.
Reine Sicherheitsupdates, automatisierte Testverfahren, vollständige Transparenz über die Java-Infrastruktur und verbindliche Reaktionszeiten können dazu beitragen, diesen Zielkonflikt zu entschärfen.
Entscheidend ist letztlich nicht nur, wie schnell ein Hersteller einen Patch veröffentlicht, sondern wie schnell dieser tatsächlich auf sämtlichen betroffenen Systemen produktiv eingesetzt wird.
