Composer-Supply-Chain 2026 — die Audits, Locks und Signaturkontrollen, die wir standardmäßig ausliefern

Packagist + Composer ist die Abhängigkeits-Oberfläche, aus der jede moderne PHP-App zieht. Drei Jahre Supply-Chain-Angriffe haben das Threat Model real gemacht: Ein Maintainer-Account wird kompromittiert, eine bösartige Version wird veröffentlicht, jede CI-Pipeline, die das Paket auf composer update zieht, liefert es in Produktion aus.

Die Kontrollen, die hier die Ökonomie des Angreifers materiell verändern, sind gut etabliert. Die meisten sind standardmäßig nicht eingeschaltet.

Das CI-Gate für Composer

# Weigert sich, von composer.lock abzuweichen
composer install --no-dev --prefer-dist --no-interaction --no-progress
 
# Vulnerability-Audit gegen das Lockfile
composer audit --locked --format=json
 
# Hosenträger und Gürtel — sigstore-gestützte Provenance (Packagist 2024+)
composer verify --strict

composer install (nicht composer update) ist der Einstiegspunkt in CI. Es weigert sich, vom composer.lock abzuweichen, und schlägt schnell fehl, wenn der Lock manipuliert wurde.

Der vollständige Beitrag behandelt:

• Warum composer update ins Development gehört, niemals in CI / Deploy
• Das Packagist-Signatur-/Provenance-Rollout ab 2024
• minimum-stability sperren + Repositories auf Ihren privaten Mirror beschränken
• Renovate-Konfig für Composer — sinnvolle Gruppierungen und Update-Kadenz
• Transitive Abhängigkeiten auditieren (die meisten Angriffe kommen durch tiefe Transitiven)
• Das interne Satis- / privater-Packagist-Mirror-Pattern für Air-gapped Builds
• Incident Response, wenn um 09:00 ein populäres Paket als kompromittiert gemeldet wird

Wir liefern diese Kontrollen auf jeder gemanagten PHP- / Laravel- / WordPress-Installation aus.