Supply chain do Composer em 2026 — as auditorias, locks e controles de assinatura que entregamos por padrão

Packagist + Composer é a superfície de dependências de onde toda app PHP moderna puxa. Três anos de ataques à supply-chain tornaram o modelo de ameaça real: uma conta de maintainer é comprometida, uma versão maliciosa é publicada, todo pipeline de CI que puxa esse pacote em composer update o envia para produção.

Os controles que mudam materialmente a economia do atacante aqui são bem estabelecidos. A maioria não está ligada por padrão.

O gate de CI para o Composer

# Recusa desviar do composer.lock
composer install --no-dev --prefer-dist --no-interaction --no-progress
 
# Auditoria de vulnerabilidades contra o lockfile
composer audit --locked --format=json
 
# Cinto e suspensório — provenance respaldada por sigstore (Packagist 2024+)
composer verify --strict

composer install (não composer update) é o ponto de entrada no CI. Recusa desviar do composer.lock e falha rápido se o lock foi adulterado.

O artigo completo cobre:

• Por que composer update pertence ao desenvolvimento, nunca ao CI / deploy
• O rollout de assinatura/provenance do Packagist de 2024 em diante
• Travar minimum-stability + restringir os repositories ao seu mirror privado
• Config do Renovate para Composer — agrupamentos sensatos e cadência de update
• Auditar dependências transitivas (a maioria dos ataques vem por transitivas profundas)
• O padrão de Satis interno / mirror Packagist privado para builds air-gapped
• Resposta a incidentes quando um pacote popular é anunciado comprometido às 09:00

Entregamos esses controles em cada instalação PHP / Laravel / WordPress gerenciada.