Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- „In sich geschlossen“ bedeutet nicht „risikoarm“: protobuf-java und die Python-Laufzeitumgebung haben keine Abhängigkeiten von Drittanbietern, aber sie analysieren dennoch nicht vertrauenswürdige Eingaben. Wenn keine Patches mehr bereitgestellt werden, ist jeder Dienst, der Daten deserialisiert, diesem Risiko ausgesetzt.
- Überstürzte Upgrades sind kostspielig: Größere Versionsänderungen bei Protobuf können die APIs des generierten Codes sprachübergreifend beeinträchtigen und erfordern koordinierte Aktualisierungen bei allen Diensten, die Protobuf-Daten erzeugen oder nutzen.
- EOL bedeutet nicht das Ende der Sicherheit: TuxCare’s ELS für Protocol Buffers hält nicht mehr unterstützte Java- und Python-Laufzeitumgebungen auf dem neuesten Stand, während Sie das Upgrade nach Ihrem eigenen Zeitplan durchführen.
Die Serialisierungsschicht ist eines der am häufigsten übersehenen EOL-Risiken in modernen Service-Infrastrukturen. Protocol Buffers – Googles sprachunabhängiges Datenformat – kommt in Microservices, gRPC-APIs, Nachrichtenwarteschlangen und Datenpipelines in Unternehmen jeder Größe zum Einsatz. Jeder Dienst, der eingehende Protobuf-Daten analysiert, lässt seine Nutzdaten bei jeder Anfrage durch einen Parser laufen, der nicht vertrauenswürdige Eingaben verarbeitet. Wenn für diesen Parser keine Sicherheitspatches mehr bereitgestellt werden, besteht an jedem Endpunkt, der damit in Berührung kommt, eine Sicherheitslücke.
Protobuf ist keine einzelne Bibliothek. Jede Sprache verfügt über eine eigene Laufzeitumgebung mit eigenem Versionszyklus und eigenem EOL-Zeitpunkt, und CVEs sind in der Regel sprachspezifisch – sie werden in einigen Laufzeitumgebungen behoben, in anderen jedoch nicht. Die Java-Laufzeitumgebung (protobuf-java, einschließlich der Lite-Laufzeitumgebung, sowie im weiteren Sinne Kotlin und JRuby, die davon abhängen) und die Python-Laufzeitumgebung sind zwei der gängigsten in Unternehmensstacks. Wenn eine von beiden aus dem Support-Zeitraum von Google herausfällt, sammelt sich bei jedem davon abhängigen Dienst eine Parser-Sicherheitslücke an, die von den Upstream-Maintainern nicht mehr behoben wird.
Dieser Beitrag erläutert, wie der Release-Lebenszyklus von Protocol Buffers tatsächlich funktioniert, was das Ende des Supports (EOL) für Protobuf in Bezug auf Sicherheit und Compliance konkret bedeutet und warum ELS für Protocol Buffers der direkteste Weg ist, diese Lücke für die Java- und Python-Laufzeitumgebungen zu schließen, während Sie Ihr Upgrade nach Ihrem eigenen Zeitplan planen.
Wie sieht der Release-Zyklus von Protocol Buffers aus?
Protocol Buffers verwendet ein Versionsmodell, das komplexer ist als bei den meisten Bibliotheken, da der Protocol-Compiler und die jeweilige Sprach-Laufzeitumgebung unabhängig voneinander versioniert werden. Dies zu verstehen ist unerlässlich, um genau zu wissen, wo die EOL-Risiken beginnen.
Der Protoc-Compiler verwendet ein Nummerierungsschema aus Version und Punkt, zum Beispiel 29.5. Die Versionsnummer (29) gibt die Generation der Protoc-Funktionen an, während die Punktnummer (.5) Fehlerbehebungen und Patches innerhalb dieser Versionsreihe umfasst.
Sprach-Laufzeitumgebungen verwenden ein MAJOR.MINOR.POINT-Schema, das an die Protoc-Version gekoppelt ist. Die Minor- und Point-Versionen folgen der Protoc-Version, sodass die Laufzeitversion x.29.5 zeitgleich mit Protoc 29.5 veröffentlicht wurde. Die Major-Version wird für jede Sprache unabhängig erhöht, wenn für diese spezifische Laufzeitumgebung eine kompatibilitätsbrechende Änderung erforderlich ist. Das bedeutet, dass verschiedene Sprach-Runtimes unterschiedliche Hauptversionen haben können, selbst wenn sie gleichzeitig veröffentlicht werden: Die Protoc-Version 29.5 entspricht gleichzeitig der Java-Runtime 4.29.5 und der Python-Runtime 5.29.5.
Fenster zur Unterstützung folgen zwei Regeln:
Der Support für eine ältere Nebenversion endet, sobald die nächste Nebenversion unter derselben Hauptversion veröffentlicht wird.
Der Support für eine frühere Hauptversion endet vier Quartale nach dem Quartal, in dem die Version mit den kompatibilitätsbrechenden Änderungen veröffentlicht wurde. Als beispielsweise Protobuf Python 5.26.0 im ersten Quartal 2024 veröffentlicht wurde, wurde das Ende des Supports für Protobuf Python 4.25.x auf das Ende des ersten Quartals 2025 festgelegt.
| Protobuf-Komponente | Versionsschema | Support-Fenster |
| protoc-Compiler | Auslösepunkt (z. B. 29,5) | Nur aktuelle Version |
| Sprach-Laufzeitumgebungen (geringfügig) | MAJOR.MINOR.POINT ist mit dem Protokoll verknüpft | Endet, sobald die nächsten kleinen Schiffe auslaufen |
| Sprach-Laufzeitumgebungen (wichtig) | Unabhängig von der Sprache | Veröffentlichung nach dem Durchbruch in vier Quartalen |
Die praktische Konsequenz: Für Teams, die nicht mehr unterstützte Versionen einsetzen – wie beispielsweise ältere Java 3.x-Versionen oder nicht mehr unterstützte Python 4.x- oder 5.x-Versionen –, ist ELS für Protocol Buffers der Weg zu anhaltendem Sicherheitsschutz.
Was bedeutet „Protobuf EOL“?
Keine Sicherheitspatches mehr
Wenn eine Protobuf-Laufzeitversion nicht mehr zum unterstützten Zeitraum gehört, stellt das Protobuf-Team von Google die Veröffentlichung von Sicherheitspatches dafür ein. Jede nach diesem Zeitpunkt bekannt gewordene Sicherheitslücke – sei es in der Parsing-Ebene, in den APIs für generierten Code oder bei der Behandlung fehlerhafter Eingaben durch die Laufzeitumgebung – wird in den aktuell unterstützten Versionen behoben, für Ihre Version jedoch nicht.
Das ist die operative Realität beim Betrieb einer EOL-Serialisierungsinfrastruktur in großem Maßstab: Protobuf-Laufzeitumgebungen sind keine passiven Bibliotheken. Sie analysieren aktiv nicht vertrauenswürdige Daten von Netzwerkendpunkten, Nachrichtenwarteschlangen und API-Gateways. Jeder Dienst, der eingehende Protobuf-Nutzdaten deserialisiert, verarbeitet Daten über einen Parser, für den keine Sicherheitspatches mehr bereitgestellt werden. Diese Sicherheitslücke im Parser besteht bei jeder Anfrage.
Sicherheits- und Compliance-Risiken nach dem Ende der Lebensdauer von Protobuf
Auch in Bezug auf die Compliance ist die Lage 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 auf den betroffenen Systemen behoben werden müssen. HIPAA, FedRAMP und SOC 2 stellen vergleichbare Anforderungen an das Schwachstellenmanagement, die Risikobehebung und dokumentierte Patch-Prozesse. Bei Diensten, die Zahlungsdaten, Gesundheitsdaten oder authentifizierten API-Datenverkehr verarbeiten, führt der Betrieb einer EOL-Protobuf-Laufzeitumgebung, die nicht gepatcht werden kann, zu einer Sicherheits- und Compliance-Lücke, die durch kompensierende Kontrollen nur teilweise geschlossen werden kann.
Protobuf ist Teil der Serialisierungsschicht von Diensten, die einige der sensibelsten Daten in Unternehmensumgebungen verarbeiten, darunter Authentifizierungstoken, Finanztransaktionen, Gesundheitsdaten und interne API-Nutzdaten. Prüfer könnten nicht gepatchte Serialisierungsbibliotheken als schwerwiegende Mängel einstufen, da der Parser als Erstes mit nicht vertrauenswürdigen Netzwerkdaten in Berührung kommt.
Die CVE-Historie von Protocol Buffers
Der Protobuf-CVE-Datensatz in der Java-Laufzeitumgebung veranschaulicht, wie die Offenlegung von Parsern nach dem Ende des Lebenszyklus (EOL) in der Praxis aussieht.
CVE-2024-7254 – CVSS 7.5 (Hoch). Diese im September 2024 bekannt gewordene Sicherheitslücke betrifft die Java-Protobuf-Laufzeitumgebungen (Full und Lite) sowie Protobuf für Kotlin und JRuby, die die Java-Laufzeitumgebung nutzen. Das Parsen verschachtelter Gruppen als unbekannte Felder mit dem DiscardUnknownFieldsParser oder dem Java Protobuf Lite-Parser sowie das Parsen von Protobuf-Map-Feldern führt zu einer unbegrenzten Rekursion, die ein Angreifer ausnutzen kann. Eine speziell gestaltete Protobuf-Nachricht, die eine beliebige Anzahl verschachtelter Gruppen oder eine Reihe von SGROUP-Tags enthält, kann einen StackOverflowError verursachen und den Serverprozess zum Absturz bringen. Der Angriff erfordert keine Authentifizierung und keine Benutzerinteraktion und funktioniert durch das Senden einer bösartigen Nutzlast an einen beliebigen Endpunkt, der nicht vertrauenswürdige Protobuf-Daten parst. Der NVD CVSS 3.1-Vektor lautet CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Patches wurden in den Versionen 3.25.5, 4.27.5 und 4.28.2 veröffentlicht; betroffene frühere Releases dieser Versionsreihen blieben jedoch anfällig.
Diese Sicherheitslücke betraf alle Versionen von protobuf-java in beiden Hauptversionszweigen, was bedeutet, dass jedes Unternehmen, das eine protobuf-Java-Laufzeitumgebung mit abgelaufenem Support (EOL) einsetzte, einem aus der Ferne ausnutzbaren Denial-of-Service-Zustand ausgesetzt war, ohne dass für die jeweilige Version ein Patch vom Hersteller verfügbar war. Für Dienste, die externen API-Datenverkehr verarbeiten, stellt dies ein direktes Verfügbarkeitsrisiko dar.
Die Abhängigkeitsfläche
Beide von ELS für Protocol Buffers abgedeckten Laufzeiten sind auf Paketebene bemerkenswert eigenständig. protobuf-java wird ohne jegliche Laufzeitabhängigkeiten von Drittanbietern ausgeliefert. Die Python-Laufzeit benötigt lediglich den Python-Interpreter selbst. Die ELS-Abdeckung dieser beiden Laufzeiten umfasst direkt deren gesamte Abhängigkeitsfläche, ohne dass zusätzliche transitive Ebenen verwaltet werden müssen.
Möglichkeiten, auch nach dem Ende des Lebenszyklus von Protobuf die Sicherheit und Compliance zu gewährleisten
Auf eine unterstützte Protobuf-Version aktualisieren
Die Umstellung auf die aktuellste unterstützte Protobuf-Laufzeitumgebung ist langfristig der richtige Weg. Das Protobuf-Team von Google veröffentlicht bei jedem größeren Versionswechsel Migrationsanleitungen, und die Kompatibilität des binären Datenformats ist über alle Versionen hinweg gewährleistet. Das bedeutet, dass Dienste ihre Laufzeitumgebungen aktualisieren können, ohne dass serialisierte Daten während der Übertragung oder im Speicher beschädigt werden.
Die Komplexität dieser Migration hängt von Ihrer Umgebung ab. Eine verteilte Serviceflotte, die Protobuf nutzt, lässt sich nicht auf dieselbe Weise aktualisieren wie eine einzelne Anwendung. Dazu ist es erforderlich, den Protobuf-Compiler zu aktualisieren, alle sprachspezifischen Bindungen für alle betroffenen Dienste neu zu generieren, zu überprüfen, ob die generierten API-Änderungen bestehende Serviceverträge nicht beeinträchtigen, die Bereitstellungen zwischen Diensten zu koordinieren, die Protobuf-Daten erzeugen und nutzen, sowie die Einführung über Staging-Umgebungen mit realistischem Datenverkehr zu verwalten. Für Unternehmen, die mehrere Dienste in verschiedenen Sprachen betreiben, die jeweils dieselben Proto-Definitionen nutzen, ist der Umfang einer erzwungenen Migration auf eine neue Hauptversion beträchtlich.
Auf ein alternatives Serialisierungsformat umstellen
Einige Organisationen nutzen ein Protobuf-EOL-Ereignis, um alternative Serialisierungsformate wie JSON, Avro, FlatBuffers, MessagePack oder ähnliche zu evaluieren. Für manche Teams ist dies eine tragfähige langfristige architektonische Entscheidung, doch sie erfordert die Neuprogrammierung der Serialisierungslogik, die Migration der Schemaverwaltung, die Neugenerierung aller Service-Schnittstellen sowie die Koordination dienstübergreifender Migrationen.
Für die meisten Unternehmen, die mit einer unmittelbaren Sicherheits- und Compliance-Lücke konfrontiert sind, ist eine Formatmigration keine Lösung für eine bevorstehende Patch-Frist.
Der empfohlene Weg: TuxCare ELS für Protocol Buffers
Das ELS für Protocol Buffers von TuxCare löst das Sicherheits- und Compliance-Problem direkt, ohne dass ein sofortiges Upgrade der Laufzeitumgebung erforderlich ist. TuxCare stellt im Rahmen des ELS-Abonnements fortlaufend Sicherheitspatches für nicht mehr unterstützte Protobuf-Java- und Python-Laufzeitversionen bereit, sodass Ihre Serviceflotte ein vertretbares Sicherheitsniveau aufrechterhalten kann, während Sie das tatsächlich gewünschte Upgrade planen.
TuxCare überwacht das NVD, die Sicherheitshinweise von Google sowie die Release-Kanäle des Protobuf-Upstreams auf Schwachstellen, die die Protobuf-Laufzeitumgebung und ihr Ökosystem betreffen, und stellt anschließend über SLA-gestützte Prozesse Backports und Korrekturen für EOL-Versionen bereit. Unabhängig davon, ob Sie Protocol Buffers-Updates derzeit über Maven, Gradle, pip 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 Unterbrechung Ihrer aktuellen Toolchain oder des generierten Servicecodes.
Die Risiken einer überstürzten Aktualisierung von Protobuf
Wenn durch Ergebnisse von Compliance-Audits, Warnmeldungen von Schwachstellenscannern oder Eskalationen des Sicherheitsteams Druck hinsichtlich des Endes der Unterstützung für Protobuf 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 Protocol Buffers einsetzen, können diesen Druck vollständig vermeiden, da ihre Sicherheitslage gewahrt bleibt, während das Upgrade ordnungsgemäß geplant wird.
Was ein Upgrade der Protobuf-Hauptversion konkret beinhaltet
Ein Upgrade der Hauptversion von Protobuf ist nicht nur eine Erhöhung der Versionsnummer in Ihrer Build-Datei. Es erfordert die Neugenerierung des gesamten generierten Codes. Jede .proto-Datei, die Ihr Unternehmen verwaltet, muss mit der neuen Protoc-Version neu kompiliert werden, wodurch aktualisierte sprachspezifische Stubs erzeugt werden, deren APIs sich möglicherweise von denen unterscheiden, die Ihr Servicecode derzeit aufruft. Dies erfordert eine Kompatibilitätsprüfung für jeden Dienst, der Protobuf-serialisierte Daten erzeugt oder nutzt, um sicherzustellen, dass die neu generierten APIs keine grundlegenden Änderungen an den Dienstverträgen mit sich bringen. Dazu gehört die Anpassung der Toolchain für CI/CD-Pipelines, Docker-Build-Images und jegliche Automatisierung, die den Protoc-Compiler direkt aufruft. Und es entsteht ein Testaufwand: Das Serialisierungsverhalten muss dienstübergreifend durchgängig validiert werden, und Randfälle des Parsers treten nur unter realistischen Produktionsbedingungen zutage.
In einer Unternehmensumgebung, in der Dutzende oder Hunderte von Diensten gemeinsame Proto-Definitionen nutzen, in der Serviceteams nach unterschiedlichen Release-Rhythmen arbeiten und in der Produktionsbereitstellungen einer Änderungskontrolle unterliegen, ist ein Protobuf-EOL-Upgrade ein koordiniertes Arbeitsprogramm und keine Sprint-Aufgabe.
Was passiert, wenn das Upgrade überstürzt durchgeführt wird?
Wenn Serviceteams aufgrund einer Compliance-Frist und nicht aufgrund ihrer eigenen Bereitschaft zu einem größeren Protobuf-Upgrade gezwungen werden, zeigt sich ein einheitliches Muster. Neu generierter Stub-Code führt zu unerwarteten API-Unterschieden, die bestehende Service-Implementierungen auf eine Weise beeinträchtigen, die in automatisierten Tests nicht zutage trat. Systeminstabilität äußert sich in Serialisierungs-Randfällen, die sich nur unter realistischen Lastbedingungen zeigen und zu stiller Datenkorruption oder unerwartetem Verhalten an Service-Grenzen führen. Technische Schulden häufen sich an, da Teams Kompatibilitäts-Shims und Workarounds einsetzen, um die Frist einzuhalten, was einen Wartungsaufwand verursacht, der sich über nachfolgende Upgrade-Zyklen hinweg verstärkt. Und ungeplante Kosten eskalieren in Form von Entwicklungsstunden, Service-Vorfällen und dem betrieblichen Aufwand für die Koordination einer Migration, deren Umfang vor Beginn nicht richtig abgeschätzt wurde.
Die Teams, die den Übergang nach dem Ende des Lebenszyklus von Protobuf gut bewältigen, sind diejenigen, die ihn als geplante Migration mit vollständiger Bestandsaufnahme der Dienste, koordinierten Einführungen und einer während des gesamten Prozesses aufrechterhaltenen stabilen Sicherheitslage behandeln. ELS für Protocol Buffers macht diesen planvollen Ansatz erst möglich.
Die einfache Lösung: TuxCare ELS für Protocol Buffers
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 für Protocol Buffers schließt die Sicherheits- und Compliance-Lücke, die durch das Ende der Unterstützung von Protobuf 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 Protobuf-Bereitstellungen die von PCI DSS, HIPAA, FedRAMP und anderen Compliance-Rahmenwerken geforderten Patch-Fristen einhalten.
Vollständige Laufzeitabdeckung. Beide von ELS für Protocol Buffers abgedeckten Laufzeiten sind auf Paketebene in sich geschlossen. protobuf-java wird ohne Laufzeitabhängigkeiten von Drittanbietern ausgeliefert, und die Python-Laufzeit benötigt lediglich den Python-Interpreter selbst. Die ELS-Abdeckung dieser beiden Laufzeiten umfasst direkt deren gesamte Patch-Oberfläche, ohne dass zusätzliche transitive Schichten verwaltet werden müssen.
Nahtlose Integration in Ihre bestehenden Arbeitsabläufe. Ganz gleich, ob Sie Protocol-Buffers-Updates derzeit über Maven, Gradle, pip oder Ihre bestehenden Build-Pipelines beziehen – Sie können Ihre Update-Quelle mit nur minimalen Änderungen an Ihrem bestehenden Arbeitsablauf auf das sichere Repository von TuxCare umstellen. Ihre aktuelle Toolchain und der generierte Servicecode bleiben davon unberührt.
Signierte, manipulationssichere Pakete. Jeder von TuxCare bereitgestellte Patch wird vor der Bereitstellung in Ihrem Repository umfassend auf Integrität, Funktionalität und Regression getestet. 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 die Fehlerbehebung zur Verfügung, sodass Sie bei Sicherheitsvorfällen im Zusammenhang mit dem Ende der Lebensdauer von Protobuf stets auf fachkundige Unterstützung zählen können.
Um zu sehen, welche CVEs für Protocol Buffers 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 Protobuf Ihre Dienste gefährdet
Das Ende des Lebenszyklus von Protocol Buffers bedeutet nicht, dass Ihre Dienste keine Daten mehr serialisieren. Es bedeutet jedoch, dass der Sicherheitsschutz, auf den sich Ihre Serialisierungsschicht bisher verlassen hat, wegfällt, und jede CVE, die ab diesem Zeitpunkt im Protobuf-Parser auftaucht, stellt ein Sicherheitsrisiko dar, das Sie in der Schicht tragen, die jedes einzelne Byte der Daten verarbeitet, die Ihre Dienste austauschen.
Teams, die dies gut handhaben, betrachten das Ende der Lebensdauer von Protobuf als ein Sicherheitsproblem, das bewusst gemanagt werden muss, und nicht als eine Frist, auf die unter Druck reagiert werden muss. Sie können ein wohlüberlegtes Upgrade auf die aktuell unterstützte Hauptversion von Protobuf planen, wenn dies tatsächlich mit der Kapazität Ihrer Serviceteams, der Bereitschaft Ihrer Build-Infrastruktur und dem Release-Kalender Ihres Unternehmens vereinbar ist. Sie können den Umfang der Neugenerierung und des Rollouts angemessen festlegen, bevor Sie sich auf einen Zeitplan festlegen. Oder Sie können TuxCares ELS für Protocol Buffers nutzen, um die Sicherheit und Compliance-Abdeckung aufrechtzuerhalten, während Sie diese Entscheidungen nach Ihren eigenen Bedingungen treffen – und nicht nach dem Zeitplan eines Compliance-Audits.
ELS für Protocol Buffers ist keine Notlösung. Es ist die Lösung, die die Sicherheit Ihrer Serviceflotte gewährleistet, Ihre Compliance-Situation aufrechterhält und es Ihren Entwicklerteams ermöglicht, sich auf die Entwicklung zu konzentrieren, anstatt Notfallmigrationen im Bereich der Serialisierung zu verwalten.
Wenn das Ende des Lebenszyklus von Protocol Buffers derzeit auf Ihrem Sicherheitsradar steht, besuchen Sie TuxCare’s Endless Lifecycle Support von TuxCare, um zu erfahren, wie erweiterter Support Ihre Serialisierungsinfrastruktur so lange schützen kann, wie Sie es benötigen.
