Dependency security for Composer projects
Most of the code in a Laravel application is code you did not write. This is a practical overview of how that code reaches production, what can go wrong with it, and how to keep an eye on it.
What a lockfile is
composer.json says which packages you want and which versions are acceptable, for example ^11.0. composer.lock records the exact version of every package that was actually installed, including the dependencies of your dependencies.
The lockfile is what makes composer install reproducible: your laptop, CI and production all get the same code. It is also the only accurate answer to the question “which versions am I running?” A version range in composer.json cannot tell you whether you are inside an advisory’s affected range; the lockfile can.
# Exact installed versions, straight from composer.lock
composer show --locked
# Known advisories that match your installed versions
composer auditWhy dependency monitoring matters
A typical Laravel application installs well over a hundred packages once transitive dependencies are counted. Advisories are published against those packages continuously, and an application that was clean on the day it shipped can be affected weeks later without a single line of its code changing.
That is why a one-off check is not enough. The useful question is not “was this safe when we deployed?” but “is anything we run today affected by something published since?”
Common dependency threats
Vulnerable versions
A dependency has a published advisory and the version in your lockfile is inside the affected range. Most fixes are an upgrade to the patched release, but you first have to know the affected version is installed.
Malicious packages
A package is published, or an existing one is taken over, with code meant to steal secrets or run commands, at runtime or through a Composer plugin during install. Here the package itself is the attack, so the remedy is removing it, not upgrading.
Typosquatting
An attacker registers a name one keystroke away from a popular package and waits for someone to mistype a composer require. The fake often works like the original, so nothing looks wrong.
Dependency confusion
A private package name also exists on a public registry, published by an attacker. Composer treats repositories you add as canonical by default, which blocks this for the packages they serve; the risk returns when that is switched off or a private name is missing from your private repository.
Abandoned packages
A dependency stops receiving releases. Nothing changes overnight, but future vulnerabilities will not be fixed upstream and compatibility with new PHP and Laravel versions drifts.
Why automated monitoring helps
It checks exact versions
Matching the lockfile against advisory databases removes the guesswork of comparing version ranges by hand.
It keeps checking
New advisories are compared against what you already run, not only against what you change.
It catches problems before merge
Checking dependency changes in pull requests stops a vulnerable or malicious version before it reaches the main branch.
It helps you prioritise
Not every finding is equally urgent. Ordering them, for example production code before development tooling, turns a long list into a short one.
Promotion
What Lockhound can do
Which vulnerable dependencies to fix first, across every GitHub repository.
Fix-first prioritisation
Ranks vulnerable dependencies across your repositories so malicious packages, vulnerabilities exploited in the wild, and critical or high findings in code you ship come first.
Lockfile-accurate inventory
Reads exact package versions from lockfiles such as composer.lock, including direct, transitive and dev dependencies, across monorepos.
Pull request checks
Pull requests that touch a lockfile get a GitHub check listing what they add and the version that fixes it.
Continuous re-evaluation
Scans on push, on schedule and daily against new advisories, even when your code has not changed.
Malicious package detection
Flags known-malicious packages and shows the command to remove them.
Slack and email alerts
Alerts with severity thresholds, digests and deduplication.
Read-only GitHub App
Installs as a GitHub App whose scans read code but never change it.
EcosystemsJavaScript (npm, Yarn, pnpm) · PHP (Composer) · Python · Go · Rust · Ruby · Java and Kotlin (Gradle)
This site is operated by the makers of Lockhound. Links to Lockhound are promotional.