Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- Le fait d'être autonome ne signifie pas pour autant que le risque est faible: protobuf-java et le runtime Python n'ont pas de dépendances tierces, mais ils analysent tout de même des données d'entrée non fiables. Lorsque les correctifs cessent, chaque service de désérialisation est exposé à ce risque.
- Les mises à jour précipitées coûtent cher : les changements majeurs de version de Protobuf peuvent rompre la compatibilité des API de code généré entre les langages, ce qui oblige à coordonner les mises à jour entre les services qui produisent ou utilisent des données Protobuf.
- La fin de vie (EOL) ne signifie pas la fin de la sécurité : L'ELS de TuxCare pour Protocol Buffers maintient à jour les environnements d'exécution Java et Python qui ne sont plus pris en charge pendant que vous effectuez la mise à niveau selon votre calendrier.
La couche de sérialisation est l’un des risques liés à la fin de vie (EOL) les plus négligés dans les infrastructures de services modernes. Protocol Buffers – le format de données indépendant du langage de Google – est présent au sein des microservices, des API gRPC, des files d’attente de messages et des pipelines de données dans les organisations de toutes tailles. Chaque service qui analyse les données protobuf entrantes traite ses charges utiles via un analyseur syntaxique qui gère les entrées non fiables à chaque requête. Lorsque cet analyseur cesse de recevoir des correctifs de sécurité, la vulnérabilité est exposée sur chaque point de terminaison qui y a accès.
Protobuf n'est pas une bibliothèque unique. Chaque langage dispose de son propre moteur d'exécution, avec son propre rythme de mise à jour et sa propre date de fin de vie, et les vulnérabilités CVE sont généralement spécifiques à chaque langage : elles sont corrigées dans certains moteurs d'exécution, mais pas dans d'autres. Le runtime Java (protobuf-java, y compris le runtime lite, et par extension Kotlin et JRuby, qui en dépendent) et le runtime Python sont deux des plus courants dans les piles d'entreprise. Lorsque l'un ou l'autre sort de la fenêtre de support de Google, tous les services qui en dépendent commencent à accumuler des vulnérabilités de l'analyseur syntaxique que les responsables de la maintenance en amont ne corrigent plus.
Cet article explique en détail le fonctionnement du cycle de vie des versions de Protocol Buffers, ce que signifie la fin de vie (EOL) de Protobuf en termes concrets de sécurité et de conformité, et pourquoi ELS pour Protocol Buffers constitue la solution la plus directe pour combler cette lacune dans les environnements d'exécution Java et Python, tout en vous permettant de planifier votre mise à niveau selon votre propre calendrier.
En quoi consiste le cycle de vie des versions de Protocol Buffers ?
Protocol Buffers utilise un modèle de gestion des versions plus complexe que celui de la plupart des bibliothèques, car le compilateur Protocol et chaque moteur d'exécution de langage sont gérés indépendamment. Il est essentiel de bien comprendre ce principe pour savoir exactement à quel moment votre exposition à la fin de vie (EOL) commence.
Le compilateur Protocol utilise un système de numérotation de version de type « version.point », par exemple 29.5. Le numéro de version (29) identifie la génération de fonctionnalités de Protocol, tandis que le numéro de point (.5) correspond aux corrections de bogues et aux correctifs apportés au sein de cette branche de version.
Les environnements d'exécution des langages utilisent un schéma MAJOR.MINOR.POINT lié à la version de protoc. Les versions mineures et ponctuelles suivent la version de protoc ; ainsi, la version x.29.5 de l'environnement d'exécution a été publiée en même temps que la version 29.5 de protoc. La version majeure est incrémentée indépendamment pour chaque langage lorsqu'un changement rompant la compatibilité est nécessaire pour cet environnement d'exécution spécifique. Cela signifie que les runtimes de différents langages peuvent avoir des versions majeures différentes même lorsqu'ils sont publiés en même temps : la version 29.5 de protoc correspond simultanément au runtime Java 4.29.5 et au runtime Python 5.29.5.
Les fenêtres de support respectent deux règles :
La prise en charge d'une version mineure antérieure prend fin dès la sortie de la version mineure suivante relevant de la même version majeure.
Le support d'une version majeure antérieure prend fin quatre trimestres après le trimestre au cours duquel la version introduisant des changements majeurs a été publiée. Par exemple, lorsque Protobuf Python 5.26.0 a été publié au premier trimestre 2024, la fin du support de Protobuf Python 4.25.x a été fixée à la fin du premier trimestre 2025.
| Composant Protobuf | Système de numérotation des versions | Fenêtre d'assistance |
| compilateur Protoc | Point de relâchement (par exemple, 29,5) | Version actuelle uniquement |
| Environnements d'exécution de langages (mineur) | MAJOR.MINOR.POINT lié au protocole | Se termine lorsque le prochain « minor » sera publié |
| Environnements d'exécution de langages (principaux) | Indépendant par langue | Communiqué de presse quatre trimestres après la clôture |
En pratique, cela signifie que pour les équipes utilisant des versions non prises en charge – telles que les anciennes versions de Java 3.x ou les versions non prises en charge de Python 4.x ou 5.x –, ELS pour Protocol Buffers est la solution pour continuer à bénéficier d'une couverture de sécurité.
Que signifie « EOL » pour Protobuf ?
Fin des correctifs de sécurité
Lorsqu'une version du runtime Protobuf sort de la période de prise en charge, l'équipe Protobuf de Google cesse de publier des correctifs de sécurité pour celle-ci. Toute vulnérabilité révélée après cette date – qu'elle concerne la couche d'analyse, les API du code généré ou la gestion par le runtime des entrées mal formées – fera l'objet d'un correctif dans les versions actuellement prises en charge, mais pas dans la vôtre.
Voici la réalité opérationnelle liée à la gestion d'une infrastructure de sérialisation EOL à grande échelle : les moteurs d'exécution Protobuf ne sont pas de simples bibliothèques passives. Ils analysent activement des données non fiables provenant de points d'extrémité réseau, de files d'attente de messages et de passerelles API. Chaque service qui désérialise des charges utiles Protobuf entrantes traite des données via un analyseur syntaxique pour lequel les correctifs de sécurité ne sont plus fournis. Cette vulnérabilité de l'analyseur est présente à chaque requête.
Risques liés à la sécurité et à la conformité après la fin de vie de Protobuf
La situation en matière de conformité est tout aussi claire. La norme PCI DSS (exigence 6.3.3) impose que les vulnérabilités critiques et à haut risque, dont le score CVSS est égal ou supérieur à 7,0, soient corrigées dans un délai d’un mois à compter de la publication du correctif pour les systèmes concernés. Les normes HIPAA, FedRAMP et SOC 2 peuvent imposer des exigences similaires en matière de gestion des vulnérabilités, de correction des risques et de processus de correction documentés. Pour les services traitant des données de paiement, des dossiers médicaux ou du trafic API authentifié, l'utilisation d'un runtime Protobuf en fin de vie (EOL) que vous ne pouvez pas corriger crée une faille de sécurité et de conformité que les contrôles compensatoires ne peuvent combler que partiellement.
Protobuf fait partie de la couche de sérialisation des services qui traitent certaines des données les plus sensibles dans les environnements d'entreprise, telles que les jetons d'authentification, les transactions financières, les dossiers médicaux et les charges utiles des API internes. Les auditeurs peuvent considérer les bibliothèques de sérialisation non mises à jour comme des anomalies majeures, car l'analyseur syntaxique est le premier élément à entrer en contact avec des données réseau non fiables.
Historique des vulnérabilités CVE de Protocol Buffers
L'enregistrement CVE de Protobuf dans l'environnement d'exécution Java illustre concrètement ce à quoi ressemble l'exposition d'un analyseur syntaxique après la fin de vie du produit.
CVE-2024-7254 – CVSS 7,5 (Risque élevé). Divulguée en septembre 2024, cette vulnérabilité affecte les environnements d'exécution Java Protobuf complet et allégé, ainsi que Protobuf pour Kotlin et JRuby, qui utilisent l'environnement d'exécution Java. L'analyse de groupes imbriqués en tant que champs inconnus avec DiscardUnknownFieldsParser ou le parseur Java Protobuf Lite, ou l'analyse de champs de carte Protobuf, crée une récursion illimitée qu'un attaquant peut exploiter. Un message Protobuf spécialement conçu contenant un nombre arbitraire de groupes imbriqués ou une série de balises SGROUP peut provoquer une erreur StackOverflowError et faire planter le processus serveur. L'attaque ne nécessite aucune authentification ni interaction de l'utilisateur, et fonctionne en envoyant une charge utile malveillante à n'importe quel point de terminaison qui analyse des données Protobuf non fiables. Le vecteur NVD CVSS 3.1 est CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Des correctifs ont été publiés dans les versions 3.25.5, 4.27.5 et 4.28.2 ; les versions antérieures concernées de ces séries restaient vulnérables.
Cette vulnérabilité concernait toutes les versions de protobuf-java, qu'elles appartiennent à l'une ou l'autre des branches principales. Cela signifie que toute organisation utilisant une version de protobuf-java arrivée en fin de vie était exposée à une attaque par déni de service exploitable à distance, sans qu'aucun correctif en amont ne soit disponible pour sa version. Pour les services traitant du trafic API externe, cela représente un risque direct pour la disponibilité.
La surface de dépendance
Les deux environnements d'exécution couverts par ELS pour Protocol Buffers sont particulièrement autonomes au niveau des paquets. protobuf-java ne comporte aucune dépendance d'exécution tierce. L'environnement d'exécution Python ne nécessite que l'interpréteur Python lui-même. La couverture ELS de ces deux environnements d'exécution englobe directement l'ensemble de leurs dépendances, sans couches transitives supplémentaires à gérer.
Solutions pour garantir la sécurité et la conformité après la fin de vie de Protobuf
Passez à une version prise en charge de Protobuf
La migration vers la dernière version prise en charge du runtime Protobuf constitue la bonne stratégie à long terme. L'équipe Protobuf de Google publie des guides de migration pour chaque passage à une nouvelle version majeure, et la compatibilité du format binaire de transmission est garantie d'une version à l'autre. Les services peuvent ainsi mettre à niveau leurs runtimes sans compromettre l'intégrité des données sérialisées, qu'elles soient en transit ou stockées.
La complexité de cette migration dépend de votre environnement. Un parc de services distribués utilisant Protobuf ne se met pas à jour de la même manière qu’une application unique. Cela nécessite de mettre à jour le compilateur Protobuf, de régénérer toutes les liaisons spécifiques à chaque langage pour tous les services concernés, de vérifier que les modifications apportées à l’API générée ne rompent pas les contrats de service existants, de coordonner les déploiements entre les services qui produisent et consomment des données Protobuf, et de gérer le déploiement progressif via des environnements de test avec un trafic réaliste. Pour les organisations exploitant plusieurs services dans plusieurs langages, chacun consommant les mêmes définitions Proto, l'ampleur d'une migration forcée vers une version majeure est considérable.
Passer à un autre format de sérialisation
Certaines organisations ont recours à un événement EOL Protobuf pour évaluer d'autres formats de sérialisation, tels que JSON, Avro, FlatBuffers, MessagePack ou d'autres formats similaires. Il s'agit d'un choix architectural viable à long terme pour certaines équipes, mais cela implique de réécrire la logique de sérialisation, de migrer la gestion des schémas, de régénérer toutes les interfaces de service et de coordonner les migrations entre les services.
Pour la plupart des entreprises confrontées à une lacune immédiate en matière de sécurité et de conformité, la migration de format ne constitue pas une solution pour respecter une échéance de mise à jour.
La solution recommandée : TuxCare ELS pour Protocol Buffers
Le service ELS de TuxCare pour Protocol Buffers résout directement les problèmes de sécurité et de conformité, sans nécessiter de mise à niveau immédiate de l'environnement d'exécution. Dans le cadre de l'abonnement ELS, TuxCare fournit des correctifs de sécurité continus pour les versions obsolètes de protobuf-java et de l'environnement d'exécution Python, ce qui permet à votre parc de services de conserver un niveau de sécurité défendable pendant que vous planifiez la mise à niveau que vous souhaitez réellement effectuer.
TuxCare surveille le NVD, les avis de sécurité de Google et les canaux de publication en amont de Protobuf afin de détecter les vulnérabilités affectant le runtime Protobuf et son écosystème, puis rétroporte et fournit des correctifs pour les versions en fin de vie (EOL) via des processus couverts par un SLA. Que vous utilisiez actuellement les mises à jour de Protocol Buffers via Maven, Gradle, pip ou vos pipelines de build existants, vous pouvez basculer votre source de mise à jour vers le référentiel sécurisé de TuxCare avec un minimum de modifications de votre workflow actuel. Cela n'entraîne aucune perturbation de votre chaîne d'outils actuelle ni du code de service généré.
Les risques liés à une mise à niveau précipitée de Protobuf
Lorsque la pression liée à la fin de vie de Protobuf se fait sentir, qu'elle provienne des conclusions d'un audit de conformité, des alertes d'un scanner de vulnérabilités ou des signalements de l'équipe de sécurité, le réflexe est d'agir immédiatement. Mais le coût d'une réaction sans préparation adéquate s'avère systématiquement plus élevé que ce que les équipes avaient prévu. Les entreprises qui déploient une solution ELS pour Protocol Buffers échappent totalement à cette pression, car leur niveau de sécurité est maintenu pendant que la mise à niveau est planifiée de manière appropriée.
Ce qu'implique réellement une mise à jour majeure de Protobuf
Une mise à niveau majeure de Protobuf ne se résume pas à une simple augmentation du numéro de version dans votre fichier de configuration. Elle implique la régénération de tout le code généré. Chaque fichier .proto géré par votre organisation doit être recompilé avec la nouvelle version de Protobuf, ce qui produit des stubs spécifiques au langage mis à jour dont les API peuvent différer de celles actuellement appelées par le code de votre service. Cela implique une vérification de la compatibilité pour chaque service qui produit ou consomme des données sérialisées en Protobuf, afin de s'assurer que les nouvelles API générées n'introduisent pas de changements incompatibles dans les contrats de service. Cela implique une adaptation de la chaîne d'outils pour les pipelines CI/CD, les images de build Docker et toute automatisation qui invoque directement le compilateur protoc. Et cela implique une charge de travail supplémentaire en matière de tests : le comportement de sérialisation doit être validé de bout en bout sur l'ensemble des services, et les cas limites du parseur n'apparaissent que dans des conditions de trafic de production réalistes.
Dans un environnement d'entreprise où des dizaines, voire des centaines de services partagent des définitions Proto communes, où les équipes de services fonctionnent selon des cadences de déploiement différentes et où le contrôle des changements régit les déploiements en production, la mise à niveau vers la version de fin de vie (EOL) de Protobuf constitue un programme de travail coordonné, et non une simple tâche à réaliser en un sprint.
Que se passe-t-il quand la mise à jour est précipitée ?
Lorsque les équipes de service sont contraintes de procéder à une mise à niveau majeure de Protobuf en raison d’une échéance de conformité plutôt que d’un état de préparation suffisant, le scénario se répète systématiquement. Le code de remplacement régénéré introduit des divergences inattendues au niveau de l’API qui perturbent les implémentations existantes des services d’une manière qui n’apparaissait pas lors des tests automatisés. L’instabilité du système se manifeste sous la forme de cas limites de sérialisation qui ne se produisent que dans des conditions de trafic réalistes, provoquant une corruption silencieuse des données ou un comportement inattendu aux limites des services. La dette technique s'accumule à mesure que les équipes appliquent des correctifs de compatibilité et des solutions de contournement pour respecter la date limite, créant ainsi une charge de maintenance qui s'alourdit au fil des cycles de mise à niveau suivants. Et les coûts imprévus s'accumulent en heures d'ingénierie, en incidents de service et en frais opérationnels liés à la coordination d'une migration dont la portée n'avait pas été correctement définie avant son lancement.
Les équipes qui gèrent efficacement les transitions liées à la fin de vie de Protobuf sont celles qui les traitent comme des migrations planifiées, avec un inventaire complet des services, des déploiements coordonnés et un niveau de sécurité stable maintenu tout au long du processus. C'est ELS for Protocol Buffers qui rend cette approche planifiée possible.
La solution simple : TuxCare ELS pour Protocol Buffers
Depuis plus de dix ans, TuxCare perfectionne l'automatisation, l'expertise et les processus nécessaires pour fournir de manière fiable et à grande échelle des correctifs de sécurité pour les logiciels en fin de vie. Avec plus de 220 000 correctifs déployés sur l'ensemble de son portefeuille de produits pris en charge, TuxCare a mis au point un processus de correction à la fois rapide et sans risque pour la production.
ELS pour Protocol Buffers comble les lacunes en matière de sécurité et de conformité laissées par la fin de vie de Protobuf :
Correctifs de sécurité rapides, garantis par un accord de niveau de service (SLA). TuxCare surveille en permanence les divulgations de vulnérabilités et fournit des correctifs pour les CVE de niveau élevé et critique (CVSS 7.0+) dans le respect des SLA définis, garantissant ainsi que vos déploiements Protobuf respectent les délais de correction exigés par les normes PCI DSS, HIPAA, FedRAMP et d'autres cadres de conformité.
Couverture complète des environnements d'exécution. Les deux environnements d'exécution pris en charge par ELS pour Protocol Buffers sont autonomes au niveau des paquets. protobuf-java ne comporte aucune dépendance d'exécution tierce, et l'environnement d'exécution Python ne nécessite que l'interpréteur Python lui-même. La couverture ELS de ces deux environnements d'exécution englobe directement l'intégralité de leur surface de correction, sans couches transitives supplémentaires à gérer.
Intégration transparente à vos flux de travail existants. Que vous utilisiez actuellement les mises à jour de Protocol Buffers via Maven, Gradle, pip ou vos pipelines de compilation existants, vous pouvez basculer votre source de mise à jour vers le référentiel sécurisé de TuxCare en modifiant au minimum votre flux de travail actuel. Cela n'entraîne aucune perturbation de votre chaîne d'outils actuelle ni du code de service généré.
Des paquets signés et inviolables. Chaque correctif fourni par TuxCare fait l'objet de tests approfondis portant sur son intégrité, son fonctionnement et la détection des régressions avant d'être intégré à votre référentiel ; les paquets sont en outre signés cryptographiquement, ce qui vous permet de savoir exactement ce que vous déployez.
Une assistance spécialisée 24 h/24, 7 j/7. L'équipe de sécurité de TuxCare est disponible en permanence pour le triage des vulnérabilités, les demandes de correctifs et le dépannage ; vous ne serez donc jamais amené à gérer seul un incident de sécurité lié à la fin de vie de Protobuf.
Pour savoir quelles vulnérabilités CVE liées à Protocol Buffers ont déjà été corrigées, consultez l'outil de suivi des CVE en temps réel de TuxCare. Pour plus d'informations sur le processus de correction et les normes de validation de TuxCare, consultez le livre blanc technique.
Ne laissez pas la fin de vie de Protobuf mettre vos services en danger
La fin de vie de Protocol Buffers ne signifie pas que vos services cessent de sérialiser les données. Cela signifie toutefois que la protection de sécurité sur laquelle reposait votre couche de sérialisation n'existe plus, et que chaque vulnérabilité CVE détectée dans l'analyseur protobuf à partir de ce moment-là constitue un risque que vous assumez au sein de la couche qui traite chaque octet de données échangé par vos services.
Les équipes qui gèrent efficacement cette situation considèrent la fin de vie de Protobuf comme un enjeu de sécurité à gérer de manière réfléchie, et non comme une échéance à respecter sous la pression. Vous pouvez planifier une mise à niveau réfléchie vers la version majeure actuelle de Protobuf prise en charge, lorsque cela correspond réellement aux capacités de vos équipes de service, à l'état de préparation de votre infrastructure de compilation et au calendrier de déploiement de votre organisation. Vous pouvez définir correctement la portée de la régénération et du déploiement avant de vous engager sur un calendrier. Vous pouvez également utiliser l'ELS de TuxCare pour Protocol Buffers afin de maintenir la sécurité et la conformité tout en prenant ces décisions selon vos propres conditions, et non en fonction d'un calendrier d'audit de conformité.
ELS pour Protocol Buffers n'est pas une solution de secours. C'est la solution qui garantit la sécurité de votre parc de services, le respect de vos obligations de conformité et permet à vos équipes d'ingénieurs de se concentrer sur le développement, plutôt que sur la gestion de migrations de sérialisation en urgence.
Si la fin de vie de Protocol Buffers figure actuellement parmi vos priorités en matière de sécurité, rendez-vous sur le site de TuxCare Assistance tout au long du cycle de vie pour découvrir comment une assistance prolongée peut protéger votre infrastructure de sérialisation aussi longtemps que vous en avez besoin.
