Composer supply chain in 2026 — the audits, locks, and signing controls we ship by default

Packagist + Composer is the dependency surface every modern PHP app pulls from. Three years of supply-chain attacks have made the threat model real: a maintainer account gets compromised, a malicious version is published, every CI pipeline pulling that package on composer update ships it to production.

The controls that materially change attacker economics here are well-established. They are mostly not turned on by default.

The CI gate for Composer

# Refuse to deviate from composer.lock
composer install --no-dev --prefer-dist --no-interaction --no-progress
 
# Vulnerability audit against the lockfile
composer audit --locked --format=json
 
# Belt-and-braces — sigstore-backed provenance (Packagist 2024+)
composer verify --strict

composer install (not composer update) is the entry point in CI. It refuses to deviate from composer.lock and fails fast if the lock has been tampered with.

The full write-up covers:

• Why composer update belongs in development, never in CI / deploy
• The Packagist signature/provenance rollout from 2024 onward
• Locking minimum-stability + restricting repositories to your private mirror
• Renovate config for Composer — sensible groupings and update cadence
• Auditing transitive dependencies (most attacks come through deep transitives)
• The internal Satis / private Packagist mirror pattern for air-gapped builds
• Incident response when a popular package is announced compromised at 09:00

We ship these controls on every managed PHP / Laravel / WordPress install.