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
- Les dépendances multiplient les risques liés à la fin de vie (EOL), car le backend Go de Grafana, le frontend TypeScript/React et les bibliothèques intégrées augmentent l'exposition aux vulnérabilités, qui ne seront plus corrigées une fois que Grafana aura atteint sa fin de vie.
- Les mises à jour précipitées coûtent cher, car les mises à jour majeures de Grafana peuvent perturber le fonctionnement des tableaux de bord, des plugins, des sources de données et des workflows de provisionnement, ce qui rend les migrations imprévues complexes et coûteuses.
- La fin de vie (EOL) de Grafana ne signifie pas pour autant la fin de la sécurité, car le service « Endless Lifecycle Support » (ELS) de TuxCare fournit en continu des correctifs pour les versions de Grafana qui ne sont plus prises en charge, et ce sur l'ensemble de l'arborescence des dépendances. Vous pouvez ainsi effectuer la mise à niveau selon votre propre calendrier.
Grafana est à la base des tableaux de bord, des alertes et des workflows d'observabilité largement utilisés par les entreprises du monde entier. C'est l'interface grâce à laquelle les ingénieurs et les SRE surveillent les systèmes en temps réel, la plateforme où les indicateurs métier sont transformés en informations exploitables et, dans de nombreux environnements, le premier endroit où l'on se rend lorsque quelque chose ne va pas.
Une telle omniprésence fait qu'on oublie facilement un fait dérangeant : les versions de Grafana ont une période de support définie, et lorsque celle-ci prend fin, les correctifs de sécurité cessent d'être fournis. Si vous utilisez une version de Grafana arrivée en fin de vie, vous devrez gérer vous-même toutes les vulnérabilités CVE divulguées à partir de ce moment-là, sans aucune aide de la part des développeurs.
Cet article explique comment fonctionne concrètement le cycle de vie des versions de Grafana, ce que signifie la fin de vie en termes de sécurité et de conformité, ainsi que les options qui s'offrent aux entreprises qui ne sont pas prêtes à effectuer la mise à niveau selon le calendrier de Grafana.
En quoi consiste le cycle de vie des produits Grafana ?
Grafana suit un calendrier de publication mensuel qu’il est utile de connaître avant d’aborder la question de la fin de vie (EOL). Les nouvelles versions mineures – celles qui intègrent de nouvelles fonctionnalités – sont publiées les mois pairs : février, avril, juin, etc. Les versions de correctifs, qui apportent des corrections de bogues et des mises à jour de sécurité pour les versions prises en charge, sont publiées les mois impairs. Les failles de sécurité à haut niveau de gravité donnent également lieu à des publications ponctuelles qui ne suivent pas le calendrier habituel.
Grafana utilise un système de versionnement sémantique selon la structure MAJOR.MINOR.PATCH :
- Version majeure (par exemple, 11.x) : bénéficie de nouvelles fonctionnalités via de nouvelles versions mineures. Seule la version majeure actuelle bénéficie d'un « support complet ».
- Version mineure (par exemple, 11.3) : bénéficie de mises à jour mineures, de corrections de bogues et de correctifs de sécurité jusqu'à la date de fin de vie.
- Version du correctif (par exemple, 11.3.2) : corrections de sécurité et de bogues uniquement.
Les règles relatives à la durée du support sont clairement définies. Chaque version mineure bénéficie de correctifs de sécurité et de corrections de bogues pendant neuf mois à compter de sa date de sortie. La dernière version mineure d'une version majeure bénéficie d'un support prolongé pendant quinze mois à compter de sa date de sortie, ce qui lui accorde une période plus longue pour couvrir les organisations qui ne procèdent pas à une mise à niveau à chaque version mineure. Les versions dont la période de support est écoulée sont classées dans la catégorie « Non prises en charge » : aucune mise à jour, aucun correctif, aucune correction.
| Version de Grafana | Statut | Remarques |
| 12.x (dernière version) | Assistance complète | Développement actif, corrections de bogues, correctifs de sécurité et nouvelles fonctionnalités |
| 11.x (dernière version mineure) | Assistance limitée | Uniquement des corrections de bogues critiques et des correctifs de sécurité (pas de nouvelles fonctionnalités) |
| 11.x (version mineure non finale) | Non pris en charge | Aucune garantie concernant les corrections ou les mises à jour |
| 10.x et versions antérieures | Assistance limitée / temporaire | Peut bénéficier de correctifs de sécurité critiques pendant une courte période (non garanti à long terme) |
| 9.x et versions antérieures | Fin de vie | Pas de mises à jour, pas de correctifs, pas d'assistance |
En résumé : si vous ne savez pas exactement quelle version mineure vous utilisez et quand la période de neuf mois prend fin, vous risquez facilement de vous retrouver dans une situation où le support n'est plus assuré sans vous en rendre compte.
Que signifie « EOL » dans le contexte de Grafana ?
Fin des correctifs de sécurité
Lorsqu'une version de Grafana arrive en fin de vie (EOL), le projet en amont cesse de publier des mises à jour de sécurité pour celle-ci. Cela vaut même lorsque des vulnérabilités (CVE) de gravité élevée ou critique sont révélées. Les correctifs publiés par Grafana Labs ne s'appliquent qu'aux versions prises en charge ; votre version hors support n'en bénéficie tout simplement pas.
C'est là le principal enjeu de sécurité lié à l'utilisation de logiciels en fin de vie : de nouvelles vulnérabilités sont sans cesse découvertes et rendues publiques, mais aucun correctif n'est disponible pour votre version. Votre exposition aux risques augmente à chaque fois qu'un CVE est divulgué.
Risques liés à la sécurité et à la conformité après la fin de vie
Les implications en matière de conformité sont claires. La norme PCI DSS (exigence 6.3.3) impose que les vulnérabilités critiques et à haut niveau de gravité (score CVSS de 7,0 ou plus) 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 prévoient des exigences similaires pour les environnements qu’elles couvrent. Utiliser une version EOL de Grafana dans un environnement réglementé revient en fait à exploiter une infrastructure sur laquelle vous ne pouvez pas appliquer de correctifs dans les délais exigés par les auditeurs, ce qui crée un écart de conformité difficile à justifier, quelles que soient les mesures de contrôle compensatoires mises en place.
Grafana occupant une place centrale dans les piles d'observabilité, il est souvent en contact avec des flux de données sensibles, des identifiants d'authentification pour des dizaines de sources de données et les configurations des systèmes de production. Cette combinaison d'accès et de visibilité en fait une cible de choix.
Historique des vulnérabilités CVE de Grafana
L'historique des vulnérabilités CVE de Grafana illustre concrètement ce à quoi ressemble une exposition liée à la fin du support.
CVE-2024-9264 (CVSS 9,9 – Critique) : Il s'agissait d'une vulnérabilité d'injection de commande et d'inclusion de fichier local introduite dans Grafana 11 via la fonctionnalité expérimentale SQL Expressions. Cette fonctionnalité permettait le post-traitement des résultats des requêtes de sources de données à l'aide de requêtes SQL exécutées via l'interface CLI de DuckDB. Les requêtes n'étant pas correctement validées, un attaquant pouvait injecter des commandes et lire des fichiers locaux. La vulnérabilité a été classée comme une exécution de code à distance. Grafana a publié des correctifs d'urgence pour les versions 11.x prises en charge, ce qui signifie que toute organisation utilisant une version mineure de Grafana 11 qui n'est plus prise en charge n'a reçu aucun correctif.
CVE-2021-43798 (CVSS 7.5 – High): This is one of the most widely discussed vulnerabilities in Grafana’s history. An unauthenticated attacker could traverse directories via the /public/plugins/<plugin-id>/ endpoint, bypassing path restrictions using standard ../ sequences. Because every Grafana installation ships with pre-installed plugins, there was no prerequisite that any instance on a vulnerable version was exposed. The vulnerability allowed attackers to read Grafana’s SQLite database file (which contains auth tokens and data source credentials), config files with plaintext passwords, OAuth credentials, and LDAP credentials. It was disclosed as a zero-day after proof-of-concept code was published publicly before the patch was ready, and it is listed in CISA’s Known Exploited Vulnerabilities catalog. Affected versions: 8.0.0-beta1 through 8.3.0.
Ces deux vulnérabilités ont été corrigées dans les versions prises en charge. Aucune d'entre elles n'aurait fait l'objet de correctifs pour les versions mineures dont le support a pris fin.
Le problème de l'arborescence des dépendances
Grafana n'est pas une simple application à fichier binaire unique : il s'agit d'une plateforme d'observabilité complète, dotée d'un backend en Go et d'un frontend en TypeScript/React, chacun comportant des arborescences de dépendances importantes.
Le backend utilise des modules Go pour la gestion HTTP, la cryptographie, les interfaces de base de données, la logique d'alerte, etc. Le frontend s'appuie sur React, Redux pour la gestion de l'état, D3 pour le rendu des visualisations, Emotion pour la mise en forme, Recharts, ainsi qu'une vaste collection de paquets complémentaires. Le fichier package.json du monorepo répertorie à lui seul des dizaines de dépendances front-end directes, chacune apportant son propre graphe de dépendances transitives.
Lorsque Grafana atteindra sa fin de vie (EOL), aucune de ces dépendances ne bénéficiera non plus de correctifs. Une vulnérabilité critique dans un module Go utilisé par le backend de Grafana, ou une faille XSS dans une bibliothèque de graphiques du frontend, restera sans solution dans votre version hors support, tout comme une vulnérabilité dans Grafana lui-même. Le projet en amont ne proposera pas de correctifs rétroportés pour cela. Le risque lié à la fin de vie ne concerne pas seulement Grafana, mais tout ce dont Grafana dépend.
Solutions pour garantir la sécurité et la conformité
Passez à une version prise en charge de Grafana
La mise à niveau vers une version actuellement prise en charge est toujours une option, et pour de nombreuses organisations, c'est la solution à privilégier à terme. Les guides de mise à niveau de Grafana répertorient les changements incompatibles entre les versions, et les mises à niveau vers une version mineure au sein d'une même version majeure présentent généralement moins de risques que les mises à niveau vers une version majeure.
La complexité dépend fortement de votre environnement. Les organisations qui utilisent des tableaux de bord provenant de plugins communautaires, qui ont des configurations de déploiement complexes ou qui utilisent des versions de Grafana datant de plusieurs versions majeures sont confrontées à une migration plus complexe, qui nécessite généralement de réaliser des tests dans un environnement de préproduction, de valider le rendu des tableaux de bord, de revérifier les intégrations des sources de données et d'assurer la coordination entre les équipes qui dépendent de Grafana pour la visibilité en production.
Passer à une autre plateforme d'observabilité
Le passage à une autre plateforme de surveillance et de visualisation, telle que Kibana, Datadog, Grafana Cloud ou d’autres solutions hébergées, est une option que certaines entreprises envisagent lorsqu’elles réévaluent leur pile d’observabilité dans son ensemble. Il s’agit d’une décision à long terme : les migrations de plateformes de ce type impliquent la reconfiguration des sources de données, la recréation des tableaux de bord, la réécriture des règles d’alerte et un effort considérable de formation.
Pour la plupart des organisations qui ont simplement besoin de combler la faille de sécurité d'une version spécifique de Grafana, cela ne constitue pas une solution pratique à court terme.
La solution recommandée : l'assistance à vie TuxCare pour Grafana
Le service « Endless Lifecycle Support » (ELS) de TuxCare pour Grafana est la solution qui répond directement aux problèmes de sécurité et de conformité sans nécessiter de mise à niveau immédiate. TuxCare fournit en continu des correctifs de sécurité pour les versions de Grafana qui ne bénéficient plus d'assistance – couvrant à la fois les dépendances directes et transitives de Grafana, sans frais supplémentaires –, ce qui permet aux entreprises de maintenir un niveau de sécurité défendable tout en planifiant la mise à niveau qu'elles souhaitent réellement effectuer.
Concrètement : TuxCare surveille la base de données NVD, les avis de sécurité des éditeurs et les flux de sécurité GitHub afin de détecter les vulnérabilités affectant Grafana et ses dépendances, puis rétroporte et fournit des correctifs pour les versions en fin de vie (EOL) via des processus couverts par un accord de niveau de service (SLA). Vous continuez à utiliser la version dont vous disposez, sans les risques liés à la sécurité et à la conformité que la fin de vie (EOL) entraîne habituellement.
Les risques liés à une mise à niveau précipitée de Grafana
Lorsque les dates de fin de vie arrivent, l'erreur courante consiste à considérer la mise à niveau comme une échéance à respecter sous la pression plutôt que comme un risque à gérer de manière réfléchie.
Ce qu'implique réellement une mise à niveau de Grafana
Une mise à niveau majeure de Grafana, par exemple de la version 9.x à la version 11.x, ne se fait pas sans effort. Elle implique une adaptation du code de tous les scripts de provisionnement, des configurations d'infrastructure en tant que code ou des intégrations d'API qui s'appuient sur des points de terminaison obsolètes ou modifiés. Elle implique une vérification de la compatibilité pour chaque plugin utilisé par vos tableaux de bord, car les plugins communautaires sont gérés indépendamment et n'ont peut-être pas été mis à jour pour les nouvelles versions de Grafana. Cela implique l'adaptation de la chaîne d'outils pour tous les pipelines CI/CD qui créent, testent ou déploient des configurations Grafana. Et cela implique une charge de travail supplémentaire liée aux tests: les tableaux de bord doivent être validés visuellement, les alertes doivent être reconfirmées et les requêtes sur les sources de données doivent être vérifiées pour produire des résultats cohérents.
Que se passe-t-il quand la mise à jour est précipitée ?
Lorsque les mises à niveau sont imposées par une date de fin de vie (EOL) sans la planification nécessaire, les conséquences suivent un schéma prévisible. La charge de support explose lorsque les tableaux de bord tombent en panne de manière inattendue et que les ingénieurs d'astreinte passent leur temps à déboguer des problèmes de visualisation plutôt que des défaillances système. L'instabilité du système se manifeste par des perturbations au niveau des alertes, des problèmes de connectivité aux sources de données ou des incohérences de rendu pendant la transition. La dette technique s'accumule à mesure que les équipes contournent les tests appropriés pour respecter la date butoir, créant ainsi un travail qui devra être revu ultérieurement. Et les coûts imprévus s'alourdissent : en temps d'ingénierie, en perturbations potentielles du service et en frais généraux liés à la gestion d'une migration dont la portée n'a pas été correctement définie.
Les organisations qui gèrent efficacement les changements de version de Grafana sont celles qui les considèrent comme des migrations planifiées, et non comme des interventions d'urgence.
La solution simple : TuxCare ELS pour Grafana
Depuis plus de dix ans, TuxCare met en place les automatisations, l'expertise et les processus qui lui permettent de fournir à grande échelle des correctifs de sécurité pour les logiciels en fin de vie. Avec plus de 220 000 correctifs fournis pour l'ensemble de son portefeuille de produits pris en charge, TuxCare a perfectionné un processus de correction à la fois rapide et fiable.
En ce qui concerne spécifiquement Grafana, l'ELS de TuxCare offre :
- Correctifs de sécurité rapides, couverts par un SLA: TuxCare surveille en permanence les divulgations de vulnérabilités et fournit des correctifs pour les CVE à risque élevé et critique (CVSS 7.0+) selon des SLA définis, afin que votre déploiement Grafana respecte les délais imposés par les normes PCI DSS, HIPAA et autres cadres de conformité.
- Couverture complète de l'arborescence des dépendances: TuxCare couvre à la fois les dépendances directes et transitives de votre déploiement Grafana sans frais supplémentaires. Cela signifie que les modules Go et les paquets front-end dont dépend Grafana ne constituent pas un risque caché lié à la fin de vie (EOL).
- Intégration transparente à vos flux de travail existants: Que vous utilisiez actuellement les mises à jour Grafana via des gestionnaires de paquets, des images Docker ou vos pipelines CI/CD existants, vous pouvez rediriger votre source de mise à jour vers le référentiel sécurisé de TuxCare en apportant des modifications minimes à votre flux de travail actuel. Cela n'entraîne aucune perturbation de votre chaîne d'outils actuelle.
- Paquets signés et inviolables : Chaque correctif fourni par TuxCare fait l'objet de tests approfondis portant sur son intégrité, sa fonctionnalité et la régression avant d'atteindre votre référentiel, et les paquets sont signés cryptographiquement afin que vous sachiez exactement ce que vous déployez.
- Assistance par des experts 24 h/24, 7 j/7: L'équipe de sécurité de TuxCare est disponible 24 heures sur 24 pour le triage des vulnérabilités, les demandes de correctifs et le dépannage, afin que vous ne soyez jamais confronté à un incident de sécurité lié à la fin de vie d'un produit sans assistance.
Pour savoir quelles vulnérabilités CVE de Grafana ont déjà été corrigées, TuxCare met à jour un suivi en temps réel des CVE. Pour en savoir plus sur le processus de correction de TuxCare et sur la manière dont les correctifs sont validés avant leur mise à disposition, consultez le livre blanc technique.
Ne laissez pas la fin de vie de Grafana mettre votre infrastructure de surveillance en danger
La fin de vie de Grafana ne signifie pas pour autant que votre plateforme d'observabilité est immédiatement compromise. Cela signifie toutefois que la protection sur laquelle reposait votre infrastructure n'est plus assurée, et que cette lacune doit être gérée de manière réfléchie plutôt que d'être ignorée.
Les équipes qui gèrent bien cette situation sont celles qui considèrent la fin de vie de Grafana comme un problème de sécurité à gérer, et non comme un compte à rebours auquel il faut réagir. Vous pouvez planifier une mise à niveau réfléchie vers une version actuelle de Grafana lorsque celle-ci correspond véritablement aux capacités de votre équipe, à l'état de préparation de votre écosystème de plugins et au calendrier de publication de votre organisation. Vous pouvez évaluer l'étendue totale de la migration avant de vous engager sur un calendrier. Ou vous pouvez utiliser TuxCare ELS pour maintenir la sécurité et la conformité pendant que vous prenez ces décisions selon vos propres conditions, sans subir de pression.
ELS pour Grafana n'est pas une solution de secours. C'est la solution qui garantit la sécurité de votre infrastructure de surveillance, le respect de vos obligations de conformité et permet à vos équipes d'ingénieurs de se concentrer sur le développement, et non sur des migrations d'urgence.
Si la fin de vie de Grafana figure actuellement parmi vos priorités en matière de sécurité, rendez-vous sur le support à cycle de vie illimité de TuxCare pour Grafana pour découvrir comment une assistance prolongée peut protéger votre infrastructure d'observabilité aussi longtemps que vous le souhaitez.
