Una web open source no se mantiene sola

El uso de plataformas open source ha permitido que millones de organizaciones dispongan de herramientas maduras sobre las que desarrollar webs corporativas, comercios electrónicos y servicios digitales sin tener que construir toda su infraestructura tecnológica desde cero.

Esta ventaja introduce también una responsabilidad que no siempre resulta evidente una vez publicada la web. Cada proyecto acaba formando su propio ecosistema de componentes, desarrollados y mantenidos por actores diferentes y con ciclos de actualización independientes. Cuando alguno de ellos presenta una vulnerabilidad, deja de mantenerse o requiere una actualización incompatible con otros elementos del proyecto, la decisión ya no consiste simplemente en pulsar un botón para actualizar.

La seguridad de una plataforma open source no debería medirse por el número de actualizaciones que aparecen en su panel de administración, sino por la capacidad de gestionarlas de manera continua, controlada y técnicamente informada.

El código abierto no es sinónimo de software inseguro

Una de las ideas que conviene aclarar antes de analizar los riesgos de estas plataformas es que la disponibilidad pública del código fuente no convierte por sí misma una aplicación en menos segura.

En los proyectos open source consolidados, esa misma transparencia permite que desarrolladores, investigadores y equipos especializados analicen el código, comuniquen vulnerabilidades y contribuyan a corregirlas. Plataformas ampliamente implantadas disponen además de procesos específicos para gestionar incidencias de seguridad y distribuir actualizaciones.

La cuestión relevante desde el punto de vista de una empresa no es, por tanto, si alguien puede estudiar el código de WordPress, Drupal o cualquier otra solución abierta.

La cuestión es que las vulnerabilidades descubiertas acaban siendo conocidas, documentadas y corregidas. Y desde ese momento existe una diferencia fundamental entre los sistemas que han incorporado la corrección y aquellos que continúan ejecutando una versión afectada.

Una vulnerabilidad conocida y corregida por el fabricante o la comunidad deja de ser únicamente un problema teórico para convertirse también en una cuestión de mantenimiento.

Nuestra web no es solamente WordPress, WooCommerce o Drupal

Cuando una organización afirma que su web está desarrollada en WordPress o Drupal está describiendo únicamente una parte de su arquitectura.

Una instalación real suele estar formada por el núcleo de la plataforma, una plantilla o sistema visual, extensiones funcionales, módulos, plugins, librerías de terceros y desarrollos específicos. A ello pueden añadirse sistemas de comercio electrónico, pasarelas de pago, servicios de correo, herramientas de analítica, buscadores, sistemas de consentimiento, APIs, servicios externos y numerosas integraciones.

Cada uno de esos componentes incorpora código al proyecto y puede seguir un ciclo de evolución diferente.

Esta característica constituye precisamente una de las grandes ventajas de los ecosistemas abiertos: es posible ampliar una plataforma madura incorporando funcionalidades ya existentes en lugar de desarrollarlas desde cero.

Pero esa flexibilidad tiene una consecuencia importante desde el punto de vista de la seguridad y el mantenimiento: la superficie tecnológica de la web deja de depender de un único componente.

La seguridad final es el resultado del conjunto.

WordPress, por ejemplo, dispone de mecanismos para la comunicación responsable de vulnerabilidades tanto de su núcleo como de plugins y temas. Drupal mantiene igualmente avisos diferenciados para su núcleo y para los proyectos contribuidos por terceros. En septiembre de 2026, por ejemplo, Drupal publicó avisos relativos tanto a componentes de su core como a módulos contribuidos, lo que ilustra cómo ambos niveles forman parte del mantenimiento de una instalación real.

Cada extensión amplía funcionalidades, pero también el perímetro que debemos mantener

Instalar un plugin no debería entenderse simplemente como añadir una nueva opción al panel de administración.

Estamos incorporando software desarrollado por un tercero a nuestra aplicación.

Ese software puede acceder, dependiendo de su finalidad y permisos, a información almacenada en la base de datos, procesar peticiones de usuarios, gestionar ficheros, conectarse con servicios externos o intervenir en procesos especialmente sensibles.

Esto no significa que instalar plugins sea una mala práctica. Las arquitecturas extensibles existen precisamente para permitir esta modularidad y evitar que cada proyecto tenga que desarrollar desde cero funcionalidades ampliamente resueltas.

El criterio debería estar en otro lugar.

¿Cuántos componentes necesita realmente nuestra web? ¿Quién los mantiene? ¿Con qué frecuencia evolucionan? ¿Continúan siendo compatibles con nuestra plataforma? ¿Existe una alternativa si alguno deja de mantenerse? ¿Conocemos qué función desempeña cada uno?

Una web con treinta extensiones no es necesariamente menos segura que otra con diez. El número, por sí solo, dice poco. Una instalación con numerosos componentes cuidadosamente seleccionados, mantenidos y supervisados puede presentar una situación tecnológica mucho más saludable que una instalación aparentemente sencilla que depende de unos pocos componentes abandonados.

Por eso reducir dependencias innecesarias es conveniente, pero conocer y gestionar las dependencias necesarias es todavía más importante.

Cuando existe una actualización de seguridad, aparece una segunda pregunta: ¿podemos aplicarla?

En teoría, la respuesta ante una vulnerabilidad corregida parece sencilla: actualizar.

En la práctica, una aplicación empresarial puede requerir algo más de cautela.

Una nueva versión del núcleo puede introducir cambios que afecten a determinados plugins. Un plugin actualizado puede modificar una funcionalidad utilizada por otro componente. Una extensión de comercio electrónico puede tener dependencias con una pasarela de pago, un sistema logístico o un desarrollo realizado específicamente para el proyecto.

WooCommerce, de hecho, recomienda comprobar la compatibilidad de extensiones y temas, disponer de copias de seguridad y verificar después de una actualización procesos esenciales como catálogo, carrito, pedidos, pagos, impuestos, envíos y correos. Su documentación de desarrollo insiste igualmente en probar las extensiones conjuntamente con diferentes componentes y otros plugins.

Esto introduce una diferencia fundamental entre tener actualizaciones disponibles y disponer de un proceso de actualización.

Actualizar sin evaluar compatibilidades puede generar una incidencia funcional. No actualizar por miedo a provocarla puede mantener una vulnerabilidad conocida.

Ninguna de las dos alternativas debería convertirse en la estrategia habitual.

El dilema entre seguridad y estabilidad no debería resolverse dejando de actualizar

Existe una situación relativamente frecuente en proyectos que han acumulado varios años de evolución: aparece una actualización necesaria, pero aplicarla implica modificar otros componentes que dependen de versiones anteriores.

La reacción comprensible es posponerla.

La web funciona. El cambio podría generar incompatibilidades. Hay pedidos entrando, formularios funcionando o servicios que no pueden interrumpirse. Parece prudente no tocar nada.

A corto plazo puede incluso ser una decisión técnicamente razonable mientras se prepara la intervención.

El problema aparece cuando una medida temporal se convierte en la forma habitual de mantener la plataforma.

Si cada actualización resulta demasiado arriesgada para aplicarla, la cuestión probablemente ya no sea esa actualización concreta. Puede indicar que se ha acumulado una dependencia excesiva entre componentes, que existen extensiones cuyo mantenimiento no acompaña al de la plataforma o que no disponemos de un entorno y un procedimiento adecuados para probar los cambios antes de trasladarlos a producción.

La solución no consiste en elegir permanentemente entre seguridad y estabilidad, sino en disponer de una arquitectura y un proceso de mantenimiento que permitan gestionar ambas.

Actualizar una web profesional no debería empezar en producción

La actualización técnicamente correcta de una plataforma empresarial no consiste necesariamente en acceder al panel de administración y pulsar todos los botones que indiquen que existe una nueva versión.

Dependiendo de la importancia de la aplicación, el proceso puede requerir revisar qué componentes se modifican, analizar las notas de las versiones, comprobar dependencias y compatibilidades, disponer de una copia de seguridad verificable y realizar las actualizaciones previamente en un entorno de pruebas.

Después es necesario validar aquello que realmente importa para el negocio.

En una web corporativa puede significar comprobar formularios, áreas privadas, buscadores o integraciones. En un comercio electrónico el alcance es considerablemente mayor: navegación por el catálogo, carrito, promociones, impuestos, transportistas, medios de pago, generación de pedidos, comunicaciones y conexiones con sistemas empresariales.

Precisamente por ello WooCommerce recomienda comprobar la tienda después de actualizar y realizar en entornos de prueba la resolución de problemas antes de repetir una actualización problemática en producción.

El objetivo no es complicar innecesariamente una operación que en muchos casos será rutinaria. Es conseguir que una actualización deje de ser una apuesta sobre lo que ocurrirá después.

También importa quién mantiene cada componente

Los grandes proyectos open source pueden disponer de equipos de seguridad, procesos de divulgación responsable y comunidades capaces de responder rápidamente ante determinadas incidencias.

No todos los componentes instalados sobre ellos tienen necesariamente el mismo nivel de mantenimiento.

Una extensión puede haber sido desarrollada por una empresa con un equipo dedicado, por una comunidad o por un desarrollador individual. Puede evolucionar durante muchos años o dejar de hacerlo. Puede responder rápidamente ante una vulnerabilidad o llegar al final de su ciclo de vida.

Drupal, por ejemplo, mantiene avisos específicos para proyectos contribuidos y puede llegar a indicar expresamente que un proyecto ha quedado sin soporte de seguridad.

Por este motivo, seleccionar una extensión debería implicar algo más que comprobar si proporciona la funcionalidad que necesitamos.

Su mantenimiento forma parte de la decisión técnica.

La trayectoria del proyecto, su compatibilidad con las versiones actuales, la frecuencia y calidad de sus actualizaciones, su modelo de soporte y la posibilidad de sustituirlo en el futuro son aspectos que pueden resultar tan importantes como sus funcionalidades.

La mejor extensión no siempre es la que ofrece más opciones. En muchas ocasiones es la que resuelve correctamente la necesidad introduciendo una dependencia que sabemos que podremos gestionar.

Una actualización pendiente no tiene siempre la misma prioridad

Gestionar correctamente una plataforma tampoco significa tratar todas las actualizaciones como urgentes ni aplicar cualquier nueva versión inmediatamente.

Una corrección de seguridad que afecta a una vulnerabilidad explotable desde Internet requiere una valoración diferente de una actualización funcional menor. También influyen la configuración concreta de la aplicación, las funcionalidades habilitadas, la exposición del componente y las mitigaciones existentes.

La gestión profesional consiste precisamente en poder distinguir unas situaciones de otras.

Los propios avisos de seguridad de Drupal, por ejemplo, describen no solo una vulnerabilidad sino también condiciones que pueden mitigar su impacto en determinadas configuraciones. 

Por eso el mantenimiento de seguridad debería basarse en riesgo y contexto, no exclusivamente en el contador de actualizaciones pendientes del panel de administración.

La seguridad no termina cuando hemos actualizado todos los plugins

Mantener actualizados los componentes es importante, pero sería igualmente incorrecto presentar las actualizaciones como una garantía absoluta de seguridad.

La configuración de la plataforma, la gestión de usuarios y privilegios, la infraestructura donde se ejecuta, las copias de seguridad, el control de accesos, la protección de credenciales, la monitorización y la calidad de los desarrollos específicos también forman parte del resultado.

Incluso una instalación completamente actualizada puede estar incorrectamente configurada o incorporar código propio con problemas.

De la misma manera, una plataforma correctamente diseñada puede necesitar durante un periodo breve mantener una determinada versión mientras se valida una actualización, siempre que esa decisión sea consciente, evaluada y acompañada de las medidas necesarias.

La seguridad de una aplicación web no puede reducirse a una versión de software.

Es una disciplina de gestión continua.

Open source permite construir sobre el trabajo de miles de profesionales. También exige gestionar ese ecosistema

WordPress, WooCommerce, Drupal y otras plataformas abiertas han alcanzado una enorme implantación precisamente porque permiten resolver problemas complejos sobre bases tecnológicas maduras y extensibles.

Eso es una ventaja, no una debilidad.

Pero utilizar una plataforma consolidada no traslada automáticamente a sus desarrolladores la responsabilidad sobre nuestra aplicación concreta. Ellos mantienen sus respectivos componentes. La arquitectura que hemos construido combinándolos sigue siendo nuestra.

Una organización debería saber qué elementos forman su web, cuáles son críticos, cuáles dependen de terceros, qué política de actualización tienen, cómo se comprueba su compatibilidad y qué procedimiento se seguirá cuando aparezca una actualización relevante.

Porque en una plataforma abierta, el mantenimiento no consiste únicamente en mantener actualizado el software. Consiste en mantener controlado el ecosistema sobre el que depende nuestra presencia digital.

La pregunta importante no es cuántas actualizaciones tenemos pendientes

Una instalación sin actualizaciones pendientes puede transmitir tranquilidad. Sin embargo, ese dato por sí solo no permite saber si todos sus componentes continúan mantenidos, si existen extensiones innecesarias, si los desarrollos específicos siguen siendo compatibles, si disponemos de copias de seguridad verificadas o si sabríamos reaccionar ante una vulnerabilidad relevante.

Quizá las preguntas más útiles sean otras.

¿Sabemos exactamente qué componentes forman nuestra web? ¿Conocemos quién los mantiene? ¿Podemos actualizarlos sin poner en riesgo el servicio? ¿Tenemos un entorno en el que probar los cambios? ¿Sabemos qué partes del negocio debemos validar después? ¿Existe un procedimiento si una actualización importante resulta incompatible con alguno de nuestros componentes?

Cuando estas preguntas tienen respuesta, las actualizaciones dejan de ser acontecimientos imprevisibles y pasan a formar parte de la gestión normal de la plataforma.

Y probablemente esa sea una de las mejores señales de que una web está realmente mantenida.