Supply-chain attacks on PHP packages have been a slow-burn concern for years, but Composer 2.10 is the first time the toolchain itself has done something concrete about it. Released this week, the update adds malware blocking for Packagist.org packages and a new dependency policy configuration system — two features that change how we think about package governance on client projects. Here's what actually shipped and what it means for agencies running Laravel in production.
What's new in Composer 2.10
The headline changes break into two distinct areas:
Malware blocking via Packagist.org integration. Composer now queries a blocklist maintained by the Packagist.org security team when resolving dependencies. If a package or a specific version has been flagged as malicious, Composer refuses to install it and surfaces a clear error. This happens automatically — no configuration required. The blocklist covers packages that have been identified as containing malicious code, typosquatted names designed to impersonate popular libraries, and packages with known backdoors. Critically, this check runs at install and update time, not just during an audit pass, so it's a first-class gate rather than an afterthought.
Dependency policy configuration. A new policies key in composer.json lets teams define rules that govern what packages are allowed in a project. The initial feature set includes the ability to restrict allowed licenses, block specific packages or version ranges by name, and flag packages that haven't received a release within a defined time window. Policies can be applied per-project or pushed down from a root composer.json in a monorepo setup. Violations fail the install with a descriptive message, making them CI-friendly — you can enforce policies in a pipeline and get a meaningful exit code.
Other security-focused changes in the release include stricter validation of package metadata signatures and improvements to how Composer handles packages that reference non-Packagist VCS sources, which have historically been a vector for dependency confusion attacks.
The upgrade path is straightforward: composer self-update on any system running Composer 2.x. PHP 7.2.5+ is still supported, so nothing about the runtime requirement changes.
Our take
This release matters more than its version number suggests, and we want to be direct about why.
The malware blocking is genuinely useful — but it's not a silver bullet. The blocklist only covers packages that Packagist.org has already identified and flagged. It won't catch a brand-new malicious package in its first 48 hours, and it won't catch a compromised package whose maintainer account was silently hijacked without the Packagist team noticing yet. What it does do is raise the floor: opportunistic attacks using known-bad packages no longer work automatically. For agencies managing dozens of client codebases with composer update running in CI, this is a meaningful reduction in passive risk without any operational overhead.
The dependency policy system is where we're more excited. License compliance is a real problem on client work that most agencies handle inconsistently — someone drops in a GPL-licensed package on a project that's being distributed commercially, and nobody catches it until legal asks a question three years later. Being able to encode "allow only MIT, Apache-2.0, BSD-3-Clause" as a machine-checkable rule in version control is a genuine quality-of-life improvement. We're planning to add a baseline policy block to our Laravel project template this week.
The "flag stale packages" feature is one we'd approach carefully. A package with no releases for two years isn't necessarily abandoned — some libraries are simply done. We'd recommend using the staleness check as a warning rather than a hard failure in CI, at least until you've profiled your dependency tree and understand which packages are stable-and-finished versus genuinely unmaintained. Treating every quiet package as a red flag will generate noise that trains your team to ignore the policy output entirely.
Dependency confusion attacks are the gap this release doesn't fully close. If an attacker registers a public Packagist package with the same name as an internal private package, Composer can still resolve the wrong one depending on repository priority. The 2.10 metadata signature improvements help at the margins, but the real fix is explicit repository configuration — locking private packages to their internal source in composer.json rather than relying on resolution order. If you're running any private packages in Satis or a private registry and you haven't audited your repository configuration recently, that's the higher-priority action item regardless of Composer version.
Practical recommendations
Upgrade to Composer 2.10 now. There's no meaningful compatibility risk for standard Laravel applications, and the malware blocking activates automatically. Run composer self-update in your local environment and update your CI pipeline base image or runner step.
Add a baseline license policy to new projects. A three-line policies block in composer.json covering your standard allowed licenses costs almost nothing and prevents the kind of license drift that's genuinely painful to clean up later. We'll be publishing our baseline template config in a follow-up post.
Audit your private package repository configuration. If you're using Satis, Packagist Private, or any private registry, verify that private package names are explicitly locked to their internal source. This takes 20 minutes and closes the dependency confusion vector that 2.10 doesn't fully address.
Use the staleness policy as a warning first. Enable it in your CI pipeline with a non-zero exit behavior only after you've reviewed which packages it flags. Give yourself one sprint to triage before treating it as a hard gate.
Originally referenced: Malware Blocking and Dependency Policies in Composer 2.10 on Laravel News.
Supply-chain security has been the category of risk that PHP teams consistently under-index on compared to application-layer vulnerabilities. Composer 2.10 makes the baseline better, but it also surfaces how much policy governance most projects are missing entirely. If you're running Laravel in production and want help auditing your dependency configuration or formalizing your package policies, get in touch.
Originally published by Laravel News. Read the full announcement here.
