# Roave/SecurityAdvisories: a Composer exclusion list that blocks vulnerable PHP packages > Roave/SecurityAdvisories is a dev-only Composer package that turns known vulnerable dependency versions into unsatisfiable constraints. It is a guard rail for the root project, not a scanner, and it only fires at require and update time. **Roave/SecurityAdvisories** — :closed_lock_with_key: Security advisories as a simple composer exclusion list, updated daily - Repository: https://github.com/Roave/SecurityAdvisories - Stars: 2,918 · Forks: 111 - Language: Unknown - License: MIT - Published: 2026-09-24 · Updated: 2026-09-24 · Language: en - Canonical page: https://hysenlabs.com/projects/roave-securityadvisories ## The problem Roave/SecurityAdvisories solves, and the projects it fits Composer resolves version constraints, and it does not know that a given release of a package has a published advisory against it. If your composer.json says symfony/symfony:2.5.2, Composer will happily install it as long as the constraint is satisfiable and the package is reachable. Roave/SecurityAdvisories changes that by existing as a package whose own version constraints exclude the vulnerable releases. When Composer resolves your dependency graph, it has to satisfy this package too, and the excluded versions become unsatisfiable. The README is explicit about the scope: the package "does not provide any API or usable classes: its only purpose is to prevent installation of software with known and documented security issues." That is the whole design. It is for teams that own the root composer.json of a deployable PHP project and want a resolution-time gate rather than a report generated after the fact. It is not a runtime protection layer, and it does not patch anything. ## How the exclusion list works: constraints, not code The mechanism is dependency resolution rather than scanning. Roave/SecurityAdvisories is published only as dev-latest, and its composer.json carries conflict or require constraints that make known-vulnerable versions of other packages unresolvable. The README frames this as a deliberate choice: "there will never be stable/tagged versions because of the nature of the problem being targeted." Security issues are a moving target, so pinning to a tag would freeze the list at the moment of tagging. The advisory data itself is not authored in this repository. According to the README, the package "extracts information about existing security issues in various composer projects from the FriendsOfPHP/security-advisories repository and the GitHub Advisory Database." A separate builder repository, Roave/SecurityAdvisoriesBuilder, runs an hourly build workflow, which is how the latest branch stays current. That split matters when you evaluate the project: the accuracy of what gets blocked depends on upstream advisory sources, and the freshness depends on the builder job running. One structural consequence follows from the dev-latest rule. The README states the package "is therefore only suited for installation in the root of your deployable project." A library that other people install cannot require an untagged dev branch of a security list without forcing that decision on every consumer. ## Installing it and making a first failing require Installation is a single Composer command run at the root of your project. The README gives it exactly as follows. ```bash composer require --dev roave/security-advisories:dev-latest ``` After this, the package sits in the require-dev section of your composer.json. The README also shows the equivalent manual entry as "roave/security-advisories": "dev-latest" in that section. There is nothing to configure, no service to start, and no config file to write, because the package ships no classes. The way to see it working is to ask for a version the list already excludes. The README uses these two examples and notes that the commands will fail. ```bash composer require symfony/symfony:2.5.2 composer require zendframework/zendframework:2.3.1 ``` What you should see is a dependency resolution failure naming the conflicting package, not a successful install followed by a warning. That distinction is the point of the tool: the install never completes. If you want to check an existing project without changing anything, the README documents a manual trigger: "Running composer update --dry-run roave/security-advisories is an effective way to manually trigger a security version check." The dry run reports the conflict without writing a new lock file. ## Where the guard rail does not reach The most important limitation is stated plainly in the README. The checks "are only executed when adding a new dependency via composer require or when running composer update: deploying an application with a valid composer.lock and via composer install won't trigger any security versions checking." That is a large gap in practice. Continuous integration pipelines and container builds typically run composer install from a committed lock file. Those runs will not evaluate the advisory list at all. If a vulnerable version was locked in months ago, adding this package does not retroactively fail the build. You have to run an update, or the documented dry-run command, to get a verdict. Two more boundaries follow from the design. First, this only covers Composer packages that appear in the upstream advisory sources. A vulnerable dependency that no advisory has been filed against will resolve normally. Second, because the package must be installed in the root, it does nothing for a library author who wants consumers protected; the README's own wording limits it to the deployable project. Treat it as a constraint on your own resolution, not as a supply chain control for everything downstream. ## Roave/SecurityAdvisories compared with an audit command The natural alternative in the Composer ecosystem is composer audit, which inspects the installed or locked dependency set and reports advisories against it. The difference is timing and mechanism. An audit command is retrospective: it reads what is already resolved, including a committed lock file, and tells you which entries have advisories. Roave/SecurityAdvisories is prospective: it participates in resolution and makes a vulnerable version impossible to select in the first place. That makes them complementary rather than interchangeable. An audit run in CI catches the lock file that was committed before anyone added the guard rail, which is exactly the case this package cannot cover. Conversely, an audit reports a problem that a developer then has to act on, while the exclusion list refuses to produce the resolution at all. If your pipeline only runs composer install, an audit step is the one that will actually fire. The other comparison worth naming is the upstream data source. FriendsOfPHP/security-advisories and the GitHub Advisory Database are the repositories this package extracts from. Querying those sources directly, through an audit tool or your own script, gives you the advisory text and identifiers. This package deliberately does not surface that: it converts advisories into version constraints and nothing else, so you lose the explanation of why a version is blocked. ## Maintenance, versioning and the MIT licence There are no tagged releases to upgrade to. The README states the package "can only be required in its dev-latest version" and that stable or tagged versions will never exist. Upgrading therefore means re-resolving the dev-latest branch, which is what a composer update does anyway. There is no changelog to read between versions because there are no versions. Freshness depends on the builder, not on this repository. The README links Roave/SecurityAdvisoriesBuilder and its hourly build workflow on the latest branch. The last push to this repository was on 2026-09-23. If the builder job stops, the exclusion list stops changing, and the package will keep resolving against a stale set of advisories without any error to tell you so. That is a silent failure mode worth knowing about before you rely on it as your only gate. The repository is licensed MIT, with a LICENSE file at the top level. The README also notes that the package is available as part of the Tidelift Subscription for enterprise support, and that the maintainers can be contacted at team@roave.com about security issues in your own project. Those are commercial arrangements around the same MIT-licensed code; whether your organisation needs them is a procurement question, not a licensing one. Nothing here changes what the MIT terms permit. ## Conclusion Adopt it if you maintain the root composer.json of a PHP application and you want known-vulnerable versions to fail resolution before they reach composer.lock. Skip it if you only run composer install from a lock file, or if you need transitive dependency scanning, because the README states the checks do not run on install. Before rolling it out, confirm the package resolves as dev-latest in your project and run composer update --dry-run roave/security-advisories to see whether your current constraint set already conflicts. ## FAQ ### What is Roave/SecurityAdvisories? It is a Composer package that ensures your application does not have installed dependencies with known security vulnerabilities, by making vulnerable versions unresolvable. It provides no API or usable classes and exists only to block those versions. ### How do I install Roave/SecurityAdvisories in a Composer project? Run composer require --dev roave/security-advisories:dev-latest at the root of your deployable project, or add "roave/security-advisories": "dev-latest" to the require-dev section of composer.json. The package is only suited for installation in the root project. ### Does Roave/SecurityAdvisories block vulnerable packages during composer install? No. The README states the checks only run when adding a dependency with composer require or when running composer update, so deploying with a valid composer.lock via composer install does not trigger any security version checking. ### Why does Roave/SecurityAdvisories have no stable or tagged versions? The README explains that security issues are a moving target, so locking the project to a specific tagged version would not make sense. The package can only be required in its dev-latest version. ## Sources - [Issues](https://github.com/Roave/SecurityAdvisories/issues) - [License: MIT](https://github.com/Roave/SecurityAdvisories/blob/latest/LICENSE) - [README](https://github.com/Roave/SecurityAdvisories/blob/latest/README.md) - [Roave/SecurityAdvisories on GitHub](https://github.com/Roave/SecurityAdvisories) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/roave-securityadvisories