For PHP and Laravel teams
Composer and PHP dependency security, across every repository
Lockhound reads composer.lock in every GitHub repository, finds vulnerable, exploited and malicious packages, separates production from require-dev, and checks every pull request.
composer audit is a great command, and you should run it. It answers "is anything in this project vulnerable right now?" for one project, on one machine. Lockhound answers it for every PHP repository you have, keeps answering it as new advisories appear, and tells you which findings to fix first.
What Lockhound reads
composer.lock: every installed package at its exact version, including transitive ones. Packages inpackagesare marked as production and packages inpackages-devas development, so a vulnerable PHPUnit plugin doesn't outrank a vulnerable HTTP client. Package aliases resolve to the real installed version.composer.json: tells direct dependencies apart from transitive ones. If a project has no lockfile, Lockhound checks the lowest version each constraint allows and marks those findings unverified, rather than guessing.- Monorepos: every
composer.lockin the repository is a separate project, wherever it lives.
It never runs composer install, never executes repository code, and needs only read access to the repository.
What you see for each finding
Take a Laravel app pinned to guzzlehttp/psr7 2.1.0:
- Priority: Fix soon. It is high severity and ships to production. It would be Fix now if CISA listed it as exploited in the wild.
- Why: each reason with its source: the advisory (via OSV, which includes the GitHub Advisory Database), the dependency scope, and whether it is direct or transitive.
- What to do:
composer update guzzlehttp/psr7 --with-all-dependenciesfor a transitive package, orcomposer require "guzzlehttp/psr7:^2.1.1" --with-all-dependenciesfor a direct one. - Whether the upgrade is safe: the suggested version is itself checked against every known advisory, so you're told if 2.1.1 still has open issues and you need a later release.
Pull requests
Every pull request that changes composer.json or composer.lock gets a Lockhound check on GitHub. It fails only on what the pull request adds: a new critical or high vulnerability, a known-exploited one, or a malicious package. It ignores the backlog already on your main branch. Make the check required, and a risky composer update can't be merged by accident. Each workspace chooses its own threshold.
Across many projects
Agencies and teams with dozens of Laravel apps get one queue across every repository and GitHub organization. For example: "symfony/http-kernel 5.4.0 is in 14 repositories, upgrade to this version". Alerts go to Slack or email when something new and urgent appears, including when an advisory you already have is added to CISA's exploited list.
What it doesn't do
Lockhound doesn't open upgrade pull requests, and it doesn't analyse your PHP code for reachability. It gives you the exact command and an issue or prompt your AI coding agent can work from. Upgrades stay in your hands.
Try it on a composer.lock now, without an account, or connect GitHub to watch every repository.
Read next
- How to find vulnerable packages in composer.lock, and which to fix firstUse composer audit to list known vulnerabilities in a PHP project, read what it tells you, trace transitive packages, and decide what to upgrade first.
- Which vulnerable dependencies to fix first, using CISA KEV and EPSSCVSS tells you how bad a vulnerability could be, not whether anyone is exploiting it. Here is how to add CISA's Known Exploited Vulnerabilities catalog and FIRST's EPSS scores to your triage, with commands you can run today.