ELS für Apache Velocity: Auch nach dem EOL sicher bleiben

Wichtigste Erkenntnisse

• Abhängigkeiten vergrößern Ihre Angriffsfläche: Das Risiko durch Velocity, dessen Lebenszyklus beendet ist, kann über die Engine- und Tools-JARs hinaus auf anfällige Laufzeitabhängigkeiten wie commons-collections 3.2.1 und, sofern verwendet, Log4j 1.x ausgedehnt werden.
• Überstürzte Migrationen sind kostspielig und riskant: Wenn man den Umstieg von Engine 1.7 auf die 2.x-Reihe unter dem Druck von Compliance-Fristen vorantreibt, tauscht man Sicherheitsrisiken gegen neue Regressionsrisiken ein.
• Das Ende des Supports für Apache Velocity muss nicht das Ende der Sicherheit bedeuten: TuxCare ELS bietet weiterhin Sicherheitspatches für Velocity-Versionen, deren Lebenszyklus abgelaufen ist, während Sie eine kontrollierte Migration nach Ihrem eigenen Zeitplan planen.

Falls Apache Velocity irgendwo im Abhängigkeitsgraph Ihrer Java-Anwendung auftaucht – und dies ist in älteren Enterprise-Java-Umgebungen nach wie vor häufig der Fall –, sollten Sie sich über den End-of-Life-Status (EOL) im Klaren sein, bevor ein Sicherheitsscanner oder ein Compliance-Audit Sie dazu zwingt, sich mit diesem Thema auseinanderzusetzen.

Velocity Engine 1.7, die letzte Version der 1.x-Reihe, hat seit November 2010 keine neue Upstream-Version mehr erhalten. Auch für Velocity Tools 2.0 gab es seit Mai 2010 keine neue Version mehr, während die Apache-Entwicklung in den Reihen Engine 2.x und Tools 3.x fortgesetzt wurde. Der CVE-Eintrag für beide älteren Komponenten verdeutlicht die Sicherheitslücke, und der Einsatz dieser Komponenten in der Produktion ohne entsprechende Patches hat konkrete Auswirkungen auf die Einhaltung von Compliance-Vorgaben.

In diesem Artikel wird erläutert, was das Ende des Supports (EOL) für Apache Velocity in der Praxis bedeutet, wie die Sicherheitsbilanz aussieht und wie TuxCare ELS für Apache Velocity Ihrem Unternehmen einen Weg bietet, die Sicherheit zu gewährleisten, ohne eine Migration zu erzwingen, auf die Ihre Teams noch nicht vorbereitet sind.

Was ist Apache Velocity und warum wird es immer noch so häufig eingesetzt?

Apache Velocity ist eine Java-basierte Template-Engine, die die Velocity Template Language (VTL) nutzt und es Entwicklern ermöglicht, dynamische Anweisungen in Klartext-Templates einzubetten. Zur Laufzeit führt die Velocity-Engine die Templates mit Java-Datenmodellen zusammen, um die gerenderte Ausgabe zu erzeugen. Durch die Trennung der Darstellung von der Anwendungslogik entwickelte sich Velocity in den 2000er- und bis in die 2010er-Jahre hinein zu einer weit verbreiteten Template-Lösung in Java-Unternehmensanwendungen.

Das Apache Velocity-Projekt umfasst zwei Hauptkomponenten mit separaten Versionszweigen und Release-Verläufen:

• Velocity Engine: Die zentrale Laufzeitumgebung für Vorlagen, die das Parsen von VTL, die Ausführung von Direktiven, die Makroauswertung und die Auflösung von Kontextvariablen übernimmt.
• Velocity-Tools: Auf der Engine basierende Web-Framework-Integrationen, darunter VelocityViewServlet für servletbasierte Anwendungen sowie Toolboxen für die Datumsformatierung, die URL-Generierung und gängige Hilfsfunktionen für die Ansichtsebene.

Velocity war tief in Apache Struts, älteren Spring-MVC-Konfigurationen, Apache Turbine und Java-CMS-Plattformen eingebettet und fand oft als transitive Abhängigkeit in mehreren Ebenen Tiefe Eingang in Anwendungen. Es wurde zudem zu einer gängigen Wahl für E-Mail-Vorlagensysteme und Berichtsgeneratoren, die nur selten modernisiert werden. Diese Zuverlässigkeit kann zu einer blinden Stelle hinsichtlich des Endes der Lebensdauer (EOL) führen: Velocity bleibt oft gerade deshalb in langlebigen Anwendungen eingebettet, weil es weiterhin funktioniert, sodass es leicht übersehen wird, bis ein Schwachstellenscanner es identifiziert.

Apache Velocity EOL: Der Versionslebenszyklus

Apache Velocity veröffentlicht Fehlerbehebungen in Form neuer Versionen, während ältere Versionen in die Apache-Archive verschoben werden. Daher ist es für die Risikobewertung Ihres gesamten Stacks unerlässlich, den Zeitplan der Komponente zu kennen.

Velocity Engine 1.7 war die letzte Version der 1.x-Reihe und wurde zur Standardversion von Velocity, die in einer ganzen Generation von Java-Frameworks integriert wurde. Die Engine-2.x-Reihe führte gegenüber 1.x API-Änderungen ein, die Kompatibilitätsbrüche verursachten, und viele Upstream-Frameworks aktualisierten ihre festgelegte Velocity-Abhängigkeit jahrelang nicht, sodass 1.7 bis weit in die 2020er Jahre hinein weit verbreitet blieb. Auch für Velocity Tools 2.0 gab es seit 2010 keine neue Version mehr; beide Komponenten wurden durch neuere Hauptversionen abgelöst und erhalten keine neuen Releases mehr in ihren jeweiligen Versionsreihen.

Apache verweist Nutzer auf seine aktuellen Releases und archiviert ältere Versionen, ohne jedoch ein veröffentlichtes Programm zur Sicherheitspflege oder zum Backport von Patches für die Produktreihen „Engine 1.x“ oder „Tools 2.x“ anzubieten. Dadurch fehlt es Unternehmen, die diese Versionen einsetzen, an einer dokumentierten Quelle für neue Sicherheitskorrekturen seitens des Upstream-Entwicklers – genau diese Lücke soll TuxCare ELS für Apache Velocity schließen.

Die CVE-Historie, die das EOL-Risiko von Apache Velocity bestimmt

Das Ende des Lebenszyklus (EOL) von Apache Velocity bedeutet nicht, dass in den EOL-Versionen keine Sicherheitslücken mehr entdeckt werden; es bedeutet lediglich, dass diese Versionen keine Upstream-Korrekturen mehr erhalten. Template-Engines können besonders attraktive Angriffsziele sein, da sie häufig Vorlagen oder Daten verarbeiten, die von Benutzern im Ausführungskontext einer Anwendung beeinflusst werden. In anfälligen Konfigurationen können Schwachstellen an der Schnittstelle zwischen der Template-Logik und der Anwendungslaufzeit schwerwiegende Folgen wie die Remote-Code-Ausführung nach sich ziehen – und der „End-of-Life“-Status beseitigt genau das Sicherheitsnetz der Upstream-Patches, das vor dieser Art von Angriffen schützt.

CVE-2020-13936: Umgehung der Sandbox und Remote-Codeausführung

CVE-2020-13936 (NVD CVSS 3.1: 8,8 – Hoch) betrifft Velocity Engine-Versionen bis einschließlich 2.2, womit die gesamte 1.x-Reihe betroffen ist. Ein Angreifer, der Velocity-Vorlagen ändern kann, ist möglicherweise in der Lage, beliebigen Java-Code oder Systembefehle mit den Berechtigungen des Kontos auszuführen, unter dem der Servlet-Container läuft. Diese serverseitige Schwachstelle durch Template-Injection wurde vom GitHub Security Lab als GHSL-2020-048 gemeldet und anschließend in Sicherheitshinweisen mehrerer nachgelagerter Anbieter und Distributionen behandelt.

CVE-2020-13936 wurde in Velocity Engine 2.3 behoben, das im Februar 2021 veröffentlicht wurde – mehr als ein Jahrzehnt nach der letzten 1.x-Version, die im November 2010 erschienen war. Als diese Sicherheitslücke im März 2021 öffentlich bekannt wurde, war seit der Veröffentlichung von Engine 1.7 bereits mehr als zehn Jahre vergangen, ohne dass ein Upstream-Release erschienen war, und für die 1.x-Reihe wurde nie ein Fix veröffentlicht.

Für Organisationen, die die nicht mehr unterstützte Engine 1.7 einsetzen, bestehen die direktesten Abhilfemaßnahmen darin, ein Upgrade auf eine korrigierte, unterstützte Version durchzuführen oder einen vom Anbieter bereitgestellten Backport-Patch von einem Dienstleister wie TuxCare anzuwenden. Die Einschränkung der Berechtigungen zum Hochladen oder Bearbeiten von Velocity-Vorlagen kann das Risiko verringern, doch solche Kontrollen ersetzen keine Patches, solange die anfällige Funktionalität weiterhin zugänglich ist.

Das verborgene Risiko: Der Abhängigkeits-Fußabdruck von Velocity

Velocity Engine 1.7 ist für allgemeine Laufzeitfunktionen auf commons-collections 3.2.1 und commons-lang 2.4 angewiesen; Jakarta ORO 2.0.8 wird nur für bestimmte Funktionen benötigt, wie beispielsweise das automatische Escaping von Referenzen. Log4j 1.x ist ein optionales Logging-Backend, das nur dann verwendet wird, wenn Anwendungen Velocity so konfigurieren, dass die Protokollierung über Log4j erfolgt. Zwei Komponenten in diesem Ökosystem weisen CVSS-Werte von 9,8 (kritisch) auf:

commons-collections 3.2.1: CVE-2015-7501 (CVSS 9,8 – Kritisch). Diese Version kann Teil von Java-Deserialisierungs-Gadget-Ketten werden, wenn eine Anwendung nicht vertrauenswürdige Daten über einen anfälligen Codepfad deserialisiert – dieselbe Art von Exploit, die bei ihrer Bekanntgabe im Jahr 2015 WebSphere, JBoss, WebLogic und Jenkins heimgesucht hat. Velocity Engine 1.7 verwendet die betroffene Version, wobei die tatsächliche Ausnutzbarkeit davon abhängt, wie die umgebende Anwendung mit serialisierten Objekten umgeht.

Log4j 1.x: CVE-2019-17571 (CVSS 9,8 – kritisch). Log4j 1.x hat im August 2015 das Ende seines Lebenszyklus erreicht, und für den gesamten 1.x-Zweig werden keine Patches für später bekannt gewordene CVEs mehr bereitgestellt. Anwendungen, die Log4j 1.x zusammen mit Velocity verwenden, sind möglicherweise der Sicherheitslücke CVE-2019-17571 ausgesetzt – einer Schwachstelle, die die Ausführung von Code aus der Ferne ermöglicht –, sofern sie die anfällige SocketServer-Komponente aktivieren und nach außen exponieren.

Schwachstellenscanner ermitteln in diesem Abhängigkeitsbaum Befunde, für die es keine offizielle Korrektur vom Upstream-Anbieter gibt. TuxCare ELS für Apache Velocity erweitert den Erfassungsbereich über die Velocity-Artefakte der obersten Ebene hinaus auf unterstützte Komponenten im transitiven Abhängigkeitsbaum.

Einhaltung von Vorschriften und gesetzlichen Bestimmungen

Gemäß PCI DSS v4.0 schreibt Anforderung 6.3.3 vor, dass Patches und Updates für Schwachstellen, die in der Umgebung einer Organisation als kritisch eingestuft werden, innerhalb eines Monats nach ihrer Veröffentlichung installiert werden müssen; andere relevante Sicherheitsupdates müssen innerhalb der Fristen installiert werden, die im Rahmen der Risikobewertung der Organisation festgelegt wurden (gemäß Anforderung 6.3.1).

Da der PCI DSS nicht automatisch jede Schwachstelle mit einem CVSS-Wert von 7,0 oder höher als kritisch einstuft, hängen die Auswirkungen der seit März 2021 öffentlich bekannten Schwachstelle CVE-2020-13936 auf die Compliance von der dokumentierten Risikoeinstufung, der Gefährdung und den Kontrollmaßnahmen der Organisation ab. Andere Rahmenwerke und Sicherheitsprogramme, darunter HIPAA, SOC 2 Typ II und FedRAMP, können ebenfalls von Organisationen verlangen, relevante Schwachstellen zu identifizieren, zu bewerten und zu beheben, wobei deren Anforderungen jedoch separat geprüft werden sollten.

ELS für Apache Velocity unterstützt Unternehmen dabei, relevante Sicherheitslücken innerhalb vorhersehbarer Zeiträume zu beheben, ohne eine sofortige Migration erzwingen zu müssen.

Die Risiken einer überstürzten Migration zu Apache Velocity

Der Druck, auf die Feststellungen zum Ende der Lebensdauer von Apache Velocity zu reagieren, ist groß. SCA-Tools generieren Fehlermeldungen, Auditoren stellen gezielte Fragen, und die Fristen für die Einhaltung der Vorschriften lassen sich aufgrund begrenzter technischer Kapazitäten nicht verschieben. Teams, die das Ende der Lebensdauer von Apache Velocity gut bewältigen, behandeln die Migration als geplantes technisches Projekt mit einer vollständigen Bestandsaufnahme der Vorlagen, Regressionstests und einem definierten Rollback-Pfad.

Was passiert, wenn man es überstürzt?

Wenn Teams die Migration in einen unrealistischen Zeitrahmen pressen, läuft es auf vorhersehbare Weise schief:

• Erhöhte Support-Belastung: Fehler, die während der verkürzten Testphase nicht entdeckt wurden, treten in der Produktionsumgebung sofort auf. Die Support-Teams werden mit Tickets über fehlerhafte Vorlagenausgabe und verändertes Verhalten in E-Mail- oder Berichts-Pipelines überhäuft, wobei die meisten auf VTL- oder API-Unterschiede zwischen Engine 1.x und 2.x zurückzuführen sind, die aufgrund des engen Zeitplans nie vollständig validiert wurden.
• Systeminstabilität: Einige Änderungen an der Abhängigkeits-API treten erst unter Produktionslast zutage. Zeitweise auftretende Fehler beim Rendern von Vorlagen, Abweichungen bei der Ausgabeformatierung durch aktualisierte Tools-Toolboxen sowie ein geändertes Fehlerbehandlungsverhalten des VelocityViewServlet führen zu Fehlern, die schwer zu reproduzieren und aufwendig zu diagnostizieren sind.
• Anhäufung technischer Schulden: Konfigurationsunterschiede werden in den Initialisierungscode der Anwendung integriert, anstatt auf Bibliotheksebene behoben zu werden. Verhaltensänderungen von VTL zwischen den Versionen 1.x und 2.x werden lokal auf undokumentierte Weise umgangen. Das EOL-Problem wird aufgeschoben, nicht gelöst, und die aufgelaufenen Schulden verteuern später eine ordnungsgemäße Migration.
• Ungeplante Kosten: Notfall-Entwicklungsstunden, verzögerte Feature-Veröffentlichungen und die Opportunitätskosten, die entstehen, wenn Ihre besten Entwickler sich mit der Behebung von Kompatibilitätsproblemen bei Abhängigkeiten beschäftigen, anstatt neue Funktionen zu entwickeln, übersteigen in der Regel die Kosten, die ein erweiterter Lebenszyklus-Support für den gesamten Zeitraum der Migrationsplanung verursacht hätte.

Möglichkeiten für Sicherheit und die Einhaltung von Vorschriften

Unternehmen, die Apache Velocity-Versionen verwenden, deren Lebenszyklus bald endet, haben drei Möglichkeiten. Die ersten beiden erfordern erheblichen technischen Aufwand und einen längeren Zeitaufwand. Die dritte Möglichkeit schließt die Sicherheitslücke schnell, während Ihre Teams die Migration sorgfältig planen.

Option 1: Migration auf Velocity Engine 2.4.1 und Tools 3.1

Die langfristige Lösung besteht darin, auf die aktuellen Upstream-Versionen umzusteigen – zum Zeitpunkt der Erstellung dieses Artikels sind dies Velocity Engine 2.4.1 und Velocity Tools 3.1. Durch den Wechsel zu aktiv gepflegter Software wird das Risiko eines Produktendes (EOL) beseitigt.

Die Migration hat erhebliche Auswirkungen: Jede Engine-Version seit 2.1 (März 2019) – einschließlich 2.4.1 – erfordert mindestens Java 8 als Laufzeitumgebung. Daher müssen Unternehmen, die Velocity 1.7 auf älteren JVM-Umgebungen einsetzen, möglicherweise ein Java-Upgrade durchführen, bevor sie auf eine moderne 2.x-Version migrieren können. Die API-Änderungen zwischen Engine 1.7 und 2.x – entfernte Klassen, eine überarbeitete ResourceLoader-Konfiguration sowie geänderte Schnittstellen für Introspektion und Protokollierung – erfordern möglicherweise Codeänderungen in Anwendungen, die Velocity über dessen Java-APIs erweitern oder konfigurieren. Tools 3.1 erweitert den Umfang zusätzlich durch eine Umstrukturierung der Pakete und eine überarbeitete Servlet-Integration.

Bei Unternehmensanwendungen mit mehreren Velocity-Integrationspunkten kann die Migration monatelange Bestandsaufnahmen, Codeänderungen und Regressionstests erfordern.

Option 2: Velocity durch eine alternative Template-Engine ersetzen

Einige Organisationen nutzen den EOL-Meilenstein von Apache Velocity als Anlass, um Alternativen zu prüfen: Thymeleaf, FreeMarker, Pebble und Mustache werden alle aktiv weiterentwickelt. Der Austausch der Template-Engine ist mit größeren Umstellungen verbunden als ein Upgrade innerhalb derselben Version; Templates müssen in der Regel neu geschrieben oder an die Syntax der neuen Engine angepasst werden, und jeder betroffene Ausgabepfad muss erneut getestet werden. Dies ist ein realistisches langfristiges Ziel, jedoch keine Lösung für einen unmittelbar anstehenden Verstoß gegen die Compliance-Vorgaben aufgrund des End-of-Life von Apache Velocity.

Option 3: Nutzung des unbefristeten Lebenszyklus-Supports während der Migration

Mit dem „Endless Lifecycle Support“ (ELS) von TuxCare für Apache Velocity können Sie die Sicherheit gewährleisten, ohne eine Migration durchführen zu müssen, für die Ihr Team noch nicht bereit ist. Sie nutzen weiterhin Ihre aktuelle Velocity-Version und profitieren dabei von einer kontinuierlichen Versorgung mit Sicherheitspatches. Genau für diese Lücke wurde der ELS für Apache Velocity konzipiert: den Zeitraum zwischen dem Ende des offiziellen Supports und dem Zeitpunkt, zu dem Ihr Unternehmen eine geplante, kontrollierte Migration tatsächlich abgeschlossen hat.

Die einfache Lösung: TuxCare ELS für Apache Velocity

TuxCare bietet „Endless Lifecycle Support“ für Apache Velocity-Versionen, deren Lebenszyklus abgelaufen ist, und sorgt dafür, dass Ihre aktuelle Bereitstellung durch Sicherheitspatches abgesichert bleibt, die als direkt einsetzbare JAR-Ersatzdateien über Ihre bestehende Maven- oder Gradle-Toolchain bereitgestellt werden. TuxCare hat im gesamten Open-Source-Ökosystem bereits mehr als 220.000 Sicherheitspatches bereitgestellt.

Vollständige Abdeckung des Abhängigkeitsbaums

TuxCare ELS für Apache Velocity geht über die JAR-Dateien der Engine und der Tools hinaus und umfasst auch unterstützte Komponenten im transitiven Abhängigkeitsbereich, darunter commons-collections 3.2.1 (CVE-2015-7501, CVSS 9,8 – kritisch) sowie – für Anwendungen, die diese nutzen – Log4j 1.x (CVE-2019-17571, CVSS 9,8 – kritisch).

Optimierter, automatisierter Patching-Prozess

TuxCare überwacht rund um die Uhr das NVD, die Sicherheitshinweise von Apache, die Sicherheits-Feeds von GitHub sowie die Informationskanäle der Anbieter. Sobald eine relevante CVE identifiziert wird, portiert TuxCare den Fix mithilfe algorithmischer und KI-gestützter Automatisierung auf die unterstützten Versionen zurück, wobei Sicherheitsexperten jeden Patch vor der Veröffentlichung validieren. Jedes Update durchläuft Integritäts-, Funktions- und Regressionstests, bevor es in Ihre Repositories gelangt. Ausführliche technische Details finden Sie im Whitepaper „Open-Source-Patching-Prozess von TuxCare“.

Nahtlose Integration

Unabhängig davon, ob Sie Velocity über Maven Central oder einen privaten Repository-Mirror beziehen, können Sie Ihre Update-Quelle mit nur geringen Änderungen an Ihrer Repository-Konfiguration auf das sichere Repository von TuxCare umstellen. Die gepatchten JARs sind als direkte Ersatzkomponenten konzipiert, die die bestehende API und Konfiguration beibehalten und gleichzeitig zurückportierte Sicherheitskorrekturen integrieren, sodass die meisten Teams sie über ihre bestehenden Maven- oder Gradle-Workflows und CI/CD-Pipelines nutzen können.

SLA-gestützte schnelle Reaktion

Wenn neue Sicherheitslücken bekannt werden, die unterstützte Velocity-Versionen betreffen, deren Lebenszyklus bereits abgelaufen ist – sei es in der Engine, in den Tools oder in den abgedeckten Abhängigkeiten –, stellt TuxCare Patches bereit, die durch Service-Level-Vereinbarungen abgesichert sind. Dabei werden Sicherheitslücken mit hohem und kritischem Schweregrad (CVSS 7.0 und höher) innerhalb von 14 Tagen nach ihrer öffentlichen Bekanntgabe behoben.

Kosteneffiziente Aufrechterhaltung der Sicherheit

Die Kosten für TuxCare ELS betragen nur einen Bruchteil dessen, was eine Notfallmigration unter dem Druck von Compliance-Fristen kostet. Sie planen eine wohlüberlegte Migration auf Velocity Engine 2.4.1 und Tools 3.1, wenn dies mit den Kapazitäten Ihres Teams vereinbar ist – einschließlich der Zeit, die erforderlich ist, um die Auswirkungen aller transitiven Abhängigkeiten zu erfassen und jeden Ausgabepfad der Vorlagen zu validieren. Oder Sie nutzen ELS, um die Abdeckung durch Sicherheitspatches aufrechtzuerhalten und Ihre Compliance-Bemühungen zu unterstützen, während Sie diese Entscheidungen nach Ihrem eigenen Zeitplan treffen.

Lassen Sie nicht zu, dass das Ende der Lebensdauer von Apache Velocity Ihre Java-Anwendungen gefährdet

Das Ende des Supports (EOL) für Apache Velocity bedeutet nicht, dass Ihre Anwendung sofort gefährdet ist. Es bedeutet jedoch, dass Komponenten mit bekannten Sicherheitslücken möglicherweise weiterhin in Ihrem Produktions-Abhängigkeitsbaum verbleiben – darunter eine Velocity-Sicherheitslücke mit einem CVSS-Wert von 8,8 (Hoch) sowie Sicherheitslücken in Abhängigkeiten mit einem CVSS-Wert von bis zu 9,8 (Kritisch) – und dass das Upstream-Projekt diese nicht beheben wird.

Ob die einzelnen Schwachstellen ausgenutzt werden können, hängt von der Konfiguration Ihrer Anwendung, den Datenflüssen und den Sicherheitsmaßnahmen ab. Doch jeder Monat, der nach der Veröffentlichung einer CVE-Meldung zu einer Version, deren Support ausgelaufen ist, verstreicht, ist ein Monat, in dem das Sicherheitsrisiko weiterhin besteht.

Die richtige Reaktion auf das Ende des Lebenszyklus von Apache Velocity hängt vom Zeitplan und den technischen Kapazitäten Ihres Unternehmens ab. Wenn Sie jetzt auf Engine 2.4.1 und Tools 3.1 umsteigen können, ist dies der richtige Weg. Sollte ein sofortiges Upgrade aufgrund der Komplexität Ihrer Velocity-Integration nicht praktikabel sein, bietet TuxCare ELS für Apache Velocity weiterhin Sicherheitspatches, während Sie die Migration sorgfältig planen und durchführen.

Falls das Ende des Lebenszyklus von Apache Velocity derzeit auf Ihrer Sicherheits-Agenda steht, besuchen Sie den „Endless Lifecycle Support für Open-Source-Software“ von TuxCare und erfahren Sie, wie erweiterter Support Ihren gesamten Open-Source-Stack schützen kann.

Zusammenfassung

Artikel Name

ELS für Apache Velocity: Auch nach dem EOL sicher bleiben

Beschreibung

Verwenden Sie Apache Velocity, dessen Lebenszyklus bald endet? Mit TuxCare ELS für Apache Velocity bleiben Ihre Java-Anwendungen auf dem neuesten Stand und konform, ohne dass eine überstürzte Migration erforderlich ist.

Autor

Muzzammil Hasann

Name des Herausgebers

TuxCare

Logo des Herausgebers