Supply chain de Composer en 2026 — las auditorías, locks y controles de firma que entregamos por defecto

Packagist + Composer es la superficie de dependencias de la que tira cada app PHP moderna. Tres años de ataques a la supply-chain han hecho el modelo de amenazas real: la cuenta de un mantenedor se compromete, se publica una versión maliciosa, cada pipeline de CI que tira de ese paquete con composer update lo envía a producción.

Los controles que cambian materialmente la economía del atacante aquí están bien establecidos. La mayoría no están activados por defecto.

El gate de CI para Composer

# Rechaza desviarse de composer.lock
composer install --no-dev --prefer-dist --no-interaction --no-progress
 
# Auditoría de vulnerabilidades contra el lockfile
composer audit --locked --format=json
 
# Cinturón y tirantes — provenance respaldada por sigstore (Packagist 2024+)
composer verify --strict

composer install (no composer update) es el punto de entrada en CI. Rechaza desviarse de composer.lock y falla rápido si el lock ha sido manipulado.

El artículo completo cubre:

• Por qué composer update pertenece al desarrollo, nunca a CI / deploy
• El rollout de firma/provenance de Packagist desde 2024 en adelante
• Bloquear minimum-stability + restringir los repositories a tu mirror privado
• Config de Renovate para Composer — agrupaciones sensatas y cadencia de update
• Auditar dependencias transitivas (la mayoría de ataques entran por las transitivas profundas)
• El patrón de Satis interno / mirror Packagist privado para builds air-gapped
• Respuesta a incidentes cuando un paquete popular se anuncia comprometido a las 09:00

Entregamos estos controles en cada instalación PHP / Laravel / WordPress gestionada.