Supply chain Composer en 2026 — les audits, locks et contrôles de signature que nous livrons par défaut

Packagist + Composer est la surface de dépendances dont chaque app PHP moderne tire. Trois ans d'attaques supply-chain ont rendu le threat model réel : un compte mainteneur est compromis, une version malveillante est publiée, chaque pipeline CI qui pull ce package sur composer update l'expédie en prod.

Les contrôles qui changent matériellement l'économie de l'attaquant ici sont bien établis. La plupart ne sont pas activés par défaut.

La porte CI pour Composer

# Refuse de dévier de composer.lock
composer install --no-dev --prefer-dist --no-interaction --no-progress
 
# Audit de vulnérabilités contre le lockfile
composer audit --locked --format=json
 
# Ceinture et bretelles — provenance soutenue par sigstore (Packagist 2024+)
composer verify --strict

composer install (pas composer update) est le point d'entrée en CI. Il refuse de dévier de composer.lock et échoue rapidement si le lock a été altéré.

L'article complet couvre :

• Pourquoi composer update appartient au développement, jamais en CI / déploiement
• Le rollout de signature/provenance Packagist à partir de 2024
• Verrouiller minimum-stability + restreindre les repositories à votre mirror privé
• Config Renovate pour Composer — groupements sensés et cadence d'update
• Auditer les dépendances transitives (la plupart des attaques passent par les transitives profondes)
• Le pattern Satis interne / mirror Packagist privé pour builds air-gapped
• Réponse à incident quand un package populaire est annoncé compromis à 09h00

Nous livrons ces contrôles sur chaque install PHP / Laravel / WordPress managée.