Cuántos sitios son CMS y cuántos son aplicaciones a medida

Los datos de W3Techs dicen que alrededor del 68% de los sitios con un CMS reconocido usa WordPress, Shopify o una plataforma similar. El resto, poco más de un tercio de la web pública monitorizada, no usa ninguno de los CMS que esas estadísticas rastrean. Ahí dentro hay sitios estáticos, pero también muchísimas aplicaciones a medida. No es un dato perfecto. «Ningún CMS detectado» no equivale exactamente a «aplicación a medida». Pero la dirección es clara: las web apps hechas a mano siguen siendo una porción enorme de internet.

Entre los frameworks PHP usados para estas aplicaciones, Laravel es hoy el más extendido. La encuesta State of PHP 2025 de JetBrains, sobre más de 1.700 desarrolladores, reporta un 64% de uso para Laravel. Symfony le sigue, pero bastante más atrás. En mis hostings la situación es coherente con esta tendencia. Las aplicaciones a medida que gestiono para los clientes, cuando no son WordPress, son casi siempre proyectos Laravel. Algún cliente llega ya con un proyecto existente que mantener. Otros me lo piden desde cero, sabiendo que es la opción más habitual del mercado. Los recuentos absolutos de sitios, de fuentes como BuiltWith, hay que tomarlos con cautela: Laravel incluye en su interior varios componentes de Symfony, y esto confunde un poco las estadísticas basadas solo en los paquetes instalados. Pero el panorama general no cambia: para quien escribe aplicaciones PHP a medida, hoy Laravel es el punto de partida más habitual, no la excepción.

Cómo monitorizo las actualizaciones de seguridad Laravel

Un proyecto Laravel en producción nunca está «terminado y quieto». El framework, sus componentes y las decenas de paquetes Composer que arrastra reciben parches cuando se encuentra un fallo. Si nadie lo controla, un sitio puede quedar vulnerable durante meses. El cliente, muchas veces, ni se entera. Es el mismo principio que aplico cuando tuve que gestionar un ataque en curso en un servidor durante una emergencia de seguridad PHP: mejor prevenir con un control regular, que correr detrás del problema después de que ya haya estallado.

Por eso escribí un script bash sencillo. Lo ejecuto vía cron en cada proyecto Laravel que gestiono. También lo integro en los pipelines de deploy, cuando el cliente tiene uno. No hace magia: lee el archivo de lock de Composer y lo compara con las bases de datos de vulnerabilidades conocidas. Aquí está, tal cual lo uso yo, sin modificaciones.

El script de auditoría

#!/usr/bin/env bash
set -euo pipefail

PROJECT_DIR="${1:-.}"
cd "$PROJECT_DIR"

echo "==> Project: $(pwd)"

if [[ ! -f composer.lock ]]; then
  echo "SKIP: composer.lock non trovato (non sembra un progetto composer installato)."
  exit 0
fi

echo ""
echo "==> Composer audit (vulnerabilità note)"
# --no-interaction utile in CI; fallisce (exit code != 0) se trova advisory
composer audit --no-interaction

echo ""
echo "==> Pacchetti outdated (info)"
composer outdated --direct || true

echo ""
echo "==> Laravel version (se presente)"
php -r '
$lock=json_decode(file_get_contents("composer.lock"), true);
$pkgs=array_merge($lock["packages"] ?? [], $lock["packages-dev"] ?? []);
$laravel=null;
foreach ($pkgs as $p) { if (($p["name"] ?? "")==="laravel/framework") { $laravel=$p["version"] ?? null; break; } }
echo $laravel ? "laravel/framework: $laravel\n" : "laravel/framework non trovato nel lock\n";
'

Aviso: el script se proporciona tal cual, con fines informativos. Su uso es bajo tu exclusiva responsabilidad: no asumo ninguna responsabilidad por pérdida de datos, interrupciones del servicio, o cualquier error provocado por un uso incorrecto o por un contexto distinto al que yo mismo utilizo. Haz siempre una copia de seguridad independiente antes de ejecutarlo en producción.

composer audit es un comando integrado en Composer desde la versión 2.4. Lee las versiones exactas de los paquetes dentro de composer.lock. Las compara con una base de datos de advisories de seguridad publicadas. La base de datos llega a través de Packagist, que a su vez se apoya en el repositorio FriendsOfPHP/security-advisories y en el GitHub Advisory Database. Si encuentra una coincidencia, lista el paquete, la versión vulnerable y el advisory relacionado. Luego termina con un código de salida distinto de cero. Este es el detalle que más me interesa. Un exit code no-zero es lo que permite que un cron o un pipeline entienda por sí solo que algo hay que revisar. No tengo que leer cada línea de log a mano.

En los proyectos en producción lo lanzo una vez al día vía cron, con la salida enviada por email si el comando falla. En algún cliente más estructurado lo he integrado también en el pipeline de deploy. Si composer audit encuentra un advisory bloqueante, el deploy se detiene antes de llegar a producción. Mejor detenerse ahí que descubrirlo después, con el sitio ya online. Este control diario, repetido en cada proyecto, es el corazón práctico de las actualizaciones de seguridad Laravel que aplico de verdad, no solo cuando me acuerdo de hacerlo a mano.

La segunda línea del script, composer outdated --direct, muestra solo las dependencias declaradas a mano en el composer.json. No muestra todo el árbol de dependencias transitivas. Un proyecto Laravel medio arrastra centenares de paquetes indirectos. Si los listara todos, la salida sería ilegible. Terminaría ignorándola, como pasa con demasiados avisos automáticos. Mirando solo las dependencias directas, veo de un vistazo lo que he elegido yo. Puedo decidir con calma qué actualizar y cuándo hacerlo.

La última parte del script imprime la versión de laravel/framework presente en el lock file. Lo hago porque el ciclo de vida de las versiones de Laravel tiene plazos precisos. Quiero conocerlos sin abrir cada proyecto a mano, uno por uno. Según la tabla oficial de soporte publicada por Laravel, los parches de seguridad para la versión 11 terminaron el 12 de marzo de 2026. La versión 12 los recibe hasta el 24 de febrero de 2027. Desde el primer trimestre de 2026 la versión actual es Laravel 13. Planificar las actualizaciones de seguridad Laravel con tiempo también significa esto: saber en qué versión está parado cada proyecto, antes de que venza el soporte.

Los límites honestos de este control

composer audit no es un antivirus. No lee el código de la aplicación. Señala solo vulnerabilidades conocidas y ya publicadas en un advisory. Contra un fallo zero-day, descubierto pero aún no divulgado, no sirve de nada. Por eso lo considero un control de higiene básica, no una garantía absoluta. Las actualizaciones regulares de los paquetes siguen siendo la práctica más eficaz, incluso sin un advisory en curso. La documentación oficial de Laravel recomienda mantenerse en la versión actual del framework. También recomienda automatizar las pruebas antes de cada actualización de major. Sirve para convertir la actualización en una costumbre, no en una emergencia de último minuto.

Queda el hecho de que un script de pocas líneas, lanzado cada día, me habría ahorrado más de un email incómodo a los clientes, en los años en que todavía no lo usaba. Hoy forma parte de la rutina de mantenimiento de cada proyecto Laravel que sigo. Lo combino con la monitorización de los logs y de los intentos de acceso en los servidores. Las actualizaciones de seguridad Laravel no eliminan el riesgo. Lo reducen bastante. Y cuestan muy poco, comparadas con un sitio comprometido y un cliente que pierde confianza.

The post Actualizaciones de seguridad Laravel: cómo las monitorizo first appeared on Matteo Cisilino.