Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- Que sea autónomo no significa que sea de bajo riesgo: protobuf-java y el tiempo de ejecución de Python no tienen dependencias de terceros, pero siguen analizando entradas no fiables. Cuando dejan de publicarse parches, todos los servicios de deserialización corren ese riesgo.
- Las actualizaciones precipitadas salen caras: los cambios importantes en la versión de Protobuf pueden romper las API de código generado en distintos lenguajes, lo que obliga a realizar actualizaciones coordinadas en todos los servicios que producen o consumen datos Protobuf.
- El fin del ciclo de vida (EOL) no implica el fin de la seguridad: El servicio ELS de TuxCare para Protocol Buffers mantiene actualizados los entornos de ejecución de Java y Python que ya no reciben soporte técnico mientras realizas la actualización según tu propio calendario.
La capa de serialización es uno de los riesgos de fin de vida útil (EOL) más ignorados en la infraestructura de servicios moderna. Protocol Buffers —el formato de datos independiente del lenguaje de Google— se encuentra en microservicios, API gRPC, colas de mensajes y flujos de datos en organizaciones de todos los tamaños. Cada servicio que analiza datos protobuf entrantes procesa sus cargas útiles a través de un analizador que gestiona entradas no fiables en cada solicitud. Cuando ese analizador deja de recibir parches de seguridad, la vulnerabilidad queda expuesta en todos los puntos finales que interactúan con él.
Protobuf no es una única biblioteca. Cada lenguaje tiene su propio entorno de ejecución, con su propio ciclo de versiones y su propio horizonte de fin de vida útil, y los CVE suelen ser específicos de cada lenguaje: se corrigen en algunos entornos de ejecución y en otros no. El tiempo de ejecución de Java (protobuf-java, incluido el tiempo de ejecución lite, y por extensión Kotlin y JRuby, que dependen de él) y el tiempo de ejecución de Python son dos de los más comunes en las pilas empresariales. Cuando cualquiera de ellos queda fuera de la ventana de soporte de Google, todos los servicios que dependen de él comienzan a acumular vulnerabilidades del analizador que los mantenedores de la cadena de suministro ya no corrigen.
En esta entrada se explica cómo funciona realmente el ciclo de vida de las versiones de Protocol Buffers, qué significa el fin de vida útil (EOL) de Protobuf en términos de seguridad y cumplimiento normativo, y por qué ELS para Protocol Buffers es la vía más directa para subsanar esa carencia en los entornos de ejecución de Java y Python, mientras planificas la actualización según tu propio calendario.
¿En qué consiste el ciclo de vida de las versiones de Protocol Buffers?
Protocol Buffers utiliza un modelo de control de versiones más complejo que el de la mayoría de las bibliotecas, ya que el compilador protoc y el tiempo de ejecución de cada lenguaje se actualizan de forma independiente. Comprender esto es fundamental para saber exactamente cuándo empieza a estar en riesgo tu código.
El compilador de Protocol utiliza un esquema de numeración de versiones del tipo «versión.punto», por ejemplo, 29.5. El número de versión (29) identifica la generación de funciones de Protocol, mientras que el número de punto (.5) hace referencia a las correcciones de errores y los parches incluidos en esa línea de versiones.
Los entornos de ejecución de los lenguajes utilizan un esquema MAJOR.MINOR.POINT vinculado a la versión de Protocol. Las versiones menor y puntual siguen la versión de Protocol, por lo que la versión x.29.5 del entorno de ejecución se lanzó junto con Protocol 29.5. La versión principal se incrementa de forma independiente para cada lenguaje cuando se requiere un cambio compatible con versiones anteriores para ese entorno de ejecución específico. Esto significa que los entornos de ejecución de diferentes lenguajes pueden tener versiones principales diferentes incluso cuando se lanzan al mismo tiempo: la versión 29.5 de protoc corresponde simultáneamente al entorno de ejecución de Java 4.29.5 y al de Python 5.29.5.
Las ventanas de ayuda siguen dos reglas:
El soporte para una versión menor anterior finaliza cuando se lanza la siguiente versión menor dentro de la misma versión principal.
El soporte para una versión principal anterior finaliza cuatro trimestres después del trimestre en el que se lanzó la versión que introduce cambios incompatibles. Por ejemplo, cuando se lanzó Protobuf Python 5.26.0 en el primer trimestre de 2024, se fijó el fin del soporte para Protobuf Python 4.25.x para finales del primer trimestre de 2025.
| Componente Protobuf | Esquema de control de versiones | Ventana de asistencia |
| compilador de prototipos | Punto de lanzamiento (p. ej., 29,5) | Solo la versión actual |
| Entornos de ejecución de lenguajes (menores) | MAJOR.MINOR.POINT vinculado a protoc | Finaliza cuando salgan los próximos barcos menores |
| Entornos de ejecución de lenguajes (principales) | Por idioma | Publicación de los resultados de los cuatro trimestres tras el cierre del ejercicio |
La consecuencia práctica es que, para los equipos que utilizan versiones sin soporte —como las antiguas versiones de Java 3.x o las versiones de Python 4.x o 5.x sin soporte—, ELS para Protocol Buffers es la solución para seguir contando con cobertura de seguridad.
¿Qué significa «EOL» en Protobuf?
Se acabaron los parches de seguridad
Cuando la versión del tiempo de ejecución de Protobuf queda fuera del periodo de soporte, el equipo de Protobuf de Google deja de publicar correcciones de seguridad para ella. Cualquier vulnerabilidad que se revele a partir de ese momento —ya sea en la capa de análisis, en las API de código generado o en el tratamiento que el tiempo de ejecución da a las entradas malformadas— recibirá un parche en las versiones que actualmente están bajo soporte, pero no en la tuya.
Esta es la realidad operativa de gestionar una infraestructura de serialización EOL a gran escala: los entornos de ejecución de Protobuf no son bibliotecas pasivas. Analizan activamente datos no fiables procedentes de puntos finales de red, colas de mensajes y pasarelas de API. Cada servicio que deserializa cargas útiles Protobuf entrantes está procesando datos a través de un analizador sintáctico cuyos parches de seguridad han dejado de publicarse. Esa vulnerabilidad del analizador sintáctico está presente en cada solicitud.
Riesgos de seguridad y cumplimiento tras el fin de la vida útil de Protobuf
El panorama en materia de cumplimiento normativo es igualmente claro. La norma PCI DSS (Requisito 6.3.3) exige que las vulnerabilidades críticas y de alta gravedad con una puntuación CVSS de 7,0 o superior se corrijan en el plazo de un mes desde la publicación del parche para los sistemas incluidos en el ámbito de aplicación. Las normas HIPAA, FedRAMP y SOC 2 pueden establecer requisitos similares en lo que respecta a la gestión de vulnerabilidades, la corrección de riesgos y los procesos documentados de aplicación de parches. En el caso de los servicios que gestionan datos de pago, historiales médicos o tráfico API autenticado, ejecutar un entorno de ejecución protobuf en fin de vida útil (EOL) que no se puede parchear crea una brecha de seguridad y cumplimiento que los controles compensatorios solo pueden abordar parcialmente.
Protobuf forma parte de la capa de serialización de los servicios que gestionan algunos de los datos más sensibles en entornos empresariales, como tokens de autenticación, transacciones financieras, historiales médicos y cargas útiles de API internas. Los auditores pueden considerar las bibliotecas de serialización sin parches como hallazgos significativos, ya que el analizador es el primer elemento que entra en contacto con datos de red no fiables.
Historial de CVE de Protocol Buffers
El registro CVE de Protobuf en el entorno de ejecución de Java muestra cómo se manifiesta en la práctica la vulnerabilidad del analizador tras el fin de la vida útil del producto.
CVE-2024-7254 – CVSS 7,5 (Alta). Divulgada en septiembre de 2024, esta vulnerabilidad afecta a los entornos de ejecución de Protobuf para Java (versiones completa y lite), así como a Protobuf para Kotlin y JRuby, que utilizan el entorno de ejecución de Java. El análisis de grupos anidados como campos desconocidos con DiscardUnknownFieldsParser o el analizador Java Protobuf Lite, o el análisis de campos de mapa Protobuf, crea una recursión ilimitada que un atacante puede aprovechar. Un mensaje Protobuf especialmente diseñado que contenga un número arbitrario de grupos anidados o una serie de etiquetas SGROUP puede provocar un StackOverflowError y bloquear el proceso del servidor. El ataque no requiere autenticación ni interacción del usuario, y funciona enviando una carga maliciosa a cualquier punto final que analice datos Protobuf no fiables. El vector CVSS 3.1 del NVD es CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Se publicaron parches en las versiones 3.25.5, 4.27.5 y 4.28.2; las versiones anteriores afectadas de esas líneas seguían siendo vulnerables.
Esta vulnerabilidad afectaba a todas las versiones de protobuf-java en ambas ramas principales, lo que significa que cualquier organización que utilizara un entorno de ejecución de Java protobuf fuera de servicio (EOL) estaba expuesta a una condición de denegación de servicio explotable de forma remota, sin que existiera ningún parche de origen disponible para su versión. Para los servicios que procesan tráfico de API externo, esto supone un riesgo directo para la disponibilidad.
La superficie de dependencias
Ambos entornos de ejecución cubiertos por ELS para Protocol Buffers son notablemente autónomos a nivel de paquete. protobuf-java no incluye ninguna dependencia de entornos de ejecución de terceros. El entorno de ejecución de Python solo requiere el propio intérprete de Python. La cobertura de ELS de estos dos entornos de ejecución abarca directamente toda su superficie de dependencias, sin capas transitivas adicionales que gestionar.
Opciones para mantener la seguridad y el cumplimiento normativo tras el fin de la vida útil de Protobuf
Actualiza a una versión compatible de Protobuf
La migración al último entorno de ejecución de Protobuf compatible es la estrategia adecuada a largo plazo. El equipo de Protobuf de Google publica guías de migración para cada transición a una versión principal, y se garantiza que el formato binario de transmisión seguirá siendo compatible entre versiones, lo que significa que los servicios pueden actualizar los entornos de ejecución sin que se produzcan errores en los datos serializados, ya sea en tránsito o almacenados.
La complejidad de esa migración depende de tu entorno. Un conjunto de servicios distribuidos que utiliza Protobuf no se actualiza de la misma manera que una sola aplicación. Requiere actualizar el compilador de Protobuf, regenerar todos los enlaces específicos de cada lenguaje para todos los servicios afectados, validar que los cambios generados en la API no rompan los contratos de servicio existentes, coordinar las implementaciones entre los servicios que producen y consumen datos Protobuf, y gestionar el despliegue a través de entornos de prueba con tráfico realista. Para las organizaciones que ejecutan múltiples servicios en múltiples lenguajes, cada uno de los cuales consume las mismas definiciones proto, el alcance de una migración forzada a una versión principal es considerable.
Migrar a un formato de serialización alternativo
Algunas organizaciones utilizan un evento EOL de Protobuf para evaluar formatos de serialización alternativos, como JSON, Avro, FlatBuffers, MessagePack o similares. Se trata de una decisión arquitectónica viable a largo plazo para algunos equipos, pero implica reescribir la lógica de serialización, migrar la gestión de esquemas, regenerar todas las interfaces de servicio y coordinar las migraciones entre servicios.
Para la mayoría de las organizaciones que se enfrentan a una brecha inmediata en materia de seguridad y cumplimiento normativo, la migración de formatos no es una respuesta a un plazo de aplicación de parches.
La ruta recomendada: TuxCare ELS para Protocol Buffers
El servicio ELS de TuxCare para Protocol Buffers aborda directamente los problemas de seguridad y cumplimiento normativo, sin necesidad de actualizar inmediatamente el entorno de ejecución. TuxCare proporciona parches de seguridad continuos para las versiones del entorno de ejecución de protobuf-java y Python que ya no reciben soporte, como parte de la suscripción al servicio ELS, lo que permite que su conjunto de servicios mantenga un nivel de seguridad defendible mientras planifica la actualización que realmente desea llevar a cabo.
TuxCare supervisa el NVD, los avisos de seguridad de Google y los canales de lanzamiento de Protobuf de origen en busca de vulnerabilidades que afecten al tiempo de ejecución de Protobuf y a su ecosistema; a continuación, adapta y distribuye correcciones para las versiones fuera de ciclo de vida (EOL) mediante procesos respaldados por un acuerdo de nivel de servicio (SLA). Tanto si actualmente obtienes las actualizaciones de Protocol Buffers a través de Maven, Gradle, pip o tus procesos de compilación existentes, puedes cambiar tu fuente de actualizaciones al repositorio seguro de TuxCare con cambios mínimos en tu flujo de trabajo actual. No se produce ninguna interrupción en su cadena de herramientas actual ni en el código de servicio generado.
Los riesgos de precipitarse al actualizar Protobuf
Cuando surge la presión por el fin de la vida útil de Protobuf a raíz de los resultados de auditorías de cumplimiento, las alertas de los escáneres de vulnerabilidades o las escaladas del equipo de seguridad, el instinto es actuar de inmediato. Sin embargo, el coste de reaccionar sin la preparación adecuada suele ser mucho mayor de lo que los equipos prevén. Las organizaciones que implementan ELS para Protocol Buffers evitan por completo esta presión, ya que mantienen su nivel de seguridad mientras se planifica adecuadamente la actualización.
En qué consiste realmente una actualización de la versión principal de Protobuf
Una actualización de la versión principal de Protobuf no consiste simplemente en aumentar el número de versión en el archivo de compilación. Implica regenerar todo el código generado. Cada archivo .proto que mantenga tu organización debe recompilarse con la nueva versión de Protobuf, lo que generará stubs actualizados específicos para cada lenguaje que pueden tener API diferentes a las que llama actualmente el código de tu servicio. Implica una verificación de compatibilidad en todos los servicios que producen o consumen datos serializados con Protobuf, validando que las nuevas API generadas no introduzcan cambios que rompan la compatibilidad en los contratos de servicio. Implica la adaptación de la cadena de herramientas para los pipelines de CI/CD, las imágenes de compilación de Docker y cualquier automatización que invoque directamente al compilador de protoc. E implica una sobrecarga de pruebas: el comportamiento de la serialización debe validarse de extremo a extremo en todos los servicios, y los casos extremos del analizador solo salen a la luz bajo un tráfico de producción realista.
En un entorno empresarial en el que decenas o cientos de servicios comparten definiciones Proto comunes, en el que los equipos de servicios operan con ritmos de lanzamiento diferentes y en el que el control de cambios rige las implementaciones en producción, una actualización de Protobuf al final de su ciclo de vida (EOL) es un programa de trabajo coordinado, no una tarea de sprint.
¿Qué ocurre cuando se precipita la actualización?
Cuando los equipos de servicio se ven obligados a realizar una actualización importante de Protobuf debido a un plazo de cumplimiento normativo, en lugar de por estar preparados para ello, el patrón es siempre el mismo. El código stub regenerado introduce diferencias inesperadas en la API que rompen las implementaciones de servicio existentes de formas que no se detectaron en las pruebas automatizadas. La inestabilidad del sistema se manifiesta en forma de casos extremos de serialización que solo se producen en condiciones de tráfico reales, lo que provoca una corrupción silenciosa de los datos o un comportamiento inesperado en los límites del servicio. La deuda técnica se acumula a medida que los equipos aplican soluciones de compatibilidad y soluciones provisionales para cumplir el plazo, lo que crea una carga de mantenimiento que se agrava en los ciclos de actualización posteriores. Y los costes no previstos se disparan en horas de ingeniería, en incidencias de servicio y en los gastos operativos de coordinar una migración cuyo alcance no se definió adecuadamente antes de comenzar.
Los equipos que gestionan adecuadamente las transiciones de fin de vida útil (EOL) de Protobuf son aquellos que las abordan como migraciones planificadas, con un inventario completo de servicios, implementaciones coordinadas y una postura de seguridad estable que se mantiene a lo largo de todo el proceso. ELS para Protocol Buffers es lo que hace posible ese enfoque planificado.
La solución sencilla: TuxCare ELS para Protocol Buffers
TuxCare lleva más de una década perfeccionando la automatización, los conocimientos especializados y los procesos necesarios para distribuir de forma fiable y a gran escala parches de seguridad para software al final de su ciclo de vida. Con más de 220 000 parches distribuidos en toda su cartera de productos compatibles, TuxCare ha creado un flujo de trabajo de aplicación de parches que es a la vez rápido y seguro para el entorno de producción.
ELS para Protocol Buffers cubre las carencias en materia de seguridad y cumplimiento normativo que genera el fin de la vida útil de Protobuf:
Parches de seguridad rápidos, respaldados por un acuerdo de nivel de servicio (SLA). TuxCare supervisa continuamente las divulgaciones de vulnerabilidades y proporciona parches para CVE de gravedad alta y crítica (CVSS 7.0+) según los SLA definidos, lo que garantiza que sus implementaciones de Protobuf cumplan los plazos de aplicación de parches exigidos por PCI DSS, HIPAA, FedRAMP y otros marcos de cumplimiento.
Cobertura completa del tiempo de ejecución. Los dos entornos de ejecución cubiertos por ELS para Protocol Buffers son autónomos a nivel de paquete. protobuf-java no incluye ninguna dependencia de tiempo de ejecución de terceros, y el entorno de ejecución de Python solo requiere el propio intérprete de Python. La cobertura de ELS de estos dos entornos de ejecución abarca directamente toda su superficie de parcheo, sin necesidad de gestionar capas transitivas adicionales.
Integración perfecta con tus flujos de trabajo actuales. Tanto si actualmente obtienes las actualizaciones de Protocol Buffers a través de Maven, Gradle, pip o tus procesos de compilación actuales, puedes cambiar tu fuente de actualizaciones al repositorio seguro de TuxCare con cambios mínimos en tu flujo de trabajo actual. No se producirá ninguna interrupción en tu cadena de herramientas actual ni en el código de servicio generado.
Paquetes firmados y a prueba de manipulaciones. Cada parche que TuxCare entrega se somete a exhaustivas pruebas de integridad, funcionalidad y regresión antes de llegar a tu repositorio, y los paquetes están firmados criptográficamente para que sepas exactamente qué es lo que estás implementando.
Asistencia especializada las 24 horas del día, los 7 días de la semana. El equipo de seguridad de TuxCare está disponible en todo momento para la clasificación de vulnerabilidades, las solicitudes de parches y la resolución de problemas, por lo que nunca tendrás que gestionar un incidente de seguridad relacionado con el fin de vida útil (EOL) de Protobuf sin el apoyo de especialistas.
Para ver qué vulnerabilidades CVE de Protocol Buffers ya se han solucionado, visita el rastreador de CVE en tiempo real de TuxCare. Para obtener más detalles sobre el proceso de aplicación de parches y los estándares de validación de TuxCare, consulta el informe técnico.
No dejes que el fin de la vida útil de Protobuf ponga en riesgo tus servicios
El fin de la vida útil de Protocol Buffers no significa que tus servicios dejen de serializar datos. Pero sí significa que la protección de seguridad en la que se basaba tu capa de serialización ha desaparecido, y cada vulnerabilidad CVE que surja en el analizador de protobuf a partir de ese momento supone un riesgo que asumes en la capa que procesa cada byte de los datos que intercambian tus servicios.
Los equipos que gestionan bien esta situación consideran el fin de la vida útil de Protobuf como un problema de seguridad que hay que gestionar de forma planificada, y no como una fecha límite a la que reaccionar bajo presión. Puedes planificar una actualización planificada a la versión principal de Protobuf actualmente compatible cuando realmente se ajuste a la capacidad de tus equipos de servicio, al estado de preparación de tu infraestructura de compilación y al calendario de lanzamientos de tu organización. Puede definir el alcance de la regeneración y el despliegue adecuadamente antes de comprometerse con un calendario. O bien, puede utilizar el ELS de TuxCare para Protocol Buffers a fin de mantener la cobertura de seguridad y cumplimiento mientras toma esas decisiones según sus propios términos, y no según el calendario de una auditoría de cumplimiento.
ELS para Protocol Buffers no es una solución provisional. Es la opción que garantiza la seguridad de tu parque de servicios, mantiene intacto tu nivel de cumplimiento normativo y permite que tus equipos de ingeniería se centren en desarrollar, en lugar de gestionar migraciones de serialización de emergencia.
Si el fin de la vida útil de Protocol Buffers te preocupa en estos momentos, visita Soporte de ciclo de vida ilimitado de TuxCare para ver cómo el soporte ampliado puede proteger su infraestructura de serialización durante todo el tiempo que necesite.
