Bloquear dependencias vulnerables con la política de Composer y actualizar sin romper nada

Hola, bienvenido. En esta lección vamos a escribir en composer.json la política de seguridad de Composer, la sección config.policy. Vamos a ver qué hace cada parte, qué pasa cuando bloquea una versión y qué hacer cuando composer audit encuentra un aviso en un paquete que ya tienes instalado, incluido el caso en que la versión corregida rompe algo.

Desde la 2.10, Composer decide con la sección policy qué hace con 3 tipos de versiones: las que tienen avisos de seguridad, las que están marcadas como malware y las de paquetes abandonados. Con los valores por defecto ya bloquea las 2 primeras. Lo que vamos a hacer es dejarlo escrito, para que se vea qué política sigue el proyecto.

La sección policy tiene una parte por cada tipo de versión, y en cada una se decide lo mismo: si Composer se niega a instalarla, con block, y qué hace composer audit cuando la encuentra, con audit. Estos son sus valores por defecto según la documentación de Composer:

advisories es la que más vas a ver. Con block a true, cuando Composer resuelve dependencias, descarta las versiones que tienen un aviso activo, así que no te puede instalar una versión vulnerable al hacer composer require o composer update. Ojo con un detalle: no actúa en composer install. Si el aviso sale después de que la versión haya entrado en tu composer.lock, install la sigue instalando, y quien te avisa es composer audit. Con audit a fail, composer audit termina con error cuando encuentra un aviso, que es lo que para composer qa.

malware la vimos en la lección 5. Bloquea las versiones que Packagist marca como malware, y con block-scope a all lo hace también en composer install, que es lo que se ejecuta en integración continua y en producción. Recuerda su límite: solo bloquea lo que ya está marcado.

abandoned trata los paquetes que su autor ha dejado de mantener. Por defecto no los bloquea, porque un paquete abandonado sigue funcionando y sustituirlo es una tarea que se planifica, pero composer audit los trata como un fallo.

Antes de la 2.10, parte de esto ya existía en otra sección, audit: desde la 2.9, Composer bloqueaba por defecto las versiones con avisos con la opción audit.block-insecure. La documentación, en septiembre de 2026, da la sección audit por obsoleta y explica cómo conviven las 2: Composer solo lee las opciones antiguas de audit cuando falta la parte equivalente de policy, y lo hace por bloques enteros. Es decir, si tu proyecto tenía avisos ignorados en audit.ignore y añades policy.advisories, esos avisos dejan de estar ignorados, porque Composer ya no lee nada de audit sobre avisos. El esqueleto de Laravel no trae la sección audit, así que en invoices no hay nada que migrar. En un proyecto más antiguo, revísala antes y pasa todas sus opciones a la vez.