Composer 2.9 introduced Automatic Security Blocking, moving advisory enforcement from the opt-in roave/security-advisories package into the dependency resolver itself. The new SecurityAdvisoryPoolFilter stage removes vulnerable package versions from the candidate pool before the SAT solver runs, so known-bad versions simply never appear as installable options. Blocking is on by default and applies to composer update, require, and remove — but intentionally not to composer install from a lock file, preserving reproducibility. Configuration options include block-insecure, block-abandoned, and a per-advisory ignore map with reason fields. Composer 2.10 will extend the same pipeline with 'filter lists' to handle malware-flagged packages via feeds like Aikido, using a sources/lists/entries abstraction. The article also documents a real incident where GitHub broadened the affected-version range for a PHPUnit advisory beyond what the maintainer specified, causing PHPUnit 11 to be incorrectly blocked, and explains how FriendsOfPHP data takes precedence over GitHub Advisory Database data to resolve such conflicts. Practical guidance covers migrating away from roave/security-advisories, using the ignore config for inapplicable advisories, and using COMPOSER_NO_SECURITY_BLOCKING for CI bypass.

13m read timeFrom phpunit.expert
Post cover image
Table of contents
Conflict rules as a security toolReporting without enforcementAutomatic Security BlockingFilter listsWhere does the older stack fit?A real world examplePractical guidanceConclusion

Sort: