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
- Las dependencias multiplican el riesgo asociado al fin de la vida útil (EOL), ya que el backend de Go de Grafana, el frontend de TypeScript/React y las bibliotecas incluidas aumentan la exposición a vulnerabilidades que dejarán de recibir parches una vez que Grafana llegue al fin de su vida útil.
- Las actualizaciones precipitadas resultan costosas, ya que las actualizaciones importantes de Grafana pueden provocar fallos en los paneles, los complementos, las fuentes de datos y los flujos de trabajo de aprovisionamiento, lo que hace que las migraciones no planificadas resulten complejas y costosas.
- El fin de la vida útil (EOL) de Grafana no supone el fin de la seguridad, ya que el servicio Endless Lifecycle Support (ELS) de TuxCare ofrece parches continuos para las versiones de Grafana que ya no reciben soporte técnico en todo el árbol de dependencias, lo que te permite actualizar según tu propio calendario.
Grafana es la base de los paneles de control, las alertas y los flujos de trabajo de observabilidad que utilizan ampliamente organizaciones de todo el mundo. Es la interfaz desde la que los ingenieros y los SRE supervisan los sistemas en tiempo real, la plataforma en la que las métricas empresariales se convierten en información útil y, en muchos entornos, el primer lugar al que se recurre cuando surge algún problema.
Esa importancia hace que sea fácil pasar por alto un hecho incómodo: las versiones de Grafana tienen un periodo de soporte definido y, cuando este finaliza, dejan de publicarse parches de seguridad. Si utilizas una versión de Grafana que ha llegado al final de su ciclo de vida, cualquier vulnerabilidad CVE que se revele a partir de ese momento será un problema que deberás gestionar por tu cuenta, sin ayuda alguna del desarrollador.
En esta entrada se explica cómo funciona en la práctica el ciclo de vida de las versiones de Grafana, qué significa el fin de la vida útil en términos prácticos de seguridad y cumplimiento normativo, y las opciones disponibles para las organizaciones que no están preparadas para actualizar según el calendario de Grafana.
¿Cuál es el ciclo de vida del producto de Grafana?
Grafana sigue un ciclo de lanzamiento mensual que conviene conocer antes de hablar sobre el fin de la vida útil (EOL). Las nuevas versiones menores —las que incluyen nuevas funciones— se lanzan en los meses pares: febrero, abril, junio, etc. Las versiones de parches, que aportan correcciones de errores y actualizaciones de seguridad para las versiones compatibles, se lanzan en los meses impares. Las vulnerabilidades de seguridad de alta gravedad también dan lugar a lanzamientos puntuales que no esperan al calendario habitual.
Grafana utiliza un sistema de versionado semántico con la estructura MAJOR.MINOR.PATCH:
- Versión principal (p. ej., 11.x): Recibe nuevas funciones a través de nuevas versiones secundarias. Solo la versión principal actual cuenta con «soporte completo».
- Versión secundaria (p. ej., 11.3): Recibe actualizaciones de parches, correcciones de errores y parches de seguridad hasta la fecha de fin de vida útil.
- Versión del parche (p. ej., 11.3.2): Solo correcciones de seguridad y errores.
Las normas relativas a la duración del soporte técnico están claramente definidas. Cada versión secundaria recibe parches de seguridad y correcciones de errores durante nueve meses a partir de su fecha de lanzamiento. La última versión secundaria de una versión principal recibe soporte técnico ampliado durante quince meses a partir de su fecha de lanzamiento, lo que ofrece un plazo más amplio para dar cobertura a las organizaciones que no actualizan en cada versión secundaria. Las versiones que superan su periodo de soporte técnico pasan a la categoría «Sin soporte técnico»: sin actualizaciones, sin parches y sin correcciones.
| Versión de Grafana | Estado | Notas |
| 12.x (última versión) | Asistencia completa | Desarrollo activo, corrección de errores, parches de seguridad y nuevas funciones |
| 11.x (última versión menor) | Asistencia limitada | Solo correcciones de errores críticos y parches de seguridad (sin nuevas funciones) |
| 11.x (versión secundaria no final) | No compatible | No se garantizan las correcciones ni las actualizaciones |
| 10.x y versiones anteriores | Asistencia limitada / transitoria | Es posible que reciba correcciones de seguridad críticas durante un breve periodo de tiempo (sin garantía a largo plazo) |
| 9.x y versiones anteriores | Final de la vida | Sin actualizaciones, sin parches, sin asistencia técnica |
En resumen: si no llevas un control de la versión menor concreta en la que te encuentras y de cuándo finaliza su periodo de nueve meses, es fácil acabar en una situación en la que ya no se ofrece soporte sin darte cuenta.
¿Qué significa «EOL» en Grafana?
Se acabaron los parches de seguridad
Cuando una versión de Grafana llega al final de su ciclo de vida (EOL), el proyecto original deja de publicar actualizaciones de seguridad para ella. Esto ocurre incluso cuando se dan a conocer vulnerabilidades CVE de gravedad alta o crítica. Los parches que publica Grafana Labs solo se aplicarán a las versiones con soporte; tu versión sin soporte simplemente no los recibirá.
Esta es la realidad de seguridad que caracteriza al uso de software al final de su ciclo de vida: continuamente se descubren y publican nuevas vulnerabilidades, pero ninguna de las correcciones llega a tu versión. Tu exposición aumenta con cada CVE que se da a conocer.
Riesgos de seguridad y cumplimiento normativo tras el fin de la vida útil
Las implicaciones en materia de cumplimiento normativo son evidentes. La norma PCI DSS (requisito 6.3.3) exige que las vulnerabilidades críticas y de alta gravedad (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 contienen requisitos similares para los entornos que regulan. Ejecutar una versión EOL de Grafana en un entorno regulado significa, en la práctica, gestionar una infraestructura a la que no se le pueden aplicar parches en los plazos exigidos por los auditores, lo que genera una brecha de cumplimiento difícil de justificar, independientemente de los controles compensatorios.
Dado que Grafana ocupa un lugar central en las pilas de observabilidad, a menudo maneja flujos de datos confidenciales, credenciales de autenticación de decenas de fuentes de datos y configuraciones de sistemas de producción. Esa combinación de acceso y visibilidad lo convierte en un objetivo muy valioso.
Historial de CVE de Grafana
El historial de CVE de Grafana ilustra cómo se manifiesta en la práctica la vulnerabilidad derivada de la falta de soporte técnico.
CVE-2024-9264 (CVSS 9,9 – Crítica): Se trataba de una vulnerabilidad de inyección de comandos e inclusión de archivos locales introducida en Grafana 11 a través de la función experimental SQL Expressions. La función permitía el posprocesamiento de la salida de consultas de fuentes de datos mediante consultas SQL ejecutadas a través de la CLI de DuckDB. Dado que las consultas no se sanitizaban adecuadamente, un atacante podía inyectar comandos y leer archivos locales. La vulnerabilidad se clasificó como ejecución remota de código. Grafana publicó parches de emergencia para las versiones 11.x compatibles, lo que significa que cualquier organización que ejecutara una versión menor de Grafana 11 fuera de soporte no recibió ningún parche.
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.
Ambas vulnerabilidades se corrigieron en las versiones para las que se ofrece soporte. Ninguna de ellas habría recibido parches para versiones menores que ya no cuentan con soporte.
El problema del árbol de dependencias
Grafana no es una simple aplicación de un solo binario, sino una plataforma de observabilidad de pila completa con un backend en Go y un frontend en TypeScript/React, cada uno de los cuales cuenta con un amplio conjunto de dependencias.
El backend utiliza módulos de Go para la gestión de HTTP, la criptografía, las interfaces de bases de datos, la lógica de alertas y mucho más. El frontend incluye React, Redux para la gestión del estado, D3 para la visualización, Emotion para el diseño, Recharts y una amplia colección de paquetes de apoyo. El archivo package.json del monorepo enumera docenas de dependencias directas solo para el frontend, cada una de las cuales trae consigo su propio gráfico de dependencias transitivas.
Cuando Grafana llegue al final de su ciclo de vida (EOL), tampoco se aplicarán parches a ninguna de esas dependencias. Una vulnerabilidad crítica en un módulo Go utilizado por el backend de Grafana, o un XSS en una biblioteca de gráficos del frontend, quedará sin resolver en tu versión fuera de soporte con la misma certeza que una vulnerabilidad en el propio Grafana. El proyecto original no realizará retroportes de las correcciones para ello. El riesgo asociado al fin de vida útil no se limita a Grafana, sino a todo aquello de lo que depende Grafana.
Opciones para garantizar la seguridad y el cumplimiento normativo
Actualiza a una versión compatible de Grafana
Actualizarse a una versión compatible actual siempre es una opción y, para muchas organizaciones, es la mejor opción a largo plazo. Las guías de actualización de Grafana recogen los cambios que implican incompatibilidades entre versiones, y las actualizaciones de versiones menores dentro de la misma versión principal suelen presentar menos riesgos que las actualizaciones de versiones principales.
La complejidad depende en gran medida de tu entorno. Las organizaciones que utilizan paneles de control creados con complementos de la comunidad, configuraciones de aprovisionamiento complejas o versiones de Grafana que están varias versiones principales atrasadas se enfrentan a una migración más compleja, que suele requerir realizar pruebas en un entorno de prueba, validar la visualización de los paneles de control, volver a confirmar las integraciones de las fuentes de datos y coordinar a los equipos que dependen de Grafana para la visibilidad de la producción.
Migrar a una plataforma de observabilidad alternativa
El cambio a otra plataforma de monitorización y visualización —como Kibana, Datadog, Grafana Cloud u otras alternativas alojadas— es una opción que algunas organizaciones barajan cuando reevalúan su pila de observabilidad en un contexto más amplio. Se trata de una decisión a largo plazo: las migraciones de plataforma de este tipo implican la reconfiguración de las fuentes de datos, la recreación de los paneles de control, la reescritura de las reglas de alertas y una carga de trabajo considerable en materia de reciclaje profesional.
Para la mayoría de las organizaciones que simplemente necesitan subsanar la vulnerabilidad de seguridad de una versión concreta de Grafana, esta no es una solución viable a corto plazo.
La opción recomendada: soporte técnico de ciclo de vida ilimitado de TuxCare para Grafana
El servicio Endless Lifecycle Support (ELS) de TuxCare para Grafana es la opción que aborda directamente los problemas de seguridad y cumplimiento normativo sin necesidad de realizar una actualización inmediata. TuxCare proporciona parches de seguridad continuos para las versiones de Grafana que ya no cuentan con soporte técnico —cubriendo tanto las dependencias directas como las transitivas de Grafana, sin coste adicional—, lo que permite a las organizaciones mantener una postura de seguridad sólida mientras planifican la actualización que realmente desean llevar a cabo.
En la práctica: TuxCare supervisa el NVD, los avisos de seguridad de los proveedores y los canales de seguridad de GitHub en busca de vulnerabilidades que afecten a Grafana y sus dependencias; a continuación, adapta y distribuye correcciones para las versiones fuera de soporte mediante procesos respaldados por un acuerdo de nivel de servicio (SLA). Así, puedes seguir utilizando la versión que tengas instalada sin los riesgos de seguridad y de cumplimiento normativo que suele conllevar el fin de soporte.
Los riesgos de precipitarse al actualizar Grafana
Cuando se acercan las fechas de fin de vida útil, el error más común es considerar la actualización como un plazo al que hay que hacer frente bajo presión, en lugar de un riesgo que hay que gestionar de forma planificada.
En qué consiste realmente una actualización de Grafana
Una actualización de versión principal de Grafana, por ejemplo, de la 9.x a la 11.x, no es un simple cambio directo. Implica adaptar el código de cualquier script de aprovisionamiento, configuración de infraestructura como código o integración de API que dependa de puntos finales obsoletos o modificados. Implica verificar la compatibilidad de todos los complementos que utilizan tus paneles, ya que los complementos de la comunidad se versionan de forma independiente y es posible que no se hayan actualizado para las versiones más recientes de Grafana. Implica adaptar la cadena de herramientas de cualquier canalización de CI/CD que compile, pruebe o implemente configuraciones de Grafana. Y conlleva una sobrecarga de pruebas: los paneles deben validarse visualmente, las alertas deben reconfirmarse y las consultas a las fuentes de datos deben verificarse para producir resultados coherentes.
¿Qué ocurre cuando se precipita la actualización?
Cuando las actualizaciones se ven obligadas por una fecha límite de fin de vida útil sin la planificación necesaria, los resultados siguen un patrón predecible. La carga de soporte técnico se dispara a medida que los paneles de control fallan de formas inesperadas y los ingenieros de guardia dedican tiempo a solucionar fallos de visualización en lugar de fallos del sistema. La inestabilidad del sistema se manifiesta en forma de interrupciones en las alertas, problemas de conectividad con las fuentes de datos o inconsistencias en la visualización durante la transición. La deuda técnica se acumula a medida que los equipos se saltan las pruebas adecuadas para cumplir el plazo, lo que genera trabajo que habrá que revisar más adelante. Y los costes imprevistos se disparan: en tiempo de ingeniería, en posibles interrupciones del servicio y en los gastos operativos de gestionar una migración cuyo alcance no se definió adecuadamente.
Las organizaciones que gestionan bien las transiciones entre versiones de Grafana son aquellas que las tratan como migraciones planificadas, y no como respuestas de emergencia.
La solución sencilla: TuxCare ELS para Grafana
TuxCare lleva más de una década desarrollando la automatización, la experiencia y los procesos que le permiten distribuir parches de seguridad a gran escala para software que ha llegado al final de su ciclo de vida. Con más de 220 000 parches distribuidos en toda su cartera de productos compatibles, TuxCare ha perfeccionado un flujo de trabajo de aplicación de parches que es a la vez rápido y fiable.
En el caso concreto de Grafana, el servicio ELS de TuxCare ofrece:
- Parches de seguridad rápidos y respaldados por un SLA: TuxCare supervisa continuamente las divulgaciones de vulnerabilidades y proporciona parches para CVE de alto riesgo y críticos (CVSS 7.0+) según los SLA definidos, lo que garantiza que su implementación de Grafana se mantenga dentro de los plazos exigidos por PCI DSS, HIPAA y otros marcos de cumplimiento.
- Cobertura completa del árbol de dependencias: TuxCare cubre tanto las dependencias directas como las transitivas de tu implementación de Grafana sin coste adicional. Esto significa que los módulos Go y los paquetes frontend de los que depende Grafana no se convierten en una exposición oculta al fin de vida útil (EOL).
- Integración perfecta con tus flujos de trabajo actuales: Tanto si actualmente obtienes las actualizaciones de Grafana a través de gestores de paquetes, imágenes de Docker o tus canalizaciones de CI/CD existentes, puedes dirigir 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 tu cadena de herramientas actual.
- 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é 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 las 24 horas del día para la clasificación de vulnerabilidades, las solicitudes de parches y la resolución de problemas, por lo que nunca tendrá que gestionar un incidente de seguridad relacionado con el fin de vida útil (EOL) sin asistencia.
Para ver qué vulnerabilidades CVE de Grafana ya se han solucionado, TuxCare mantiene un rastreador de CVE en tiempo real. Para obtener más información sobre el proceso de aplicación de parches de TuxCare y cómo se validan los parches antes de su entrega, consulte el libro blanco técnico.
No dejes que el fin de la vida útil de Grafana ponga en riesgo tu infraestructura de monitorización
El fin del ciclo de vida de Grafana no significa que tu plataforma de observabilidad quede inmediatamente en peligro. Sin embargo, sí implica que la protección de seguridad en la que se ha basado tu infraestructura ha desaparecido, y esa brecha debe gestionarse de forma deliberada, en lugar de ignorarse.
Los equipos que gestionan bien esta situación son aquellos que consideran el fin de la vida útil (EOL) de Grafana como un problema de seguridad que hay que gestionar, y no como una cuenta atrás a la que hay que reaccionar. Puedes planificar una actualización deliberada a una versión actual de Grafana cuando realmente se adapte a la capacidad de tu equipo, a la preparación de tu ecosistema de plugins y al calendario de lanzamientos de tu organización. Puedes evaluar el alcance total de la migración antes de comprometerte con un calendario. O puedes utilizar TuxCare ELS para mantener la cobertura de seguridad y cumplimiento normativo mientras tomas esas decisiones en tus propios términos, sin presiones.
ELS para Grafana no es una solución provisional. Es la opción que garantiza la seguridad de tu infraestructura de monitorización, mantiene intacto tu cumplimiento normativo y permite que tus equipos de ingeniería se centren en desarrollar, en lugar de en migraciones de emergencia.
Si el fin de la vida útil (EOL) de Grafana es una de tus prioridades de seguridad en este momento, visita el soporte de ciclo de vida ilimitado de TuxCare para Grafana para ver cómo el soporte ampliado puede proteger su infraestructura de observabilidad durante todo el tiempo que necesite.
