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
- L'arborescence des dépendances multiplie votre vulnérabilité : Un déploiement Spark en production comporte un nombre considérable de dépendances directes et transitives, notamment les bibliothèques clientes Hadoop, Netty, Jackson Databind, Apache Parquet, Apache Avro, Guava et bien d'autres, chacune comportant son propre flux CVE qui cesse de bénéficier d'une couverture coordonnée lorsque la transition vers la fin de vie (EOL) d'Apache Spark parent a lieu.
- Les mises à niveau précipitées sont coûteuses et risquées : les migrations effectuées dans la précipitation entraînent des incidents de production, une instabilité du système, une accumulation de dette technique et des coûts imprévus qui dépassent de loin le coût d'un support prolongé.
- La fin de vie (EOL) d'Apache Spark ne signifie pas la fin de la sécurité : Des options de support étendu telles que TuxCare ELS assurent une couverture de sécurité continue pour les versions en fin de vie pendant que vous planifiez vos mises à niveau de manière stratégique.
Depuis plus d'une décennie, Apache Spark est le moteur qui sous-tend l'ingénierie des données d'entreprise, l'analyse à grande échelle et l'apprentissage automatique. Sa capacité à traiter simultanément d'énormes ensembles de données en mémoire, qu'il s'agisse de tâches par lots, de pipelines de streaming ou de charges de travail d'apprentissage automatique, en a fait le choix incontournable pour les organisations traitant de grandes quantités de données dans les secteurs des services financiers, de la santé, du commerce électronique, des télécommunications et des administrations publiques.
Cependant, l'omniprésence de Spark dans les infrastructures de production critiques signifie que la question de la sécurité liée à la fin de vie d'Apache Spark revêt une réelle importance opérationnelle. Les organisations qui utilisent des versions d'Apache Spark arrivées en fin de vie s'exposent à des risques en matière de sécurité et de conformité au sein de l'une des couches les plus gourmandes en données de leur infrastructure – celle qui traite régulièrement, à grande échelle, des dossiers clients sensibles, des transactions financières et des données soumises à une réglementation.
Cet article explique ce que la fin de vie d'Apache Spark implique concrètement pour les équipes d'ingénierie des données, où se situent les véritables risques de sécurité dans l'arborescence des dépendances, pourquoi la migration vers les versions actuelles est plus complexe qu'il n'y paraît, et comment le service « Endless Lifecycle Support » (ELS) de TuxCare vous permet de maintenir une couverture complète en matière de sécurité et de conformité sans imposer à vos équipes une migration pour laquelle elles ne sont pas encore prêtes.
En quoi consiste le cycle de vie du produit Apache Spark ?
Apache Spark suit un schéma de versionnement sémantique structuré comme suit : [MAJOR].[FEATURE].[MAINTENANCE]. Les versions mineures (fonctionnelles) sont généralement publiées tous les six mois et font l'objet de corrections de bogues et de failles de sécurité pendant une période de 18 mois après leur sortie. La dernière version mineure de chaque version majeure est désignée comme version LTS (Long-Term Support, support à long terme) et est maintenue pendant une période plus longue, généralement environ 31 mois.
État de la prise en charge des versions de Spark :
| Version | Publié | Date de fin de vie | Statut |
| Spark 1.x | 2014-2015 | 2016 | EOL |
| Spark 2.4 (LTS) | Octobre 2018 | Mai 2021 | EOL |
| Spark 3.1 | Février 2021 | Août 2022 | EOL |
| Spark 3.2 | Octobre 2021 | Avril 2023 | EOL |
| Spark 3.3 | Juin 2022 | Décembre 2023 | EOL |
| Spark 3.4 | Avril 2023 | Octobre 2024 | EOL |
| Spark 3.5 (LTS) | Septembre 2023 | Avril 2026 | Actif (fin de vie imminente) |
| Spark 4.0 | Mai 2025 | Novembre 2026 | Actif |
| Spark 4.1 | Décembre 2025 | Juin 2027 | Actif (dernière version) |
Spark 3.5, dernière version LTS de la série 3.x et version la plus largement déployée dans les entreprises qui ne sont pas encore passées à la génération 4.x, devrait atteindre la fin de vie (EOL) d'Apache Spark le 12 avril 2026. Spark 3.4 a atteint la fin de vie d'Apache Spark en octobre 2024. Spark 3.3 a atteint la fin de vie d'Apache Spark en décembre 2023. Les organisations qui utilisent encore l'une de ces versions fonctionnent déjà sur des frameworks non mis à jour, et celles qui utilisent Spark 3.5 disposent d'un délai très court avant que cela ne s'applique également à elles.
Consultez notre analyse détaillée du calendrier de fin de vie d'Apache Spark pour comprendre ce que ces dates impliquent pour votre infrastructure de production.
Le modèle de fenêtre de maintenance de 18 mois implique que les transitions vers la fin de vie (EOL) d'Apache Spark se déroulent selon un calendrier précis, mais le délai entre le premier déploiement d'une version en production et le moment où une équipe d'ingénierie des données est prête à effectuer une mise à niveau validée est généralement beaucoup plus long. Lorsque la date de fin de vie d'Apache Spark arrive, la couverture de sécurité sur laquelle reposaient vos pipelines disparaît tout simplement et, contrairement aux événements de fin de vie des systèmes d'exploitation, il n'y a pas de période de grâce ni de niveau de support prolongé de la part du projet en amont lui-même.
Quelles sont les implications de la fin de vie (EOL) d'Apache Spark pour les plateformes d'ingénierie des données ?
Pour les organisations où Spark sert de moteur de traitement pour les pipelines de données en production exécutant des workflows ETL qui alimentent les systèmes financiers en aval, traitent des informations à caractère personnel à grande échelle, permettent la détection de la fraude en temps réel ou sous-tendent des bases de données de caractéristiques pour l'apprentissage automatique, la décision de mettre fin au cycle de vie d'Apache Spark constitue un enjeu direct en matière de sécurité et de conformité, et non une simple opération de maintenance en arrière-plan.
Plus aucun correctif de sécurité après la date de fin de vie d'Apache Spark
Dès qu'une version de Spark atteint la fin de son cycle de vie (End of Life) dans Apache Spark, la communauté Apache cesse de publier des correctifs de sécurité pour celle-ci. Toute vulnérabilité découverte après cette date, qu'elle concerne la couche de communication du cluster de Spark, son interface utilisateur Web, la mise en œuvre du chiffrement RPC, son intégration avec les bibliothèques clientes Hadoop ou tout autre élément du moteur, ne fera l'objet d'aucun correctif officiel pour cette branche. La seule solution proposée par la communauté consiste à passer à une version prise en charge.
Pour les organisations qui exploitent Spark dans des environnements de production complexes où les pipelines ont été conçus à partir d’API Spark spécifiques, où les tâches PySpark dépendent de versions de l’écosystème Python liées à des versions spécifiques de Spark, et où une mise à niveau de Spark nécessite des modifications coordonnées sur des dizaines de tâches dépendantes et de configurations d’infrastructure, « se contenter de mettre à niveau » n’est pas une option réalisable dans un délai court. Le délai entre le moment où le statut de fin de vie d'Apache Spark prend effet et celui où une migration peut être raisonnablement achevée et validée correspond exactement à la période pendant laquelle de nouvelles vulnérabilités s'accumulent sans qu'aucun correctif ne soit disponible.
Risques liés à la sécurité et à la conformité après la fin de vie
Les conséquences en matière de conformité liées à l'utilisation d'une version Apache Spark en fin de vie (EOL) sont bien réelles. L'exigence 6.3.3 de la norme PCI DSS impose l'installation des correctifs critiques et à haut niveau de gravité dans un délai d'un mois à compter de leur publication ; or, sur une version Apache Spark en fin de vie, aucun correctif n'est disponible, ce qui rend impossible le respect de cette exigence par les moyens habituels. Les auditeurs SOC 2 signalent la présence de logiciels en fin de vie dans les environnements de production comme une lacune de contrôle. Pour les organisations dont les clusters Spark traitent des données relevant de la norme HIPAA, du RGPD ou de la réglementation financière, l'absence de correctifs de sécurité au niveau de la couche de traitement n'est pas un risque théorique ; il s'agit d'un manquement à la conformité qui ne demande qu'à être mis en évidence.
Les organisations qui déploient Spark au sein d'un périmètre de traitement des données réglementé sont confrontées aux mêmes lacunes en matière de documentation que celles qui apparaissent dans les questionnaires de sécurité, qui bloquent les certifications des fournisseurs et, dans les secteurs réglementés, donnent lieu à des exigences de mise en conformité pouvant s'accompagner de délais très courts.
Historique des CVE : ce que révèle le registre des vulnérabilités
L'historique des vulnérabilités CVE de Spark montre clairement pourquoi le statut « fin de vie » (EOL) d'Apache Spark, dans le cadre d'une infrastructure de données d'entreprise, ne doit pas être accepté sans réagir.
CVE-2022-33891 (CVSS 8,8 - Risque élevé) est la vulnérabilité qui a le plus concrètement illustré ce à quoi ressemble, dans la pratique, l'exposition d'un Spark non corrigé. Lorsque les ACL de Spark sont activées, un chemin d'exécution dans le HttpSecurityFilter permettait à un attaquant de transmettre un nom d'utilisateur arbitraire via une usurpation d'identité. Le filtre transmettait ensuite ce nom d'utilisateur directement à une commande shell Unix utilisée pour vérifier l'appartenance à un groupe, créant ainsi une vulnérabilité d'injection de commande OS aveugle. Un attaquant ayant accès à l'interface utilisateur de Spark pouvait exécuter des commandes shell arbitraires en tant qu'utilisateur exécutant le processus Spark. La CISA a classé cette vulnérabilité comme une « vulnérabilité exploitée connue », la plaçant parmi les vulnérabilités les plus activement exploitées recensées dans l'écosystème open source. Une exploitation active dans la nature a été confirmée dans les mois qui ont suivi la divulgation. La vulnérabilité affectait plusieurs branches de Spark 3.0.x, 3.1.x et 3.2.x, qui sont toutes désormais en fin de vie (EOL). Tout futur CVE de gravité comparable affectant une branche actuellement en fin de vie ne fera l'objet d'aucun correctif officiel.
CVE-2023-22946 (CVSS 8,8 – Risque élevé) a démontré que les vulnérabilités graves ne se limitent pas aux anciennes branches de Spark. Cette vulnérabilité d'élévation de privilèges affectait toutes les versions de Spark antérieures à la version 3.4.0, ce qui signifie qu'elle touchait l'ensemble des installations de Spark 3.3.x et des versions antérieures au moment de la divulgation. Un utilisateur malveillant pouvait transmettre une classe de configuration personnalisée en tant qu'argument de ligne de commande à spark-submit, contournant ainsi les vérifications d'autorisation de l'utilisateur proxy de Spark et obtenant la capacité d'élever ses privilèges au niveau de l'utilisateur Spark soumettant la tâche. Pour les organisations où Spark est déployé dans des environnements de clusters multi-locataires, une configuration courante dans les plateformes de données d'entreprise, ce type de vulnérabilité a un impact direct sur l'intégrité du modèle de contrôle d'accès aux données.
Ces vulnérabilités concernent à la fois la couche Web du moteur Spark et son modèle de privilèges, c'est-à-dire précisément la surface d'attaque que les organisations exploitant une infrastructure de données doivent protéger.
Le risque caché : l'arborescence des dépendances de Spark
La surface d'exposition aux vulnérabilités d'un déploiement Spark en production s'étend bien au-delà des binaires du moteur Spark proprement dits. Spark est livré avec un ensemble considérable de dépendances, et chaque composant de cette arborescence génère son propre flux de CVE indépendant.
Le module Spark Core intègre Netty en tant que dépendance d'exécution directe pour toutes les communications RPC et réseau, et Netty présente un historique important de CVE, notamment des vulnérabilités affectant l'analyse des requêtes HTTP, la gestion des en-têtes et l'implémentation SSL/TLS. Jackson Databind est inclus pour la sérialisation JSON et a généré l'un des flux de CVE les plus prolifiques parmi toutes les bibliothèques Java au cours des dernières années, avec des dizaines de vulnérabilités de désérialisation révélées à travers les principales versions. Les bibliothèques clientes Apache Hadoop hadoop-common, hadoop-hdfs et hadoop-auth sont intégrées pour l'intégration HDFS et YARN et présentent leurs propres risques de sécurité. Apache Parquet est inclus comme format de stockage en colonnes par défaut. Apache Avro gère la sérialisation basée sur un schéma. Les bibliothèques clientes Apache ZooKeeper sont intégrées via Hadoop pour les services de coordination. Google Guava, Apache Commons IO, Apache Commons Lang, Apache Commons Crypto, Curator (le framework client de ZooKeeper), Protobuf et LZ4 sont tous des dépendances d'exécution. Lorsque Spark est déployé avec la bibliothèque ML (MLlib), Arrow intervient pour l'échange de données en colonnes entre les processus JVM et Python.
Lorsque Spark est intégré à Kafka pour le Structured Streaming, un modèle de production courant, la bibliothèque cliente Kafka et ses dépendances viennent s'ajouter à l'empreinte logicielle. Le graphe de dépendances transitives d'un déploiement Spark en production avec un ensemble d'intégration type compte bien plus de 100 artefacts.
Lorsqu'une branche de Spark atteint la fin de vie (EOL) d'Apache Spark, la communauté cesse de publier des mises à jour de sécurité coordonnées pour l'ensemble des dépendances associées à cette version de Spark. Les scanners de vulnérabilité utilisés sur les déploiements Apache Spark en fin de vie génèrent une liste croissante de résultats dans l'arborescence des dépendances pour lesquels aucun correctif n'est disponible, laissant les équipes de sécurité face à des résultats d'analyse insolubles qui s'accumulent à chaque nouveau cycle de publication de CVE.
Solutions pour garantir la sécurité et la conformité
Les organisations qui utilisent des versions d'Apache Spark arrivées en fin de vie ont plusieurs options à leur disposition. Certaines impliquent un effort technique considérable et des délais prolongés. Le service « Endless Lifecycle Support » de TuxCare, en revanche, comble immédiatement cette faille de sécurité.
Option 1 : Passer à une version récente de Spark
La solution à long terme consiste à passer à une version de Spark actuellement prise en charge. Les versions faisant l'objet d'une maintenance active sont Spark 3.5 (LTS, prise en charge jusqu'en avril 2026), Spark 4.0 et Spark 4.1, qui constituent les dernières versions majeures de la gamme 4.x.
Pour les organisations utilisant Spark 3.3.x ou 3.4.x, la mise à niveau vers la version LTS Spark 3.5 constitue la solution la plus simple au sein de la génération 3.x, car elle permet d'éviter les changements majeurs introduits dans Spark 4.0. Spark 3.5 maintient la compatibilité API avec les applications 3.x tout en prolongeant la couverture de sécurité jusqu'en avril 2026, date à laquelle il atteindra lui aussi la fin de vie (EOL) d'Apache Spark, faisant de Spark 4.x la seule version bénéficiant d'un support à long terme.
La mise à niveau vers Spark 4.0 ou 4.1 entraîne une série de changements incompatibles qui nécessitent une planification minutieuse au niveau des bases de code d'ingénierie des données. Spark 4.0 a cessé de prendre en charge Scala 2.12, ce qui a eu des répercussions sur de nombreuses organisations. Les applications Spark écrites en Scala doivent mettre à jour l'intégralité de leur base de code vers Scala 2.13 et recompiler tous les artefacts compilés en Scala. La prise en charge de JDK 8 et JDK 11 a été supprimée ; Java 17 est désormais la version minimale requise, ce qui nécessite des mises à niveau de la JVM sur tous les nœuds du cluster et sur tous les systèmes exécutant des tâches Spark. Le mode ANSI SQL est activé par défaut dans Spark 4.0. Les pipelines qui s'appuyaient sur le comportement de gestion des valeurs null compatible avec Hive, la coercition de type silencieuse ou la sémantique de débordement permissive lanceront des exceptions d'exécution plutôt que de renvoyer silencieusement des valeurs null ou des valeurs encapsulées, ce qui risque de corrompre les ensembles de résultats en aval ou la logique du pipeline sans messages d'erreur évidents. Les versions de Hive Metastore antérieures à la version 2.0 ne sont plus prises en charge, car elles nécessitent JDK 8.
Pour les entreprises ayant investi massivement dans Spark – c'est-à-dire la plupart de celles pour lesquelles la question de la mise à niveau revêt une importance particulière –, une migration vers Spark 4.x, correctement planifiée et testée, s'étale sur plusieurs mois, et non sur quelques semaines.
Option 2 : Migrer vers un autre cadre de traitement
Certaines organisations considèrent la fin de vie d'Apache Spark comme une occasion d'évaluer d'autres technologies de traitement des données : Apache Flink pour le traitement de flux avec état, Trino ou Apache Hive pour l'analyse SQL, Dask ou Ray pour le calcul distribué natif Python, ou encore des services gérés natifs du cloud qui masquent entièrement le moteur.
Si vous envisagez d'adopter Hive comme infrastructure cible, vous pouvez également en savoir plus sur la fin de vie (EOL) d'Apache Hive dans notre guide détaillé.
Cet argument architectural est valable dans certains contextes spécifiques, notamment lorsque les modèles d'exécution « cloud-native » sans serveur permettraient d'éliminer la charge opérationnelle liée à la gestion des clusters Spark, ou lorsque le profil de charge de travail est mieux adapté à une architecture axée sur les flux. Cependant, une migration complète du framework est nettement plus coûteuse qu'une simple mise à niveau de la version de Spark. Les requêtes Spark SQL, les transformations PySpark, les pipelines MLlib, les topologies Structured Streaming, ainsi que l'ensemble de l'infrastructure d'outils, d'orchestration et de surveillance construite autour de Spark nécessitent un remplacement ou une refonte fondamentale. Il s'agit d'une décision stratégique en matière d'infrastructure qui mérite son propre calendrier soigneusement planifié, et non une décision imposée par la date de fin de vie (EOL) d'Apache Spark.
Option 3 : Sécurisez vos systèmes dès maintenant grâce au support de cycle de vie prolongé de TuxCare
Le support à durée illimitée de TuxCare est la solution qui résout le problème immédiat sans en créer de nouveaux. Vous continuez à utiliser votre version actuelle de Spark tout en bénéficiant d'une couverture continue des correctifs de sécurité pour le framework et son arbre de dépendances, fournis via vos workflows Maven, Gradle ou pip existants, sans mise à niveau obligatoire et sans modification du fonctionnement de votre infrastructure.
La faille de sécurité est immédiatement comblée. Votre conformité est préservée. Vos équipes sont libres de planifier la mise à niveau appropriée selon un calendrier adapté aux besoins opérationnels, y compris le délai supplémentaire nécessaire pour réécrire le code Scala 2.12 en Scala 2.13, valider le comportement du pipeline sous les paramètres par défaut ANSI SQL, mettre à niveau les environnements d'exécution Java sur l'ensemble du cluster et effectuer des tests de régression sur l'ensemble des tâches de production. Pas de migration forcée sous la pression d'une échéance, pas d'urgence de conformité, pas de régressions silencieuses de la qualité des données dans les pipelines de production qui alimentent les systèmes financiers ou opérationnels en aval.
Les risques liés à une mise à niveau précipitée de Spark
Lorsque le statut « fin de vie » (EOL) d'Apache Spark apparaît sur un tableau de bord de sécurité et que l'équipe chargée de la conformité commence à poser des questions, la pression pour agir immédiatement est bien réelle. Il est tout aussi important de comprendre ce qu'implique réellement une mise à niveau précipitée de Spark que de cerner le risque lui-même.
En quoi consiste exactement la mise à niveau Spark ?
Une mise à niveau correcte de Spark, en particulier de la version 3.3.x ou 3.4.x vers la version 4.x, est un projet de plateforme de données en plusieurs phases, et non une simple mise à jour de version dans un fichier de dépendances. Elle nécessite de passer au crible l'ensemble du code à la recherche d'API obsolètes et de fonctionnalités supprimées, de mettre à niveau le runtime Java sur tous les nœuds du cluster si la version actuelle est inférieure au minimum requis par Spark 4.x, de mettre à jour les versions de Scala et de recompiler tous les artefacts compilés en Scala, ainsi que de valider toutes les configurations de cluster, les intégrations du gestionnaire de ressources et les descripteurs de déploiement par rapport à la nouvelle version.
Adaptation du code : Pour les applications Spark basées sur Scala, chaque artefact compilé sous Scala 2.12 doit être recompilé sous Scala 2.13. Les modifications apportées au mode ANSI SQL nécessitent un examen systématique de toutes les requêtes Spark SQL, des transformations de DataFrame et des fonctions définies par l'utilisateur (UDF) afin d'identifier la logique qui dépendait d'un comportement de débordement renvoyant la valeur null, d'une coercition de type permissive ou de cas limites compatibles avec Hive dans le traitement des dates et des horodatages. Dans les pipelines de grande envergure comportant des centaines d'expressions SQL, cet audit représente une tâche d'ingénierie considérable.
Vérification de la compatibilité : Les tâches PySpark doivent être validées par rapport à la nouvelle API Python Data Source et leur compatibilité avec les changements de comportement spécifiques à PySpark dans la version 4.x doit être vérifiée. Toute application Spark s'intégrant à un Hive Metastore doit vérifier que la version du metastore répond à l'exigence minimale de Spark 4.0, à savoir Hive 2.0 ou une version ultérieure. Les tâches qui utilisent Delta Lake, Apache Iceberg ou d'autres intégrations de formats de table doivent s'assurer que ces intégrations publient des versions compatibles avec Spark 4.x.
Adaptation de la chaîne d'outils : Les systèmes de compilation, les pipelines CI/CD, les images de conteneurs, les scripts de démarrage des clusters et les configurations d'orchestration qui font référence à des chaînes de version spécifiques à Spark, à des entrées de classpath ou à des indicateurs de démarrage doivent être revus et mis à jour. Le cadre de journalisation structurée de Spark a changé dans la version 4.0, ce qui affecte l'infrastructure d'analyse des journaux et les outils d'observabilité.
Charge liée aux tests : Les tests de bout en bout sur l'ensemble du catalogue des tâches de production, couvrant les pipelines ETL par lots, les tâches de streaming structuré, les workflows d'entraînement ML et les charges de travail SQL interactives, ne peuvent être raccourcis. Les changements de comportement ANSI SQL, en particulier, produisent des différences subtiles dans les résultats qui, sans générer d'erreurs, modifient silencieusement les résultats d'une manière qui n'apparaît que dans des distributions de données spécifiques ou des cas limites. La validation de la fidélité de la sortie des pipelines sur l'ensemble des tâches avec des volumes de données réalistes avant le déploiement en production n'est pas facultative pour les organisations dont les consommateurs en aval dépendent de l'exactitude des données traitées.
Que se passe-t-il lorsqu'une mise à niveau est précipitée ?
Lorsque les équipes doivent mener ce travail à bien dans l'urgence, les conséquences suivent un schéma récurrent.
Augmentation de la charge de support : Les modifications ANSI SQL non validées génèrent des exceptions d'exécution inattendues dans les tâches de production. Les incompatibilités entre Scala 2.12 et 2.13 se manifestent sous forme de conflits de classpath ou d'erreurs de méthode introuvable, difficiles à diagnostiquer sans une connaissance approfondie des bibliothèques concernées. Cela génère une vague d'incidents que les équipes d'ingénierie des données et d'exploitation des plateformes doivent gérer en plus de leur charge de travail habituelle.
Instabilité du système : Les pipelines Spark alimentent souvent les tableaux de bord, les systèmes de gestion des risques, les modèles de détection de fraude et les produits de données destinés aux clients des consommateurs en aval, où les régressions comportementales affectent immédiatement les opérations commerciales en temps réel. Des changements subtils dans la sémantique SQL, le comportement de coercition des types ou la gestion des horodatages qui n’ont pas été détectés lors des tests entraînent des problèmes de qualité des données souvent difficiles à détecter et encore plus difficiles à attribuer à la mise à niveau de Spark.
Accumulation de la dette technique : Les solutions de contournement mises en place sous la pression du temps deviennent permanentes. Les requêtes SQL corrigées à l'aide de transtypages explicites pour éviter les exceptions ANSI, sans comprendre le changement sémantique sous-jacent, introduisent leurs propres risques en matière de qualité des données. Le problème de fin de vie d'Apache Spark est reporté, mais pas résolu.
Coûts imprévus : Les heures d'ingénierie d'urgence, les retards dans la publication des produits de données, les frais généraux liés à la gestion des incidents et le coût d'opportunité lié au fait que des ingénieurs de données seniors doivent déboguer les défaillances du pipeline de production au lieu de développer de nouvelles fonctionnalités s'accumulent rapidement. Une mise à niveau précipitée qui entraîne des semaines d'incidents de production coûte bien plus cher que le support prolongé qui aurait permis de mettre en place un plan de migration mûrement réfléchi.
La solution simple : TuxCare ELS pour Apache Spark (fin de vie)
TuxCare propose une assistance technique à durée illimitée pour les versions d'Apache Spark arrivées en fin de vie. Plutôt que d'imposer une mise à niveau pour laquelle vos équipes ne sont pas encore prêtes, vous continuez à exploiter votre déploiement Spark actuel tout en bénéficiant d'une couverture continue des correctifs de sécurité via vos workflows Maven, Gradle ou pip existants, sans modifier le fonctionnement de votre infrastructure.
TuxCare s'y emploie depuis plus de dix ans, qu'il s'agisse de systèmes d'exploitation, d'environnements d'exécution, de bibliothèques ou de frameworks d'applications. L'entreprise a distribué plus de 220 000 correctifs de sécurité à travers l'écosystème open source. Lorsqu'elle affirme savoir comment assurer la sécurité des logiciels en fin de vie à l'échelle de l'entreprise, ce ne sont pas là de simples promesses marketing, mais le fruit d'une expérience opérationnelle avérée.
Pour en savoir plus sur la gestion d'autres frameworks de services Web Java hérités arrivant en fin de vie, vous pouvez également consulter notre analyse sur la fin de vie d'Apache CXF afin de découvrir comment la prise en charge prolongée s'applique à l'ensemble de votre pile technologique.
Couverture complète de l'arborescence des dépendances : L'ELS pour Spark de TuxCare couvre le framework et ses dépendances directes et transitives, notamment Netty, Jackson Databind, les bibliothèques clientes Hadoop, Apache Parquet, Apache Avro, Guava, les bibliothèques clientes ZooKeeper, Commons IO et bien d'autres, sans frais supplémentaires. Les scanners de vulnérabilité ne tiennent pas compte des limites des paquets, et la couverture de TuxCare non plus. L'ensemble de la surface de correction est pris en compte, et pas seulement l'artefact Spark de niveau supérieur.
Processus de correction optimisé et automatisé : TuxCare surveille le NVD, les avis de sécurité des fournisseurs, la liste CVE propre à Apache et les flux de sécurité GitHub, soit tous les canaux par lesquels les vulnérabilités de Spark et de ses dépendances sont divulguées. Lorsqu’un CVE est identifié, des outils algorithmiques et une automatisation assistée par l’IA se chargent de rétroporter les correctifs de sécurité vers la version prise en charge, et des experts en sécurité valident chaque correctif avant sa publication. Chaque mise à jour est soumise à des tests d’intégrité, de fonctionnalité et de régression avant d’atteindre vos référentiels. Pour plus de détails techniques, consultez le livre blanc technique de TuxCare sur son processus de correction open source.
Intégration transparente : Que vous utilisiez actuellement Spark via Maven, Gradle ou pip, 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 existant. Aucun changement n'est nécessaire au niveau de votre pipeline de build, de vos workflows CI/CD, ni du mode de fonctionnement de vos équipes d'ingénierie des données. Les mises à jour de sécurité sont automatiquement intégrées à votre chaîne d'outils existante.
Intervention rapide garantie par un accord de niveau de service (SLA) : Lorsque de nouvelles vulnérabilités sont révélées dans les versions en fin de vie d'Apache Spark, que ce soit dans le moteur lui-même ou n'importe où dans l'arborescence des dépendances, TuxCare fournit des correctifs dans des délais garantis, soutenus par des accords de niveau de service. Les vulnérabilités critiques et de gravité élevée (CVSS 7+) sont traitées dans les 14 jours suivant leur divulgation publique. Vous n'avez pas à attendre un backport de la communauté qui ne viendra jamais pour une branche Spark en fin de vie. Vous bénéficiez de correctifs prêts à l'emploi selon un calendrier prévisible, avec une assistance d'experts 24 h/24 et 7 j/7 pour le triage des vulnérabilités et le dépannage.
Une continuité de la sécurité à moindre coût : Le coût de TuxCare ELS ne représente qu'une fraction de ce que coûte une mise à niveau d'urgence (réalisée à la hâte en raison d'une échéance de conformité imminente) en termes de temps d'ingénierie, de risque opérationnel, de gestion des incidents et de retard dans la feuille de route. Une couverture de sécurité prévisible, un calendrier de mise à niveau maîtrisé et l'absence d'urgences liées à la conformité font de l'assistance prolongée la stratégie d'entreprise idéale.
Pour savoir précisément quelles vulnérabilités ont été corrigées dans les versions Apache Spark arrivées en fin de vie, TuxCare met à disposition un suivi CVE en temps réel pour Apache Spark.
Ne laissez pas la fin de vie d'Apache Spark mettre vos pipelines de données en danger
La fin de vie d'Apache Spark ne signifie pas que vos pipelines sont immédiatement compromis, ni que vous devez procéder à une mise à niveau d'urgence pour laquelle vos équipes ne sont pas préparées. Cependant, la fin de vie d'Apache Spark signifie que la protection de sécurité sur laquelle reposait votre infrastructure de traitement des données n'est plus assurée, et l'ajout de la vulnérabilité CVE-2022-33891 au catalogue des vulnérabilités exploitées de la CISA a démontré que les failles de Spark font l'objet d'exploitations réelles, et non pas seulement d'un intérêt théorique.
Les organisations qui gèrent efficacement cette situation sont celles qui considèrent la fin de vie d'Apache Spark comme un problème de sécurité à gérer, et non comme une échéance à respecter dans l'urgence. Vous pouvez planifier une mise à niveau réfléchie vers Spark 3.5, 4.0 ou 4.1 lorsque cela correspond véritablement aux capacités de votre équipe, en tenant compte du délai supplémentaire nécessaire pour valider les changements de comportement ANSI SQL sur l'ensemble de votre inventaire de tâches, mettre à jour les versions de Scala dans l'ensemble de votre base de code et effectuer des tests de régression sur les pipelines de production avec des volumes de données réalistes. Vous pouvez évaluer si une migration plus large de la plateforme répond à un véritable objectif architectural. Ou vous pouvez utiliser TuxCare ELS pour maintenir une sécurité et une conformité totales tout en prenant ces décisions selon votre propre calendrier, et non celui d'un auditeur de conformité.
Le support prolongé n'est pas une solution de fortune. C'est la solution qui garantit la sécurité de vos déploiements Spark, préserve votre conformité et permet à vos équipes d'ingénierie des données de se concentrer sur le développement plutôt que sur la gestion des urgences. Si la fin de vie (EOL) d'Apache Spark figure actuellement parmi vos priorités en matière de sécurité, rendez-vous sur le support à cycle de vie illimité de TuxCare pour les logiciels open source pour découvrir comment le support étendu peut protéger votre infrastructure de données aussi longtemps que vous en avez besoin.
