Fin de la vida útil de Apache Spark: mantén la seguridad de tus flujos de datos | TuxCare ELS

Principales conclusiones

• El árbol de dependencias multiplica tu exposición: Una implementación de Spark en producción conlleva una huella considerable de dependencias directas y transitivas, bibliotecas de cliente de Hadoop, Netty, Jackson Databind, Apache Parquet, Apache Avro, Guava y muchas otras, cada una con su propio flujo de CVE que deja de recibir cobertura coordinada cuando se produce la transición de fin de vida útil (EOL) del Apache Spark principal.
• Las actualizaciones precipitadas son costosas y arriesgadas: Las migraciones realizadas por pánico provocan incidentes en la producción, inestabilidad del sistema, acumulación de deuda técnica y costes imprevistos que superan con creces el coste de la asistencia técnica ampliada.
• El fin de la vida útil (EOL) de Apache Spark no significa el fin de la seguridad: Las opciones de soporte ampliado, como TuxCare ELS, proporcionan una cobertura de seguridad continua para las versiones EOL mientras planifica las actualizaciones de forma estratégica.

Apache Spark lleva más de una década siendo el motor que impulsa la ingeniería de datos empresarial, el análisis a gran escala y el aprendizaje automático. Su capacidad para procesar simultáneamente conjuntos de datos masivos en memoria en trabajos por lotes, flujos de datos en tiempo real y cargas de trabajo de aprendizaje automático lo ha convertido en la opción predeterminada para organizaciones con un uso intensivo de datos en sectores como los servicios financieros, la sanidad, el comercio electrónico, las telecomunicaciones y las administraciones públicas.

Sin embargo, la omnipresencia de Spark en las infraestructuras de producción críticas hace que la cuestión de la seguridad tras el fin de vida útil de Apache Spark tenga un peso operativo real. Las organizaciones que utilizan versiones de Apache Spark que han llegado al final de su vida útil asumen un riesgo en materia de seguridad y cumplimiento normativo en una de las capas de su pila que más datos maneja: la capa que procesa habitualmente registros confidenciales de clientes, transacciones financieras y datos regulados a gran escala.

Este artículo explica qué implica realmente el fin de la vida útil de Apache Spark para los equipos de ingeniería de datos, dónde se acumulan los verdaderos riesgos de seguridad en el árbol de dependencias, por qué la migración a las versiones actuales es más compleja de lo que parece y cómo el servicio Endless Lifecycle Support (ELS) de TuxCare le permite mantener una cobertura total en materia de seguridad y cumplimiento normativo sin obligar a realizar una migración para la que sus equipos aún no están preparados.

¿En qué consiste el ciclo de vida del producto Apache Spark?

Apache Spark sigue un esquema de versionado semántico estructurado como [MAJOR].[FEATURE].[MAINTENANCE]. Las versiones menores (de características) suelen publicarse cada seis meses y se mantienen con correcciones de errores y de seguridad durante un periodo de 18 meses tras su lanzamiento. La última versión menor dentro de cada versión principal se designa como versión LTS (soporte a largo plazo) y se mantiene durante un periodo más largo, normalmente alrededor de 31 meses.

Estado de soporte de las versiones de Spark:

Spark 3.5, la última versión LTS de la serie 3.x y la más extendida entre las empresas que aún no han dado el salto a la generación 4.x, llegará al final de su ciclo de vida (EOL) en Apache Spark el 12 de abril de 2026. Spark 3.4 alcanzó el EOL en Apache Spark en octubre de 2024. Spark 3.3 alcanzó el EOL en Apache Spark en diciembre de 2023. Las organizaciones que aún utilizan cualquiera de esas ramas ya están operando con marcos sin parches, y las que utilizan Spark 3.5 disponen de un plazo muy breve antes de que lo mismo les ocurra a ellas.

Lee nuestro análisis detallado del calendario de fin de vida útil de Apache Spark para comprender qué implican estas fechas para tu entorno de producción.

El modelo de ventana de mantenimiento de 18 meses implica que las transiciones de fin de vida útil (EOL) de Apache Spark se producen según un calendario preestablecido, pero el tiempo que transcurre entre el momento en que una versión se implementa por primera vez en producción y el momento en que un equipo de ingeniería de datos está listo para completar una actualización validada suele ser mucho más largo. Cuando llega la fecha de fin de vida útil de Apache Spark, la cobertura de seguridad de la que dependían sus pipelines simplemente desaparece y, a diferencia de los eventos de fin de vida útil de los sistemas operativos, no hay periodo de gracia ni nivel de soporte ampliado por parte del propio proyecto original.

¿Qué implica el fin de la vida útil (EOL) de Apache Spark para las plataformas de ingeniería de datos?

Para las organizaciones en las que Spark es el motor de procesamiento de los flujos de datos de producción que ejecutan flujos de trabajo ETL para alimentar sistemas financieros posteriores, procesan información de carácter personal a gran escala, impulsan la detección de fraudes en tiempo real o sustentan los repositorios de características de aprendizaje automático, la designación de fin de vida útil de Apache Spark constituye un evento directo relacionado con la seguridad y el cumplimiento normativo, y no una simple tarea de mantenimiento secundaria.

No habrá más parches de seguridad tras la fecha de fin de vida útil de Apache Spark

Una vez que una versión de Spark alcanza el fin de su ciclo de vida (End of Life) en Apache Spark, la comunidad de Apache deja de publicar correcciones de seguridad para ella. Cualquier vulnerabilidad que se detecte a partir de esa fecha, ya sea en la capa de comunicación del clúster de Spark, en su interfaz de usuario web, en la implementación del cifrado RPC, en su integración con las bibliotecas de cliente de Hadoop o en cualquier otra parte del motor, no recibirá un parche oficial para esa rama. La única solución que ofrece la comunidad es actualizar a una versión compatible.

Para las organizaciones que ejecutan Spark en entornos de producción complejos, en los que se han creado flujos de trabajo basados en API específicas de Spark, donde los trabajos de PySpark dependen de versiones del ecosistema de Python vinculadas a versiones concretas de Spark, y donde una actualización de Spark requiere cambios coordinados en decenas de trabajos dependientes y configuraciones de infraestructura, «simplemente actualizar» no es una opción a corto plazo. El intervalo entre el momento en que entra en vigor el estado de fin de vida útil de Apache Spark y el momento en que la migración puede completarse y validarse de forma realista es precisamente el periodo durante el cual se acumulan nuevas vulnerabilidades sin que haya ninguna solución disponible.

Riesgos de seguridad y cumplimiento normativo tras el fin de la vida útil

Las consecuencias en materia de cumplimiento normativo derivadas del uso de una versión de Apache Spark que ha llegado al final de su vida útil (EOL) son muy concretas. El requisito 6.3.3 de la norma PCI DSS exige que los parches críticos y de alta gravedad se instalen en el plazo de un mes desde su publicación; sin embargo, en una versión de Apache Spark EOL no hay parches que instalar, lo que hace imposible cumplir con la normativa por los medios habituales. Los auditores de SOC 2 señalan el software EOL en entornos de producción como una deficiencia de control. Para las organizaciones en las que los clústeres de Spark procesan datos que entran en el ámbito de la HIPAA, el RGPD o la normativa financiera, la ausencia de parches de seguridad en la capa de procesamiento no es un riesgo teórico; es un hallazgo de cumplimiento activo a la espera de salir a la luz.

Las organizaciones en las que Spark se implementa dentro de un perímetro de tratamiento de datos regulado se enfrentan a las mismas deficiencias de documentación que se detectan en los cuestionarios de seguridad, que impiden la certificación de los proveedores y que, en los sectores regulados, dan lugar a requisitos de corrección que pueden tener plazos de cumplimiento muy ajustados.

Historial de CVE: lo que revela el registro de vulnerabilidades

El historial de vulnerabilidades CVE de Spark pone de manifiesto por qué el estado de fin de vida útil (EOL) de Apache Spark en un marco que se ejecuta dentro de la infraestructura de datos de una empresa no es algo que deba aceptarse de forma pasiva.

CVE-2022-33891 (CVSS 8,8 Alto) es la vulnerabilidad que ilustra de forma más concreta cómo se manifiesta en la práctica la exposición de Spark sin parchear. Cuando las ACL de Spark están habilitadas, una ruta de código en el HttpSecurityFilter permitía a un atacante pasar un nombre de usuario arbitrario mediante suplantación de identidad. A continuación, el filtro pasaba ese nombre de usuario directamente a un comando de shell de Unix utilizado para consultar la pertenencia a grupos, creando una vulnerabilidad de inyección de comandos ciega en el sistema operativo. Un atacante con acceso a la interfaz de usuario de Spark podía ejecutar comandos de shell arbitrarios como el usuario que ejecutaba el proceso de Spark. La CISA designó esta vulnerabilidad como «vulnerabilidad explotada conocida», situándola entre las vulnerabilidades más explotadas activamente de las que se hacen un seguimiento en todo el ecosistema de código abierto. Se confirmó su explotación activa en el mundo real en los meses posteriores a su divulgación. La vulnerabilidad afectaba a múltiples ramas de Spark 3.0.x, 3.1.x y 3.2.x, todas ellas ahora fuera de ciclo de vida (EOL). Cualquier CVE futuro de gravedad comparable que afecte a una rama actualmente fuera de ciclo de vida no tendrá una corrección oficial.

CVE-2023-22946 (CVSS 8.8 Alto) demostró que la exposición grave no se limita a las ramas más antiguas de Spark. Esta vulnerabilidad de escalada de privilegios afectaba a todas las versiones de Spark anteriores a la 3.4.0, lo que significa que afectaba a toda la base instalada de Spark 3.3.x y versiones anteriores en el momento de la divulgación. Un usuario malintencionado podría pasar una clase de configuración personalizada como argumento de línea de comandos a spark-submit, eludiendo las comprobaciones de permisos de usuario proxy de Spark y obteniendo la capacidad de escalar privilegios hasta el nivel del usuario de Spark que envía el trabajo. Para las organizaciones en las que Spark se implementa en entornos de clústeres multitenant, una configuración habitual en las plataformas de datos empresariales, este tipo de vulnerabilidad tiene un impacto directo en la integridad del modelo de control de acceso a los datos.

Estas vulnerabilidades afectan tanto a la capa web del motor Spark como a su modelo de privilegios, precisamente la superficie de ataque que las organizaciones que gestionan infraestructuras de datos deben mantener protegida.

El riesgo oculto: el árbol de dependencias de Spark

La superficie de vulnerabilidad de una implementación de Spark en producción va mucho más allá de los propios binarios del motor de Spark. Spark incluye un gran número de dependencias, y cada componente de ese árbol tiene su propio flujo independiente de CVE.

El módulo Spark Core incorpora Netty como dependencia directa en tiempo de ejecución para todas las comunicaciones RPC y de red, y Netty cuenta con un historial considerable de CVE, que incluye vulnerabilidades que afectan al análisis de solicitudes HTTP, al manejo de encabezados y a la implementación de SSL/TLS. Jackson Databind se incluye para la serialización JSON y ha generado algunas de las series de CVE más prolíficas de cualquier biblioteca Java en los últimos años, con docenas de vulnerabilidades de deserialización reveladas a lo largo de las principales versiones. Las bibliotecas cliente de Apache Hadoop hadoop-common, hadoop-hdfs y hadoop-auth se incluyen para la integración de HDFS y YARN y aportan su propia superficie de exposición de seguridad. Apache Parquet se incluye como formato de almacenamiento columnar predeterminado. Apache Avro se encarga de la serialización basada en esquemas. Las bibliotecas cliente de Apache ZooKeeper se incorporan a través de Hadoop para los servicios de coordinación. Google Guava, Apache Commons IO, Apache Commons Lang, Apache Commons Crypto, Curator (el marco de trabajo de cliente de ZooKeeper), Protobuf y LZ4 son todas dependencias de tiempo de ejecución. Cuando Spark se implementa con la biblioteca de ML (MLlib), Arrow se utiliza para el intercambio de datos en formato columnar entre los procesos de la JVM y Python.

Cuando Spark se integra con Kafka para Structured Streaming —un patrón de producción habitual—, la biblioteca cliente de Kafka y sus dependencias se suman a la huella de la aplicación. El gráfico de dependencias transitivas de una implementación de Spark en producción con un conjunto de integración típico abarca más de 100 artefactos.

Cuando una rama de Spark alcanza el fin de vida útil (EOL) de Apache Spark, la comunidad deja de publicar actualizaciones de seguridad coordinadas para cualquiera de esas dependencias en el contexto de esa versión de Spark. Los escáneres de vulnerabilidades que se ejecutan en implementaciones de Apache Spark EOL generan una lista cada vez mayor de hallazgos en todo el árbol de dependencias para los que no hay ninguna solución disponible, lo que deja a los equipos de seguridad con resultados de análisis irresolubles que se acumulan con cada nuevo ciclo de divulgación de CVE.

Opciones para garantizar la seguridad y el cumplimiento normativo

Las organizaciones que utilizan versiones de Apache Spark que han llegado al final de su ciclo de vida tienen varias opciones. Algunas requieren un esfuerzo técnico considerable y plazos prolongados. El servicio «Endless Lifecycle Support» de TuxCare, por el contrario, subsana inmediatamente las brechas de seguridad.

Opción 1: Actualizar a una versión reciente de Spark

La solución a largo plazo consiste en actualizar a una versión de Spark que cuente actualmente con soporte técnico. Las versiones que reciben mantenimiento activo son Spark 3.5 (LTS, con soporte hasta abril de 2026), Spark 4.0 y Spark 4.1, las versiones principales más recientes de la línea 4.x.

Para las organizaciones que utilizan Spark 3.3.x o 3.4.x, actualizar a la versión Spark 3.5 LTS es la opción más sencilla dentro de la generación 3.x, ya que evita los cambios incompatibles con versiones anteriores introducidos en Spark 4.0. Spark 3.5 mantiene la compatibilidad de la API con las aplicaciones 3.x, al tiempo que amplía la cobertura de seguridad hasta abril de 2026, tras lo cual también alcanzará el fin de vida útil (EOL) de Apache Spark, lo que convierte a Spark 4.x en el único objetivo con soporte a largo plazo.

La actualización a Spark 4.0 o 4.1 introduce una serie de cambios que rompen la compatibilidad y que requieren una planificación minuciosa en todos los códigos de ingeniería de datos. Spark 4.0 dejó de ser compatible con Scala 2.12, lo que afectó a muchas organizaciones. Las aplicaciones de Spark escritas en Scala deben actualizar todo su código a Scala 2.13 y volver a compilar todos los artefactos compilados en Scala. Se ha eliminado la compatibilidad con JDK 8 y JDK 11; Java 17 es ahora el entorno de ejecución mínimo, lo que requiere actualizaciones de la JVM en todos los nodos del clúster y en cualquier sistema que ejecute trabajos de Spark. El modo ANSI SQL está habilitado de forma predeterminada en Spark 4.0. Las tuberías que dependían del comportamiento de manejo de valores nulos compatible con Hive, la coerción de tipos silenciosa o la semántica de desbordamiento permisiva lanzarán excepciones en tiempo de ejecución en lugar de devolver silenciosamente valores nulos o valores envueltos, lo que podría romper los conjuntos de resultados posteriores o la lógica de la tubería sin mensajes de error evidentes. Las versiones de Hive Metastore anteriores a la 2.0 ya no son compatibles, ya que requieren JDK 8.

Para las organizaciones que han realizado una inversión considerable en Spark —es decir, la mayoría de aquellas para las que la cuestión de la actualización es relevante—, una migración a Spark 4.x debidamente planificada y probada se mide en meses, no en semanas.

Opción 2: Migrar a otro marco de procesamiento

Algunas organizaciones aprovechan el fin de la vida útil de Apache Spark como motivo para evaluar tecnologías alternativas de procesamiento de datos: Apache Flink para el procesamiento de flujos con estado, Trino o Apache Hive para el análisis SQL, Dask o Ray para el cálculo distribuido nativo de Python, o servicios gestionados nativos de la nube que abstraen por completo el motor.

Si estás valorando Hive como marco de trabajo, también puedes obtener más información sobre el fin de vida útil (EOL) de Apache Hive en nuestra guía detallada.

El argumento arquitectónico tiene su fundamento en contextos específicos, sobre todo cuando los modelos de ejecución sin servidor nativos de la nube eliminarían la sobrecarga operativa que supone gestionar clústeres de Spark, o cuando el patrón de carga de trabajo se adapta mejor a una arquitectura centrada en el flujo de datos. Sin embargo, una migración completa del marco de trabajo resulta considerablemente más costosa que una actualización de la versión de Spark. Las consultas de Spark SQL, las transformaciones de PySpark, los pipelines de MLlib, las topologías de Structured Streaming y toda la infraestructura de herramientas, orquestación y monitorización construida en torno a Spark requieren ser sustituidas o sometidas a una revisión fundamental. Se trata de una decisión estratégica de infraestructura que merece su propio calendario cuidadosamente planificado, no uno impuesto por una fecha de fin de vida útil (EOL) de Apache Spark.

Opción 3: Proteja sus sistemas ahora con el servicio de soporte de ciclo de vida ampliado de TuxCare

El servicio de soporte de ciclo de vida ilimitado de TuxCare es la opción que resuelve el problema inmediato sin generar otros nuevos. Podrás seguir utilizando tu versión actual de Spark mientras recibes actualizaciones de seguridad continuas para el marco y su árbol de dependencias, que se distribuyen a través de tus flujos de trabajo existentes de Maven, Gradle o pip, sin necesidad de actualizaciones obligatorias y sin cambios en el funcionamiento de tu infraestructura.

La brecha de seguridad se cierra de inmediato. Se mantiene el nivel de cumplimiento normativo. Tus equipos tienen libertad para planificar la actualización adecuada siguiendo un calendario que tenga sentido desde el punto de vista operativo, incluyendo el margen de tiempo adicional necesario para reescribir el código de Scala 2.12 a Scala 2.13, validar el comportamiento de los procesos de integración con la configuración predeterminada de ANSI SQL, actualizar los entornos de ejecución de Java en todo el clúster y realizar pruebas de regresión en el conjunto completo de tareas de producción. Sin migraciones forzadas bajo la presión de los plazos, sin emergencias de cumplimiento normativo, sin regresiones silenciosas en la calidad de los datos en los pipelines de producción que alimentan los sistemas financieros u operativos posteriores.

Los riesgos de precipitarse al actualizar Spark

Cuando el estado de fin de vida útil (EOL) de Apache Spark aparece en un panel de control de seguridad y el equipo de cumplimiento normativo empieza a hacer preguntas, la presión para actuar de inmediato es real. Comprender lo que implica realmente una actualización apresurada de Spark es tan importante como comprender el propio riesgo.

En qué consiste realmente una actualización de Spark

Una actualización adecuada de Spark, especialmente de las versiones 3.3.x o 3.4.x a la 4.x, es un proyecto de plataforma de datos que se desarrolla en varias fases, no un simple cambio de versión en un archivo de dependencias. Requiere auditar todo el código en busca de API obsoletas y funciones eliminadas, actualizar el entorno de ejecución de Java en todos los nodos del clúster si la versión actual es inferior al mínimo requerido por Spark 4.x, actualizar las versiones de Scala y recompilar todos los artefactos compilados en Scala, y validar todas las configuraciones del clúster, las integraciones del gestor de recursos y los descriptores de implementación con respecto a la nueva versión.

Adaptación del código: Para las aplicaciones Spark basadas en Scala, todos los artefactos compilados con Scala 2.12 deben recompilarse con Scala 2.13. Los cambios en el modo ANSI SQL requieren una revisión sistemática de todas las consultas Spark SQL, las transformaciones de DataFrame y las UDF para identificar la lógica que dependía del comportamiento de desbordamiento con retorno nulo, la coerción de tipos permisiva o los casos extremos compatibles con Hive en el manejo de fechas y marcas de tiempo. En grandes canalizaciones con cientos de expresiones SQL, esta auditoría supone una tarea de ingeniería considerable.

Verificación de compatibilidad: Los trabajos de PySpark deben validarse con la nueva API de origen de datos de Python y comprobarse su compatibilidad con cualquier cambio de comportamiento específico de PySpark en la versión 4.x. Cualquier aplicación de Spark que se integre con un Hive Metastore debe verificar que la versión del metastore cumple el requisito mínimo de Spark 4.0 de Hive 2.0 o posterior. Los trabajos que utilicen Delta Lake, Apache Iceberg u otras integraciones de formatos de tabla deben confirmar que dichas integraciones publiquen versiones compatibles con Spark 4.x.

Adaptación de la cadena de herramientas: Es necesario revisar y actualizar los sistemas de compilación, los flujos de CI/CD, las imágenes de contenedores, los scripts de arranque de clústeres y las configuraciones de orquestación que hagan referencia a cadenas de versión específicas de Spark, entradas de la ruta de clases o indicadores de inicio. El marco de registro estructurado de Spark cambió en la versión 4.0, lo que afecta a la infraestructura de análisis de registros y a las herramientas de observabilidad.

Carga de trabajo de las pruebas: Las pruebas de extremo a extremo en todo el inventario de trabajos de producción, que abarcan canalizaciones ETL por lotes, trabajos de Structured Streaming, flujos de trabajo de entrenamiento de ML y cargas de trabajo SQL interactivas, no pueden abreviarse. Los cambios de comportamiento de ANSI SQL, en particular, producen diferencias sutiles en la salida que pueden no generar errores, pero que modificarán silenciosamente los resultados de formas que solo se manifiestan bajo distribuciones de datos específicas o entradas de casos extremos. Validar la fidelidad de la salida de los procesos en todo el conjunto de trabajos con volúmenes de datos realistas antes de pasar a producción no es opcional para las organizaciones en las que los consumidores posteriores dependen de la corrección de los datos procesados.

¿Qué ocurre cuando se precipita una actualización?

Cuando los equipos se ven obligados a acelerar este trabajo bajo la presión de los plazos, las consecuencias siguen un patrón constante.

Aumento de la carga de soporte técnico: Los cambios no validados en ANSI SQL provocan excepciones de tiempo de ejecución inesperadas en los trabajos de producción. Las incompatibilidades de Scala 2.12/2.13 se manifiestan como conflictos en la ruta de clases o errores de «método no encontrado» que son difíciles de diagnosticar sin un conocimiento profundo de las bibliotecas afectadas. Esto genera una oleada de incidencias que los equipos de ingeniería de datos y operaciones de la plataforma deben gestionar además de sus cargas de trabajo habituales.

Inestabilidad del sistema: Los pipelines de Spark suelen alimentar los paneles de control, los sistemas de riesgo, los modelos de fraude y los productos de datos orientados al cliente de los consumidores posteriores, donde las regresiones de comportamiento afectan de forma inmediata a las operaciones empresariales en tiempo real. Los cambios sutiles en la semántica de SQL, el comportamiento de la conversión de tipos o el manejo de las marcas de tiempo que no se detectaron durante las pruebas generan problemas de calidad de los datos que suelen ser difíciles de detectar y aún más difíciles de atribuir a la actualización de Spark.

Acumulación de deuda técnica: Las soluciones provisionales implementadas bajo presión de tiempo se convierten en permanentes. Las consultas SQL parcheadas con conversiones de tipo explícitas para evitar excepciones ANSI, sin comprender el cambio semántico subyacente, introducen sus propios riesgos para la calidad de los datos. El problema del fin de vida útil de Apache Spark se aplaza, pero no se resuelve.

Costes imprevistos: Las horas de ingeniería de emergencia, los retrasos en el lanzamiento de productos de datos, los gastos generales de respuesta a incidentes y el coste de oportunidad que supone que los ingenieros de datos sénior dediquen su tiempo a depurar fallos en el canal de producción en lugar de desarrollar nuevas capacidades se acumulan rápidamente. Una actualización apresurada que provoca semanas de incidentes de producción cuesta mucho más que la ampliación del soporte técnico que habría permitido llevar a cabo un plan de migración planificado.

La solución sencilla: TuxCare ELS para Apache Spark EOL

TuxCare ofrece soporte técnico de ciclo de vida ilimitado para las versiones de Apache Spark que han llegado al final de su vida útil. En lugar de obligar a realizar una actualización para la que sus equipos aún no están preparados, podrá seguir ejecutando su implementación actual de Spark con cobertura continua de parches de seguridad a través de sus flujos de trabajo existentes de Maven, Gradle o pip, sin necesidad de modificar el funcionamiento de su infraestructura.

TuxCare lleva más de una década dedicándose a esto en distintos sistemas operativos, entornos de ejecución, bibliotecas y marcos de aplicaciones. Ha distribuido más de 220 000 parches de seguridad en todo el ecosistema de código abierto. Cuando afirman que saben cómo mantener seguro el software al final de su ciclo de vida a escala empresarial, no se trata de un eslogan de marketing, sino de una trayectoria operativa demostrada.

Si deseas obtener más información sobre la gestión de otros marcos de trabajo heredados de servicios web Java que están llegando al final de su ciclo de vida, también puedes consultar nuestro análisis sobre el fin del ciclo de vida de Apache CXF para ver cómo se aplica el soporte ampliado en toda tu pila tecnológica.

Cobertura completa del árbol de dependencias: El ELS para Spark de TuxCare cubre el marco y sus dependencias directas y transitivas, incluyendo Netty, Jackson Databind, las bibliotecas de cliente de Hadoop, Apache Parquet, Apache Avro, Guava, las bibliotecas de cliente de ZooKeeper, Commons IO y otras, sin coste adicional. Los escáneres de vulnerabilidades no respetan los límites de los paquetes, y tampoco lo hace la cobertura de TuxCare. Se aborda toda la superficie de parches, no solo el artefacto Spark de nivel superior.

Proceso de aplicación de parches optimizado y automatizado: TuxCare supervisa el NVD, los avisos de seguridad de los proveedores, la propia lista CVE de Apache y los canales de seguridad de GitHub, todos los canales en los que se revelan las vulnerabilidades de Spark y sus dependencias. Cuando se identifica un CVE, las herramientas algorítmicas y la automatización asistida por IA se encargan de aplicar las correcciones de seguridad a la versión compatible, y los expertos en seguridad validan cada parche antes de su distribución. Cada actualización se somete a pruebas de integridad, funcionalidad y regresión antes de llegar a sus repositorios. Para obtener todos los detalles técnicos, consulte el informe técnico de TuxCare sobre su proceso de aplicación de parches de código abierto.

Integración perfecta: Tanto si actualmente utiliza Spark a través de Maven, Gradle o pip, puede cambiar su fuente de actualizaciones al repositorio seguro de TuxCare con cambios mínimos en su flujo de trabajo actual. No hay cambios en su canal de compilación, ni en sus flujos de trabajo de CI/CD, ni en el funcionamiento de sus equipos de ingeniería de datos. Las actualizaciones de seguridad se distribuyen automáticamente a través de su cadena de herramientas existente.

Respuesta rápida respaldada por un acuerdo de nivel de servicio (SLA): Cuando se revelan nuevas vulnerabilidades en versiones de Apache Spark al final de su ciclo de vida, ya sea en el propio motor o en cualquier parte del árbol de dependencias, TuxCare entrega parches en un plazo garantizado respaldado por acuerdos de nivel de servicio. Las vulnerabilidades críticas y de alta gravedad (CVSS 7+) se abordan en un plazo de 14 días desde su divulgación pública. No tendrá que esperar a una adaptación de la comunidad que nunca llegará para una rama de Spark al final de su ciclo de vida. Obtendrá parches listos para producción en un plazo que podrá planificar, con asistencia de expertos las 24 horas del día, los 7 días de la semana, para la clasificación de vulnerabilidades y la resolución de problemas.

Continuidad de la seguridad a un precio asequible: El coste de TuxCare ELS es una fracción de lo que cuesta una actualización de emergencia (apresurada debido a un plazo de cumplimiento inminente) en tiempo de ingeniería, riesgo operativo, respuesta a incidentes y retrasos en el trabajo de la hoja de ruta. Una cobertura de seguridad predecible, un calendario de actualizaciones controlado y la ausencia de emergencias de cumplimiento son los factores que hacen que el soporte ampliado sea la estrategia empresarial adecuada.

Para ver exactamente qué vulnerabilidades se han solucionado en las versiones de Apache Spark que han llegado al final de su ciclo de vida (EOL), TuxCare mantiene un rastreador CVE en tiempo real para Apache Spark.

No dejes que el fin de la vida útil de Apache Spark ponga en riesgo tus flujos de datos

El fin de la vida útil de Apache Spark no significa que tus procesos de datos se vean comprometidos de inmediato, ni que debas llevar a cabo una actualización de emergencia para la que tus equipos no estén preparados. Sin embargo, el estado de fin de vida útil de Apache Spark sí significa que la cobertura de seguridad de la que dependía su infraestructura de procesamiento de datos ya no existe, y la inclusión de CVE-2022-33891 en el catálogo de vulnerabilidades explotadas conocidas de la CISA ha demostrado que las vulnerabilidades de Spark son objeto de explotación en el mundo real, y no solo de interés teórico.

Las organizaciones que gestionan bien esta situación son aquellas que consideran el fin de la vida útil de Apache Spark como un problema de seguridad que hay que gestionar, y no como una fecha límite a la que hay que reaccionar bajo presión. Puede planificar una actualización deliberada a Spark 3.5, 4.0 o 4.1 cuando realmente se ajuste a la capacidad de su equipo, incluyendo el tiempo adicional necesario para validar los cambios de comportamiento de ANSI SQL en todo su inventario de trabajos, actualizar las versiones de Scala en todo su código base y realizar pruebas de regresión en los flujos de trabajo de producción con volúmenes de datos realistas. Puede evaluar si una migración más amplia de la plataforma tiene una finalidad arquitectónica real. O puede utilizar TuxCare ELS para mantener la seguridad y el cumplimiento totales mientras toma esas decisiones según su propio calendario, y no el de un auditor de cumplimiento.

El soporte ampliado no es una solución provisional. Es la opción que mantiene seguras tus implementaciones de Spark, garantiza el cumplimiento normativo y permite que tus equipos de ingeniería de datos se centren en desarrollar, en lugar de en apagar incendios. Si el fin de la vida útil (EOL) de Apache Spark figura actualmente entre tus prioridades de seguridad, visita el soporte de ciclo de vida ilimitado de TuxCare para software de código abierto para ver cómo el soporte ampliado puede proteger su infraestructura de datos durante todo el tiempo que necesite.

Resumen

Nombre del artículo

Fin de la vida útil de Apache Spark: riesgos, brechas de seguridad y próximos pasos

Descripción

¿Utilizas Apache Spark en entorno de producción? Mantén la seguridad y el cumplimiento normativo sin necesidad de una migración forzada. TuxCare ELS amplía la cobertura de seguridad más allá del fin de vida útil (EOL).

Autor

Artem Karasev

Nombre del editor

TuxCare

Logotipo de la editorial