ELS für Jackson: Was das Ende der Lebensdauer von Jackson Databind für Ihre Java-Anwendungen bedeutet

Wichtigste Erkenntnisse

• Das Ende der Lebensdauer von Jackson vergrößert Ihre Angriffsfläche: Jackson Databind ist von Jackson Core abhängig, das eine echte CVE-Historie aufweist, sodass durch das EOL die JSON-Parsing-Ebene ungeschützt bleibt.
• Überstürzte Upgrades sind kostspielig: Änderungen an der Minor-Version von Jackson können sich auf die Deserialisierung, Annotationen und das Verhalten des ObjectMappers auswirken und erfordern eine koordinierte Validierung über alle Anwendungen hinweg.
• EOL bedeutet nicht das Ende der Sicherheit: TuxCares ELS für Jackson bietet fortlaufende Patches für nicht mehr unterstützte Jackson-Versionen, während Sie das Upgrade nach Ihrem eigenen Zeitplan durchführen.

ELS für Jackson wurde ins Leben gerufen, weil Jackson Databind eine der am häufigsten in der Produktion eingesetzten Java-Bibliotheken ist und gleichzeitig eines der am häufigsten übersehenen EOL-Risiken in Anwendungsstacks von Unternehmen darstellt. Jackson ist der De-facto-Standard für die JSON-Verarbeitung auf der JVM. Es übernimmt die Serialisierung und Deserialisierung über REST-APIs, Message Broker, Microservices und Datenpipelines hinweg in praktisch jeder Java-Anwendung, die im letzten Jahrzehnt entwickelt wurde. Wenn eine Jackson-Version das Ende ihrer Lebensdauer erreicht, erhält jede davon abhängige Anwendung keine Sicherheitspatches mehr für die Bibliothek, die jede von ihr verarbeitete JSON-Nutzlast verarbeitet.

Das FasterXML-Team pflegt Jackson im Rahmen eines Langzeit-Support-Modells, doch Teams, die weiterhin ältere, nicht mehr weiterentwickelte Zweige nutzen, sind Sicherheitsrisiken ausgesetzt, selbst wenn auf den aktuellen Zweigen neuere Patch-Versionen verfügbar sind. Unternehmen, die Jackson 2.17, 2.16, 2.15 oder einen noch älteren, nicht mehr weiterentwickelten Zweig einsetzen, arbeiten ohne Sicherheitsunterstützung durch den Upstream-Entwickler, und die CVE-Historie von Jackson Core und Jackson Databind macht dieses Risiko konkret und messbar.

In diesem Beitrag wird erläutert, wie der Release-Zyklus von Jackson tatsächlich funktioniert, was das Ende der Unterstützung (EOL) von Jackson Databind in Bezug auf Sicherheit und Compliance konkret bedeutet und warum ELS für Jackson der direkteste Weg ist, diese Lücke zu schließen, während Sie Ihr Upgrade nach Ihrem eigenen Zeitplan planen.

Was ist der Release-Zyklus von Jackson?

Jackson folgt einem Modell für langfristigen Support, ähnlich wie es beim JDK bei der Versionsverwaltung gehandhabt wird. Das Verständnis dieses Modells ist unerlässlich, um genau zu wissen, wann für Ihre Jackson-Version keine Patches mehr bereitgestellt werden und ob die von Ihnen verwendete Version noch unterstützt wird.

LTS- und Nicht-LTS-Zweige. Nicht jede Jackson-Minor-Version ist eine LTS-Version. Etwa jede dritte Minor-Version wird zum Zeitpunkt ihrer Erstveröffentlichung als LTS-Version ausgewiesen, basierend auf dem Zeitpunkt und der Stabilität der Veröffentlichung. LTS-Zweige bleiben mindestens zwei Jahre lang offen. Nicht-LTS-Zweige bleiben nur so lange offen, bis die nächste LTS-Version veröffentlicht wird.

Was „geschlossen“ bedeutet. Wenn ein Jackson-Zweig geschlossen wird, stellt das FasterXML-Team die Veröffentlichung von Patches dafür ein. Keine Sicherheitskorrekturen, keine Fehlerbehebungen – der Zweig ist eingefroren. Im Projekt-Wiki werden geschlossene Zweige ausdrücklich beschrieben: Organisationen, die eine geschlossene Version nutzen, sind auf sich allein gestellt.

Der aktuelle Stand der Support-Maßnahmen. Stand Anfang 2026 werden folgende Zweige aktiv gepflegt:

• 2.18 (LTS), veröffentlicht am 26. September 2024, offen für Backports und Patch-Veröffentlichungen
• 2.21 (LTS), veröffentlicht am 18. Januar 2026, offen für Patch-Veröffentlichungen
• 3.1 (LTS), veröffentlicht am 23. Februar 2026

Alle anderen Zweige wurden geschlossen. Jackson 2.17 wurde im August 2025 geschlossen, als 2.20.0 veröffentlicht wurde. Jackson 2.19 wurde im Oktober 2025 geschlossen. Jackson 2.20 wurde im Januar 2026 geschlossen, als 2.21.0 (LTS) veröffentlicht wurde. Jackson 2.16 wurde im April 2025 geschlossen. Jackson 2.15 wurde im September 2024 eingestellt. Jackson 2.13 und 2.14 wurden beide im November 2023 eingestellt. Jede Anwendung, die auf diesen Versionen läuft, nutzt eine EOL-Version von Jackson.

Die Anforderung an die Versionsnummer der Kernkomponente. Die drei Kernkomponenten von Jackson – Jackson Annotations, Jackson Core und Jackson Databind – müssen immer dieselbe Nebenversion aufweisen. Sie können beispielsweise Jackson Core 2.18.x nicht mit Jackson Databind 2.17.x kombinieren. Diese enge Kopplung bedeutet, dass ein EOL-Ereignis für Jackson Databind gleichzeitig auch ein EOL-Ereignis für Jackson Core ist und umgekehrt.

Die Mindestanforderungen an Java. Jackson 2.13 war der letzte 2.x-Zweig, der JDK 6 als Basis für Jackson Core Streaming unterstützte. Jackson 2.14 und alle späteren 2.x-Versionen erfordern mindestens Java 8.

Was bedeutet „Jackson Databind EOL“?

Keine Sicherheitspatches mehr

Wenn ein Jackson-Zweig geschlossen wird, stellt das FasterXML-Team die Veröffentlichung von Sicherheitspatches dafür ein. Jede Sicherheitslücke, die nach dieser Schließung bekannt wird – sei es in der Parsing-Ebene, der Deserialisierungs-Pipeline oder der Verarbeitung nicht vertrauenswürdiger Eingaben durch den ObjectMapper – wird in den derzeit offenen Zweigen behoben, während Ihre Version weiterhin ungeschützt bleibt.

Dies ist von Bedeutung, da Jackson keine passive Utility-Bibliothek ist. Es analysiert aktiv nicht vertrauenswürdige JSON-Daten, die von Netzwerkendpunkten, Nachrichtenwarteschlangen, REST-Clients und externen APIs eingehen. Jeder Aufruf von `ObjectMapper.readValue()` oder `ObjectMapper.readTree()` für eingehende Daten ist ein Ausführungspfad durch einen Parser, für den seit der Schließung eines Zweigs keine Sicherheitspatches mehr bereitgestellt werden. Diese Sicherheitslücke besteht bei jeder Anfrage.

Sicherheits- und Compliance-Risiken nach dem Ende des Supports für Jackson Databind

Die Compliance-Anforderungen sind eindeutig. PCI DSS (Anforderung 6.3.3) schreibt vor, dass kritische und schwerwiegende Sicherheitslücken mit einem CVSS-Wert von 7,0 oder höher innerhalb eines Monats nach Veröffentlichung des Patches für betroffene Systeme behoben werden müssen. HIPAA, FedRAMP und SOC 2 enthalten vergleichbare Anforderungen. Bei Anwendungen, die Zahlungsdaten, Gesundheitsdaten oder authentifizierten API-Datenverkehr verarbeiten, führt der Einsatz einer EOL-Version von Jackson, für die keine Patches mehr verfügbar sind, zu einer Sicherheits- und Compliance-Lücke, die durch kompensierende Kontrollmaßnahmen nur teilweise geschlossen werden kann.

Jackson ist Teil der Deserialisierungsschicht von Anwendungen, die einige der sensibelsten Daten in Unternehmensumgebungen verarbeiten, darunter Authentifizierungstoken, Finanzdaten, Gesundheitsakten und Antworten interner Service-APIs. Prüfer stufen nicht gepatchte JSON-Deserialisierungsbibliotheken als schwerwiegende Mängel ein, da der Parser die erste Ebene darstellt, die nicht vertrauenswürdige Daten aus externen Quellen verarbeitet.

Jacksons Geschichte im Bereich CVE

Jacksons CVE-Eintrag zeigt genau, wie die Offenlegung von Parsern nach Ablauf der Lebensdauer in der Praxis aussieht.

CVE-2025-52999: CVSS 4.0-Bewertung von 8,7, hoher Schweregrad (NVD). Diese am 25. Juni 2025 bekannt gegebene Schwachstelle betrifft Jackson Core in allen Versionen vor 2.15.0. Wenn Jackson Core Eingabedateien mit tief verschachtelten JSON-Strukturen – verschachtelte Objekte oder Arrays mit Tausenden von Ebenen – analysiert, erstellt der Parser für jede Verschachtelungsebene einen neuen JsonReadContext auf dem JVM-Aufrufstapel. In Versionen vor 2.15.0 gibt es keine Begrenzung für die Tiefe dieser Verschachtelung. Ein Angreifer kann eine JSON-Nutzlast erstellen, die aus Tausenden von verschachtelten Arrays oder Objekten besteht, wodurch die JVM ihren Aufrufstapel erschöpft und einen StackOverflowError auslöst, wodurch die Anwendung abstürzt. Der Angriff ist über das Netzwerk ausnutzbar, erfordert keine Authentifizierung und erfordert keine Benutzerinteraktion. Der NVD-Vektor lautet CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N. Der Fix in Jackson Core 2.15.0 führte StreamReadConstraints ein, eine konfigurierbare maximale Verschachtelungstiefe, deren Standardwert auf 1000 gesetzt ist. Da Jackson Databind Jackson Core zum Parsen aller JSON-Eingaben verwendet, war jede Anwendung, die Jackson Databind auf einem EOL-Zweig vor Version 2.15.0 ausführte, dieser aus der Ferne ausnutzbaren Denial-of-Service-Sicherheitslücke ausgesetzt, ohne dass für diese Version ein Upstream-Patch verfügbar war.

Für Java-Anwendungen in Unternehmen, die Spring Boot 2.7 einsetzen, bei dem der gesamte Jackson-Abhängigkeitsbaum auf die Version 2.13.x festgelegt ist: Diese Sicherheitslücke war in einem Zweig vorhanden und ungepatcht, der bereits seit November 2023 geschlossen war. Für diesen geschlossenen Zweig war kein Upstream-Patch vorgesehen; der standardmäßig unterstützte Weg war ein umfassenderes Framework-Upgrade oder eine Vereinbarung über erweiterten Support.

Das Problem der Abhängigkeitsfläche

Der direkte Abhängigkeitsbaum von Jackson Databind ist bewusst klein gehalten. In der README-Datei des FasterXML-Projekts wird ausdrücklich darauf hingewiesen, dass die Kernkomponenten, Annotationen, das Streaming und Databind keine zusätzlichen Abhängigkeiten über das JDK-Kernmodul hinaus erfordern. In der Praxis hängt Jackson Databind direkt nur von zwei Paketen ab: Jackson Core (dem Low-Level-Streaming-Parser und -Generator) und Jackson Annotations (der Ebene zur Verarbeitung von Annotationen). Beide sind FasterXML-Pakete, haben dieselbe Nebenversion und sind Teil desselben EOL-Ereignisses, wenn ein Jackson-Zweig geschlossen wird.

Es handelt sich zwar um einen kleinen Zweig, doch CVE-2025-52999 zeigt, dass die durch CVE verursachte Sicherheitslücke in Jackson Core real und unmittelbar relevant ist. Wenn ein Jackson-Zweig geschlossen wird, erhält nicht nur Jackson Databind keine Patches mehr: Auch Jackson Core und Jackson Annotations werden gleichzeitig geschlossen. Eine Anwendung, die einen geschlossenen Jackson-Zweig ausführt, ist gleichzeitig allen drei Kernkomponenten mit ungepatchten Schwachstellen ausgesetzt. TuxCares ELS für Jackson deckt die gesamte Abhängigkeitsfläche ab: Jackson Databind, Jackson Core und Jackson Annotations, sodass diese Sicherheitslücke umfassend behoben wird und nicht nur auf der obersten Paketebene.

Möglichkeiten, nach dem Ende des Supports für Jackson Databind die Sicherheit und Compliance zu gewährleisten

Aktualisieren Sie auf eine unterstützte Jackson-Version

Die Umstellung auf Jackson 2.18 oder 2.21 (die aktuellen LTS-Zweige) ist langfristig der richtige Weg. Das FasterXML-Team veröffentlicht für jede Nebenversion detaillierte Migrationshinweise, und die Jackson-Community sorgt für eine hohe Abwärtskompatibilität innerhalb einer Hauptversionsreihe.

Die Komplexität dieser Migration hängt von Ihrer Umgebung ab. Unternehmen, die große Anwendungsflotten betreiben, haben oft viele Codebasen, die nicht durch direkte Abhängigkeiten, sondern über das Framework-Management an eine bestimmte Jackson-Nebenversion gebunden sind. Spring Boot, Quarkus und andere Java-Frameworks verwalten Jackson-Versionen transitiv, was bedeutet, dass ein Upgrade der Jackson-Minor-Version oft auch eine Änderung der Framework-Version erfordert. Ein Upgrade von Jackson in einer Unternehmensanwendungsflotte erfordert die Identifizierung aller Jackson-Nutzer in der gesamten Codebasis, die Validierung des Serialisierungsverhaltens über alle ObjectMapper-Konfigurationen hinweg und das Testen der Anwendung unter realistischen Lastbedingungen, insbesondere dort, wo benutzerdefinierte Serialisierer, Deserialisierer oder Jackson-Module zum Einsatz kommen.

Wechsel zu einer alternativen JSON-Bibliothek

Einige Unternehmen nutzen das Auslaufen von Jackson Databind als Anlass, um alternative JSON-Bibliotheken wie Gson, Moshi, JSON-B oder andere zu prüfen. Für manche Teams ist dies eine sinnvolle langfristige architektonische Entscheidung, doch sie erfordert die Neuprogrammierung der gesamten Serialisierungslogik, das Ersetzen aller @JsonProperty- und verwandter Annotationen, die Migration der ObjectMapper-Konfigurationen sowie die Überprüfung des Verhaltens in jedem API-Vertrag und Datenmodell.

Für die meisten Unternehmen, die mit einer unmittelbaren Sicherheits- und Compliance-Lücke konfrontiert sind, ist die Migration der Datenbank keine Reaktion auf eine Patch-Frist.

Der empfohlene Weg: TuxCare ELS für Jackson

TuxCares ELS für Jackson geht das Sicherheits- und Compliance-Problem direkt an, ohne dass ein sofortiges Upgrade des Frameworks oder der Abhängigkeiten erforderlich ist. TuxCare stellt fortlaufend Sicherheitspatches für nicht mehr unterstützte Jackson-Versionen bereit, die Jackson Databind, Jackson Core und Jackson Annotations ohne zusätzliche Kosten abdecken. So kann Ihre Anwendungsflotte ein vertretbares Sicherheitsniveau aufrechterhalten, während Sie das von Ihnen gewünschte Upgrade planen.

TuxCare überwacht das NVD, die Sicherheitshinweise von FasterXML sowie die Release-Kanäle von Jackson, um Schwachstellen zu identifizieren, die das Jackson-Core-Ökosystem betreffen. Anschließend werden Korrekturen für EOL-Versionen zurückportiert und im Rahmen von SLA-gestützten Prozessen bereitgestellt. Unabhängig davon, ob Sie Jackson-Updates derzeit über Maven, Gradle oder Ihre bestehenden Build-Pipelines beziehen, können Sie Ihre Update-Quelle mit minimalen Änderungen an Ihrem bestehenden Workflow auf das sichere Repository von TuxCare umstellen. Es gibt keine Beeinträchtigungen für Ihre aktuelle Build-Toolchain, Ihre Framework-Konfiguration oder Ihren generierten Anwendungscode.

Die Risiken einer überstürzten Umstellung auf Jackson

Wenn durch Ergebnisse von Compliance-Audits, Warnmeldungen von Schwachstellenscannern oder Eskalationen des Sicherheitsteams Druck hinsichtlich des End-of-Life (EOL) von Jackson entsteht, ist der erste Impuls, sofort zu handeln. Doch die Kosten einer Reaktion ohne angemessene Vorbereitung sind stets höher, als die Teams erwarten. Unternehmen, die ELS für Jackson einsetzen, vermeiden diesen Druck vollständig, da ihre Sicherheitslage gewahrt bleibt, während das Upgrade ordnungsgemäß geplant wird.

Was ein Minor-Version-Upgrade von Jackson tatsächlich beinhaltet

Ein Upgrade auf eine Nebenversion von Jackson ist nicht gleichbedeutend mit einer Versionserhöhung in einer POM-Datei. Es umfasst die Überprüfung des Deserialisierungsverhaltens. In Nebenversionen von Jackson ändern sich gelegentlich die Standardverhalten hinsichtlich der Behandlung von Null-Werten, der Typumwandlungsregeln und der Behandlung unbekannter Eigenschaften. Das bedeutet, dass Anwendungen, die auf ein bestimmtes Deserialisierungsverhalten angewiesen sind, unter realistischen Lastbedingungen auf ihre Kompatibilität mit der neuen Version überprüft werden müssen. Dies beinhaltet die Überprüfung der Framework-Kompatibilität für Anwendungen, die Spring Boot, Quarkus oder andere verwaltete Frameworks verwenden. Dabei muss sichergestellt werden, dass die Zielversion von Jackson von der jeweiligen Framework-Version unterstützt wird und keine transitiven Abhängigkeitskonflikte auftreten. Es umfasst zudem Kompatibilitätsprüfungen für benutzerdefinierte Module bei Anwendungen, die Jackson-Module für Kotlin, Scala, Guava oder andere Integrationen nutzen. Dabei muss überprüft werden, ob diese Module verfügbar und mit der Ziel-Minor-Version von Jackson kompatibel sind. Außerdem umfasst dies den Testaufwand für jeden API-Endpunkt, jeden Nachrichtenempfänger und jede Datenpipeline, die Jackson für die Serialisierung verwenden.

In einer Unternehmensumgebung, in der Dutzende oder Hunderte von Diensten gemeinsame Jackson-Konfigurationen nutzen, in der verschiedene Teams für unterschiedliche Teile des Jackson-Abhängigkeitsgraphen verantwortlich sind und in der Änderungskontrollen die Produktivbereitstellungen regeln, ist ein Jackson-EOL-Upgrade ein koordiniertes Arbeitsprogramm und kein einzelnes Ticket.

Was passiert, wenn das Upgrade überstürzt durchgeführt wird?

Wenn Anwendungsteams aufgrund einer Compliance-Frist und nicht aufgrund ihrer eigenen Bereitschaft zu einem Jackson-Minor-Upgrade gezwungen werden, zeigt sich ein einheitliches Muster. In der Produktion treten bei Randfällen subtile Änderungen im Deserialisierungsverhalten zutage, die in automatisierten Tests nicht aufgetreten sind. Anwendungen, die zuvor großzügige ObjectMapper-Einstellungen verwendet haben, fallen aus, wenn die neue Version strengere Konvertierungsregeln durchsetzt. Jackson-Module für Integrationen von Drittanbietern schlagen stillschweigend fehl oder lösen zur Laufzeit Ausnahmen aus, wenn die Modulversionen nicht mit der neuen Minor-Version übereinstimmen. Technische Schulden häufen sich an, da Teams MapperFeature-Workarounds und Kompatibilitätsflags anwenden, um die Frist einzuhalten, was zu einem Wartungsaufwand führt, der sich mit der Zeit vervielfacht. Und ungeplante Kosten eskalieren in Form von Entwicklungsstunden, Produktionsvorfällen und dem Koordinationsaufwand für die Durchführung eines Upgrades, dessen Umfang vor Beginn nicht richtig abgegrenzt wurde.

Die Teams, die den Übergang nach dem Ende des Lebenszyklus von Jackson gut bewältigen, sind diejenigen, die ihn als geplante Migration behandeln – mit einer vollständigen Bestandsaufnahme der Anwendungen, einer Überprüfung der Framework-Kompatibilität und einer während des gesamten Prozesses gewahrten stabilen Sicherheitslage. ELS for Jackson macht diesen planvollen Ansatz erst möglich.

Die einfache Lösung: TuxCare ELS für Jackson

TuxCare hat über ein Jahrzehnt damit verbracht, die Automatisierung, das Fachwissen und die Prozesse zu optimieren, die erforderlich sind, um Sicherheitspatches für Software, deren Lebenszyklus abgelaufen ist, zuverlässig und in großem Maßstab bereitzustellen. Mit mehr als 220.000 Patches, die für das gesamte unterstützte Produktportfolio bereitgestellt wurden, hat TuxCare einen Patching-Workflow entwickelt, der sowohl schnell als auch produktionssicher ist.

ELS for Jackson schließt die Sicherheits- und Compliance-Lücke, die durch das Ende der Unterstützung für Jackson Databind entsteht:

Schnelle, SLA-gestützte Sicherheitspatches: TuxCare überwacht kontinuierlich die Veröffentlichung von Sicherheitslücken und stellt Patches für hochgradige und kritische CVEs (CVSS 7.0+) gemäß festgelegten SLAs bereit, sodass Ihre Jackson-Bereitstellungen die von PCI DSS, HIPAA, FedRAMP und anderen Compliance-Rahmenwerken geforderten Patch-Fristen einhalten.

Vollständige Abdeckung der Abhängigkeitsfläche: ELS für Jackson deckt Jackson Databind, Jackson Core und Jackson Annotations ab – den vollständigen Satz der FasterXML-Kernpakete, die bei einem Jackson-EOL-Ereignis gleichzeitig geschlossen werden – ohne zusätzliche Kosten. Die versteckte EOL-Exposition in Ihrem JSON-Verarbeitungsstack wird nicht zu einer Lücke, die Sie manuell verwalten müssen.

Nahtlose Integration in Ihre bestehenden Arbeitsabläufe: Unabhängig davon, ob Sie Jackson-Updates derzeit über Maven oder Gradle beziehen, können Sie Ihre Update-Quelle mit minimalen Änderungen an Ihrem bestehenden Workflow auf das sichere Repository von TuxCare umstellen. Ihre aktuelle Build-Toolchain oder die ObjectMapper-Konfigurationen Ihrer Anwendung werden dabei nicht beeinträchtigt.

Signierte, manipulationssichere Pakete: Jeder von TuxCare bereitgestellte Patch wird vor der Bereitstellung in Ihrem Repository umfassend auf Integrität, Funktionalität und Regressionen getestet, und die Pakete sind kryptografisch signiert, sodass Sie genau wissen, was Sie bereitstellen.

Kompetenter Support rund um die Uhr: Das Sicherheitsteam von TuxCare steht Ihnen rund um die Uhr für die Einstufung von Sicherheitslücken, Patch-Anfragen und Fehlerbehebung zur Verfügung, sodass Sie bei Sicherheitsvorfällen im Zusammenhang mit dem EOL von Jackson stets auf fachkundige Unterstützung zurückgreifen können.

Um zu sehen, welche Jackson-CVEs bereits behoben wurden, besuchen Sie den Live-CVE-Tracker von TuxCare. Weitere Informationen zum Patch-Prozess und zu den Validierungsstandards von TuxCare finden Sie im technischen Whitepaper.

Lassen Sie nicht zu, dass das Ende der Lebensdauer von Jackson Databind Ihre Anwendungen gefährdet

Das Ende der Lebensdauer (EOL) von Jackson bedeutet nicht, dass Ihre Anwendungen keine JSON-Daten mehr verarbeiten können. Es bedeutet jedoch, dass der Sicherheitsschutz, auf den sich Ihre JSON-Schicht bisher stützte, wegfällt, und jede CVE, die ab diesem Zeitpunkt in Jackson Core oder Jackson Databind bekannt gegeben wird, wirkt sich auf die Bibliothek aus, die alle Datenpakete verarbeitet, die Ihre Anwendungen mit der Außenwelt austauschen.

Teams, die den EOL von Jackson gut bewältigen, planen dies als eigenen Arbeitsbereich im Sicherheitsbereich. Sie legen einen Patch-Prozess fest, erfassen den Anwendungsbestand und legen einen Zeitplan für die Validierung fest, bevor eine Compliance-Frist sie dazu zwingt. Sie können ein gezieltes Upgrade auf die aktuelle LTS-Version von Jackson planen, wenn dies wirklich mit den Kapazitäten Ihrer Anwendungsteams, den Kompatibilitätsanforderungen Ihres Frameworks und dem Release-Kalender Ihres Unternehmens vereinbar ist. Sie können den Umfang der Deserialisierungsvalidierung und die Einführung sorgfältig festlegen, bevor Sie sich auf einen Zeitplan festlegen. Oder Sie nutzen TuxCares ELS für Jackson, um die Sicherheit und Compliance-Abdeckung aufrechtzuerhalten, während Sie den Zeitplan für das Upgrade selbst festlegen.

ELS for Jackson stellt Ihrer Anwendungsflotte fortlaufend Sicherheitspatches für Jackson-Versionen bereit, die von FasterXML nicht mehr gepflegt werden. Damit wird die Compliance-Situation gewahrt, auf die Ihre Audits angewiesen sind, und Ihre Entwicklerteams erhalten den nötigen Spielraum, um das Upgrade sorgfältig zu planen.

Falls das Ende des Supports für Jackson Databind derzeit auf Ihrer Sicherheits-Agenda steht, besuchen Sie TuxCare’s Endless Lifecycle Support für Jackson , um mehr über den erweiterten Support für nicht mehr unterstützte Jackson-Versionen zu erfahren.

Zusammenfassung

Artikel Name

ELS für Jackson: Was das Ende der Lebensdauer von Jackson Databind bedeutet

Beschreibung

Jackson EOL vergrößert Ihre Risikofläche: Jackson Databind basiert auf Jackson Core, das eine lange CVE-Historie aufweist. Lesen Sie mehr dazu in diesem Artikel

Autor

Muzzammil Hasann

Name des Herausgebers

TuxCare

Logo des Herausgebers