Dependencias de PHP seguras con Composer: archivos lock, auditorías y actualizaciones

La mayoría de las aplicaciones PHP modernas, desde las hechas con Laravel y Symfony hasta muchos plugins de WordPress, se construyen sobre decenas de paquetes de código abierto instalados con Composer. Mantenerlos seguros requiere cuatro hábitos: subir composer.lock al repositorio e instalar a partir de él, ejecutar composer audit con regularidad y en cada despliegue, reemplazar los paquetes abandonados y actualizar con un calendario constante en lugar de una vez cada varios años. Si su empresa depende de una aplicación PHP a medida, estas son las preguntas que debe hacerle a su desarrollador, y las comprobaciones que verá a continuación toman minutos una vez que forman parte de la rutina.

Por qué las dependencias merecen atención

Cuando contrata a alguien para crear un portal, un sistema de reservas o una herramienta interna en PHP, una gran parte del código que funciona en producción fue escrito por otras personas: frameworks, SDK de pagos, generadores de PDF, librerías de correo. Eso es normal y saludable. También significa que una vulnerabilidad en cualquiera de esos paquetes es una vulnerabilidad en su aplicación, y las correcciones solo le llegan cuando alguien los actualiza.

La buena noticia: Composer incluye herramientas que hacen esto manejable, y son gratuitas.

1. Suba composer.lock al repositorio e instale a partir de él

Composer usa dos archivos:

• composer.json enumera los paquetes que necesita su aplicación y qué rangos de versiones son aceptables (por ejemplo ^3.2, es decir, cualquier versión 3.x desde la 3.2, pero no la 4.0).
• composer.lock registra las versiones exactas que se instalaron y probaron.

La documentación de Composer indica que subir el archivo lock al control de versiones es importante porque hace que cualquiera que configure el proyecto use las mismas versiones, incluidos los servidores de producción y los sistemas de CI. En la práctica:

• Los despliegues a producción deben ejecutar composer install, que instala exactamente lo que indica el archivo lock. Un comando típico de producción es composer install --no-dev --optimize-autoloader, que omite las herramientas solo de desarrollo.
• Ejecute composer update solo de forma deliberada, en el equipo de un desarrollador o en staging; luego pruebe y suba el nuevo archivo lock. Ejecutar update directamente en un servidor en producción puede instalar versiones sin probar.
• Mantenga vendor/ fuera del alcance público. Debe estar fuera de la raíz web o bloqueado por el servidor web.

2. Use composer audit

composer audit compara los paquetes instalados con los avisos de seguridad publicados (por defecto, desde la API de Packagist.org) y enumera los que están afectados. Se añadió en Composer 2.4 y, por defecto, Composer también ejecuta una auditoría automáticamente después de composer update y composer require.

Formas útiles de ejecutarlo:

composer audit                 # revisa los paquetes instalados
composer audit --locked        # revisa lo que dice composer.lock, sin carpeta vendor
composer audit --no-dev        # ignora los paquetes solo de desarrollo
composer audit --format=json   # salida legible por máquina para CI

Termina con un código distinto de cero cuando encuentra problemas, así que puede añadirlo a su proceso de despliegue y detener un despliegue que incluiría un paquete con vulnerabilidades conocidas.

Las versiones recientes de Composer bloquean actualizaciones inseguras

Desde Composer 2.9, Composer bloquea por defecto, durante update y require, las versiones de paquetes con avisos de seguridad conocidos, para que usted no actualice por accidente a una versión vulnerable. La documentación reciente agrupa estas opciones en el ajuste policy (los proyectos más antiguos pueden usar los ajustes audit anteriores). Si una compilación falla de repente después de actualizar Composer, lea el mensaje: normalmente señala un paquete que usted debe actualizar, no un error. Si necesita ignorar un aviso temporalmente, ignore ese aviso concreto con un motivo por escrito y una fecha de revisión, en lugar de desactivar la protección.

Mantenga Composer actualizado con composer self-update para contar con estas protecciones.

3. Reemplace los paquetes abandonados

Los autores pueden marcar un paquete como abandonado en Packagist, a menudo indicando un reemplazo. Un paquete abandonado no recibirá correcciones de seguridad, así que se convierte en un riesgo creciente.

• Composer avisa de los paquetes abandonados durante las instalaciones y en composer audit. Desde Composer 2.7, la auditoría trata por defecto los paquetes abandonados como un fallo; el comportamiento se ajusta con la opción --abandoned (ignore, report o fail).
• Cuando aparezca uno, planifique el cambio al reemplazo sugerido (o a una alternativa con mantenimiento activo) en su próximo ciclo de actualizaciones.
• Preste atención también a los paquetes que no están formalmente abandonados pero no publican una versión desde hace años. Merecen una segunda mirada antes de construir más sobre ellos.

4. Actualice con un calendario constante

La mayoría de los problemas con dependencias surgen por esperar demasiado, cuando una pequeña actualización se ha convertido en una migración de versión mayor. Un calendario que funciona para muchos equipos pequeños:

Cuándo	Qué
En cada despliegue	composer install desde el archivo lock; composer audit en el proceso
Cada mes	composer outdated --direct para ver qué tiene versiones nuevas; aplicar actualizaciones menores y de parche en staging, probar y desplegar
Pocos días después de un aviso	Actualizar el paquete afectado, probar la función afectada y desplegar
Cada trimestre	Revisar paquetes abandonados u obsoletos; planificar actualizaciones de versión mayor
Con cada actualización de PHP	Confirmar que todos los paquetes admiten la nueva versión de PHP

Herramientas automáticas como Dependabot de GitHub son compatibles con Composer y pueden abrir solicitudes de actualización (pull requests) por usted, lo que convierte el paso mensual en una revisión en lugar de una tarea pesada.

Mantenga un número razonable de dependencias

Cada paquete es código en el que usted confía. Antes de añadir uno nuevo, el desarrollador debería preguntarse si tiene mantenimiento activo, si se usa ampliamente y si realmente hace falta. Menos paquetes, y bien mantenidos, son más fáciles de mantener seguros.

5. Proteja la cadena de suministro

• Instale paquetes solo desde repositorios de confianza (Packagist o su propio repositorio privado) y mantenga las URL de los repositorios en HTTPS.
• Revise los cambios del archivo lock en las solicitudes de cambios. Los paquetes o fuentes nuevos e inesperados merecen una pregunta.
• No ejecute Composer como root en los servidores. Ejecútelo con el usuario propio del sitio.
• Mantenga los secretos fuera de composer.json y fuera del repositorio; use variables de entorno o un archivo de autenticación que no se suba al repositorio.

Preguntas para su desarrollador o proveedor de TI

1. ¿Está composer.lock en el repositorio y producción usa composer install?
2. ¿Cada despliegue ejecuta composer audit y se detiene si encuentra problemas?
3. ¿Qué versión de Composer usamos y cuándo se actualizó por última vez?
4. ¿Tenemos paquetes abandonados y cuál es el plan para ellos?
5. ¿Cuándo se actualizaron las dependencias por última vez y quién se encarga de la actualización mensual?

Podemos ayudarle

Core Florida IT mantiene y protege aplicaciones PHP a medida y los servidores donde funcionan para empresas de Miami-Dade y el sur de Florida, con soporte remoto en todo el país. Si no está seguro de cuándo se revisaron por última vez las dependencias de su aplicación, solicite una evaluación de TI gratuita y la revisaremos con usted.

Fuentes

• Documentación de Composer: Uso básico (composer.lock)
• Documentación de Composer: Interfaz de línea de comandos (audit)
• Documentación de Composer: Configuración (ajustes policy y audit)
• Blog de Packagist: Composer 2.4
• Blog de Packagist: Composer 2.9