{"id":1393,"date":"2026-11-03T09:00:00","date_gmt":"2026-11-03T08:00:00","guid":{"rendered":"https:\/\/www.cisilino.com\/?p=1393"},"modified":"2026-11-03T09:02:50","modified_gmt":"2026-11-03T08:02:50","slug":"actualizaciones-seguridad-laravel-composer-audit","status":"publish","type":"post","link":"https:\/\/www.cisilino.com\/es\/2026\/11\/03\/actualizaciones-seguridad-laravel-composer-audit\/","title":{"rendered":"Actualizaciones de seguridad Laravel: c\u00f3mo las monitorizo"},"content":{"rendered":"\n

Gestiono varios servidores en producci\u00f3n. La mayor parte del tr\u00e1fico que pasa por mis hostings va hacia sitios WordPress. Pero no todo. Cuando un cliente me pide un software de gesti\u00f3n a medida, un backend para una app, o un peque\u00f1o e-commerce con reglas no est\u00e1ndar, el CMS ya no basta. Ah\u00ed entran en juego los frameworks PHP. Para las actualizaciones de seguridad Laravel<\/strong> he montado un control que realmente ejecuto, no solo en teor\u00eda.<\/p>\n\n\n\n

\"actualizaciones<\/figure>\n\n\n\n

Cu\u00e1ntos sitios son CMS y cu\u00e1ntos son aplicaciones a medida<\/h2>\n\n\n\n

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\u00e1s de un tercio de la web p\u00fablica monitorizada, no usa ninguno de los CMS que esas estad\u00edsticas rastrean. Ah\u00ed dentro hay sitios est\u00e1ticos, pero tambi\u00e9n much\u00edsimas aplicaciones a medida. No es un dato perfecto. \u00abNing\u00fan CMS detectado\u00bb no equivale exactamente a \u00abaplicaci\u00f3n a medida\u00bb. Pero la direcci\u00f3n es clara: las web apps hechas a mano siguen siendo una porci\u00f3n enorme de internet.<\/p>\n\n\n\n

Entre los frameworks PHP usados para estas aplicaciones, Laravel es hoy el m\u00e1s extendido. La encuesta State of PHP 2025 de JetBrains, sobre m\u00e1s de 1.700 desarrolladores, reporta un 64% de uso para Laravel. Symfony le sigue, pero bastante m\u00e1s atr\u00e1s. En mis hostings la situaci\u00f3n es coherente con esta tendencia. Las aplicaciones a medida que gestiono para los clientes, cuando no son WordPress, son casi siempre proyectos Laravel. Alg\u00fan cliente llega ya con un proyecto existente que mantener. Otros me lo piden desde cero, sabiendo que es la opci\u00f3n m\u00e1s 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\u00edsticas 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\u00e1s habitual, no la excepci\u00f3n.<\/p>\n\n\n\n

C\u00f3mo monitorizo las actualizaciones de seguridad Laravel<\/h2>\n\n\n\n

Un proyecto Laravel en producci\u00f3n nunca est\u00e1 \u00abterminado y quieto\u00bb. 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<\/a>: mejor prevenir con un control regular, que correr detr\u00e1s del problema despu\u00e9s de que ya haya estallado.<\/p>\n\n\n\n

Por eso escrib\u00ed un script bash sencillo. Lo ejecuto v\u00eda cron en cada proyecto Laravel que gestiono. Tambi\u00e9n 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\u00ed est\u00e1, tal cual lo uso yo, sin modificaciones.<\/p>\n\n\n\n

El script de auditor\u00eda<\/h3>\n\n\n\n
#!\/usr\/bin\/env bash\nset -euo pipefail\n\nPROJECT_DIR=\"${1:-.}\"\ncd \"$PROJECT_DIR\"\n\necho \"==> Project: $(pwd)\"\n\nif [[ ! -f composer.lock ]]; then\n  echo \"SKIP: composer.lock non trovato (non sembra un progetto composer installato).\"\n  exit 0\nfi\n\necho \"\"\necho \"==> Composer audit (vulnerabilit\u00e0 note)\"\n# --no-interaction utile in CI; fallisce (exit code != 0) se trova advisory\ncomposer audit --no-interaction\n\necho \"\"\necho \"==> Pacchetti outdated (info)\"\ncomposer outdated --direct || true\n\necho \"\"\necho \"==> Laravel version (se presente)\"\nphp -r '\n$lock=json_decode(file_get_contents(\"composer.lock\"), true);\n$pkgs=array_merge($lock[\"packages\"] ?? [], $lock[\"packages-dev\"] ?? []);\n$laravel=null;\nforeach ($pkgs as $p) { if (($p[\"name\"] ?? \"\")===\"laravel\/framework\") { $laravel=$p[\"version\"] ?? null; break; } }\necho $laravel ? \"laravel\/framework: $laravel\\n\" : \"laravel\/framework non trovato nel lock\\n\";\n'\n<\/code><\/pre>\n\n\n\n
Aviso<\/strong>: el script se proporciona tal cual, con fines informativos. Su uso es bajo tu exclusiva responsabilidad: no asumo ninguna responsabilidad por p\u00e9rdida 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\u00f3n.<\/p>\n\n\n\n
composer audit<\/code> es un comando integrado en Composer desde la versi\u00f3n 2.4. Lee las versiones exactas de los paquetes dentro de composer.lock<\/code>. Las compara con una base de datos de advisories de seguridad publicadas. La base de datos llega a trav\u00e9s 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\u00f3n vulnerable y el advisory relacionado. Luego termina con un c\u00f3digo de salida distinto de cero. Este es el detalle que m\u00e1s me interesa. Un exit code no-zero es lo que permite que un cron o un pipeline entienda por s\u00ed solo que algo hay que revisar. No tengo que leer cada l\u00ednea de log a mano.<\/p>\n\n\n\n
En los proyectos en producci\u00f3n lo lanzo una vez al d\u00eda v\u00eda cron, con la salida enviada por email si el comando falla. En alg\u00fan cliente m\u00e1s estructurado lo he integrado tambi\u00e9n en el pipeline de deploy. Si composer audit<\/code> encuentra un advisory bloqueante, el deploy se detiene antes de llegar a producci\u00f3n. Mejor detenerse ah\u00ed que descubrirlo despu\u00e9s, con el sitio ya online. Este control diario, repetido en cada proyecto, es el coraz\u00f3n pr\u00e1ctico de las actualizaciones de seguridad Laravel que aplico de verdad, no solo cuando me acuerdo de hacerlo a mano.<\/p>\n\n\n\n
La segunda l\u00ednea del script, composer outdated --direct<\/code>, muestra solo las dependencias declaradas a mano en el composer.json<\/code>. No muestra todo el \u00e1rbol de dependencias transitivas. Un proyecto Laravel medio arrastra centenares de paquetes indirectos. Si los listara todos, la salida ser\u00eda ilegible. Terminar\u00eda ignor\u00e1ndola, como pasa con demasiados avisos autom\u00e1ticos. Mirando solo las dependencias directas, veo de un vistazo lo que he elegido yo. Puedo decidir con calma qu\u00e9 actualizar y cu\u00e1ndo hacerlo.<\/p>\n\n\n\n
La \u00faltima parte del script imprime la versi\u00f3n de laravel\/framework<\/code> 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\u00fan la tabla oficial de soporte publicada por Laravel, los parches de seguridad para la versi\u00f3n 11 terminaron el 12 de marzo de 2026. La versi\u00f3n 12 los recibe hasta el 24 de febrero de 2027. Desde el primer trimestre de 2026 la versi\u00f3n actual es Laravel 13. Planificar las actualizaciones de seguridad Laravel con tiempo tambi\u00e9n significa esto: saber en qu\u00e9 versi\u00f3n est\u00e1 parado cada proyecto, antes de que venza el soporte.<\/p>\n\n\n\n
Los l\u00edmites honestos de este control<\/h2>\n\n\n\n
composer audit<\/code> no es un antivirus. No lee el c\u00f3digo de la aplicaci\u00f3n. Se\u00f1ala solo vulnerabilidades conocidas y ya publicadas en un advisory. Contra un fallo zero-day, descubierto pero a\u00fan no divulgado, no sirve de nada. Por eso lo considero un control de higiene b\u00e1sica, no una garant\u00eda absoluta. Las actualizaciones regulares de los paquetes<\/a> siguen siendo la pr\u00e1ctica m\u00e1s eficaz, incluso sin un advisory en curso. La documentaci\u00f3n oficial de Laravel recomienda mantenerse en la versi\u00f3n actual del framework. Tambi\u00e9n recomienda automatizar las pruebas antes de cada actualizaci\u00f3n de major. Sirve para convertir la actualizaci\u00f3n en una costumbre, no en una emergencia de \u00faltimo minuto.<\/p>\n\n\n\n
Queda el hecho de que un script de pocas l\u00edneas, lanzado cada d\u00eda, me habr\u00eda ahorrado m\u00e1s de un email inc\u00f3modo a los clientes, en los a\u00f1os en que todav\u00eda no lo usaba. Hoy forma parte de la rutina de mantenimiento de cada proyecto Laravel que sigo. Lo combino con la monitorizaci\u00f3n 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.<\/p>\n\n","protected":false},"excerpt":{"rendered":"
C\u00f3mo monitorizo las actualizaciones de seguridad Laravel en mis servidores de producci\u00f3n: composer audit, composer outdated y el seguimiento del ciclo de vida del framework.<\/p>\n","protected":false},"author":1,"featured_media":1388,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"wpai_generated_summary":"","footnotes":""},"categories":[364],"tags":[335,521,374,522,379,343],"class_list":["post-1393","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-servidores-bases-de-datos","tag-actualizacion","tag-composer","tag-gestion-de-servidores","tag-laravel","tag-php-es","tag-script-de-bash"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t