Mantener los plugins al día y vigilar las vulnerabilidades
Sigue los paquetes que usas, elige cómo quieres enterarte, deja que tu composer.lock vigile por ti y actúa ante los avisos de vulnerabilidades antes de que lleguen a tus sitios.
Sobre esta guía
- Dificultad
- Principiante
- Tiempo de realización
- 15 minutos
- Tiempo de lectura
- 4 min de lectura
Requisitos previos
- Una cuenta de MeteorGPL
- Un proyecto que instale paquetes desde MeteorGPL, y su
composer.lock
En esta guía
Instalar un plugin es la parte fácil. Saber cuándo necesita una actualización, y sobre todo una actualización de seguridad, es el trabajo que nunca termina. MeteorGPL tiene cuatro herramientas para ello: seguir paquetes, las notificaciones, el panel de dependencias y los avisos de vulnerabilidades. Esta guía las configura en ese orden y después muestra cómo actualizar.
Paso 1 — Sigue los paquetes que usas
La página de cada paquete tiene un menú Seguir, como en GitHub:
| Opción | Te enteras de |
|---|---|
| Toda la actividad | Nuevas versiones, avisos de seguridad y retiradas |
| Lanzamientos | Nuevas versiones (y retiradas) |
| Alertas de seguridad | Avisos de seguridad (y retiradas) |
| Personalizado | Los eventos que elijas |
| Ignorar | Nada sobre este paquete |
Al dar estrella a un paquete, también empiezas a seguir sus lanzamientos; puedes desactivarlo en tu configuración de notificaciones. Configuración → Siguiendo enumera todos los paquetes que sigues.
Paso 2 — Elige cómo quieres enterarte
En Configuración → Notificaciones eliges, para cada tipo de evento, si te llega en la aplicación, como notificación push o por correo electrónico. De forma predeterminada:
- Las nuevas versiones llegan en la aplicación y por correo electrónico.
- Los avisos de seguridad llegan en la aplicación, por push y por correo electrónico.
- Las retiradas llegan en la aplicación y por correo electrónico.
También hay un resumen semanal de lo que ha cambiado en los paquetes a los que has puesto estrella, desactivado hasta que lo actives. Las notificaciones push se activan por navegador, en la misma página.
Paso 3 — Deja que tu archivo de bloqueo vigile por ti
Seguir los paquetes uno a uno funciona con unos pocos plugins. Para un sitio entero, deja que hable el archivo de bloqueo: crea un proyecto en Configuración → Proyectos y sube el composer.lock del sitio, a mano o desde tu pipeline (consulta Tokens de Composer en CI).
La página del proyecto muestra cada paquete del repositorio como:
- al día,
- desactualizado, con las entradas del registro de cambios que te faltan,
- retirado, o
- eliminado por reclamación.
En tus proyectos personales, los paquetes del archivo de bloqueo se pueden seguir automáticamente para enterarte de sus nuevas versiones: marca Seguir las nuevas versiones de estos paquetes en la página del proyecto. Vuelve a subir el archivo de bloqueo después de cada despliegue, y el panel reflejará lo que realmente se ejecuta.
Paso 4 — Actúa ante los avisos de vulnerabilidades
Las vulnerabilidades publicadas en plugins y temas de WordPress, procedentes de la fuente de vulnerabilidades de Wordfence Intelligence, se cruzan con el catálogo. Cada coincidencia aparece:
- en la página de avisos de seguridad, que también tiene un feed Atom;
- en la sección Vulnerabilidades conocidas de la pestaña Seguridad del paquete afectado, con las versiones afectadas y, cuando existe, la versión que la corrige y la línea
composer requirepara obtenerla; - como notificación de seguridad para quienes siguen el paquete o ejecutan una versión afectada.
Los avisos publicados en los últimos 30 días alertan de inmediato a quienes siguen el paquete y a las instalaciones conocidas. Los más antiguos te alertan cuando más adelante descargas una versión afectada, o subes un archivo de bloqueo que la contiene, de modo que un sitio olvidado sigue recibiendo la alerta la próxima vez que llega su archivo de bloqueo.
Antes de publicar cualquier versión, se limpia, se compara con el propio código de licencia del proveedor, se analiza con ClamAV y reglas de patrones, y se revisa con un linter; una versión que no supera las comprobaciones no se publica, y la pestaña Seguridad muestra las comprobaciones. Si más adelante se detecta un problema, la versión se retira, se avisa a quienes siguen el paquete y se disparan los webhooks.
Paso 5 — Actualiza
Consulta qué tiene versiones más recientes y después actualiza un paquete o todos ellos dentro de tus restricciones:
composer outdated "meteorgpl-plugin/*"
composer update meteorgpl-plugin/elementor-pro
Prueba el sitio, haz commit del nuevo composer.lock y despliega con composer install. Todas las versiones publicadas siguen disponibles, así que si una actualización da problemas, volver atrás es un solo comando:
composer require meteorgpl-plugin/elementor-pro:3.20.0
Paso 6 — Automatiza con webhooks y feeds
Los webhooks (Configuración → Webhooks) envían un POST cuando un paquete que elijas recibe una nueva versión, se emite un aviso de seguridad o se retira un paquete: JSON firmado, o un mensaje listo para Slack o Discord. Verifica las entregas JSON con la cabecera X-MeteorGPL-Signature, el HMAC-SHA256 del cuerpo con el secreto de tu webhook. Un webhook JSON puede iniciar un flujo de trabajo, por ejemplo uno que ejecute composer update y abra un pull request.
Los feeds Atom no requieren cuenta: cada paquete tiene uno para sus lanzamientos (en su página), cada proveedor tiene uno, y https://meteorgpl.ddev.site/releases.atom recoge cada nueva versión del repositorio.
