Composer, the widely used dependency manager for PHP projects, has released version 2.10 with new security protections designed to reduce the risk of malicious software reaching live websites and development environments.
The release follows a recent supply chain attack involving Laravel-Lang packages, where attackers were reported to have used rewritten version tags to point installations towards malicious code. The incident highlighted a difficult problem for modern web development: trusted open-source packages can become a route into websites, applications, hosting environments and developer systems if their release process is compromised.
What has changed in Composer 2.10?
The headline change is native malware filtering. Composer can now block package versions that have been flagged as malware before they are installed. Importantly, this protection also applies when a project is installing from an existing lockfile, which helps reduce the risk of compromised versions continuing to move through deployment pipelines after they have been identified.
Composer audit has also been expanded so malware warnings sit alongside more traditional vulnerability checks. For development teams, this makes dependency checks more useful as part of regular build and deployment processes, rather than something that only happens after a known vulnerability has been published.
Packagist is also introducing stronger protections around package versions, including stable version immutability. In practical terms, this means published stable versions should no longer be silently changed by rewriting underlying version tags, closing one of the routes used in the Laravel-Lang incident.
Why this matters for businesses
Most business websites and digital platforms rely on open-source software. That is not a weakness in itself. Open-source tools are a normal and valuable part of modern web development. The risk comes when organisations treat those dependencies as invisible, unmanaged, or automatically trusted.
A website may have strong hosting, careful development practices and regular updates, yet still depend on dozens of third-party packages. If one of those packages is compromised, the impact can reach far beyond the website’s visible functionality. In some cases, malicious packages may target credentials, deployment systems, cloud services, or developer machines.
For website owners, the lesson is not to avoid open source. The lesson is to make sure open-source dependencies are managed with the same seriousness as other parts of the security process.
What digital teams should review
- Whether their PHP projects are using a current Composer version.
- Whether dependency audits are part of routine development and deployment checks.
- Whether build pipelines fail clearly when security issues are detected.
- Whether package maintainer accounts use multi-factor authentication where relevant.
- Whether any affected Laravel-Lang packages were used during the reported attack window.
- Whether secrets, API keys and deployment credentials are rotated promptly after any suspected exposure.
A wider shift in website security
This update is part of a broader shift in how website security is being understood. Security is no longer only about the finished website, the server, or the CMS. It also includes the tools, packages and release processes that sit behind the scenes.
For agencies and in-house digital teams, Composer 2.10 is a useful step forward because it adds protection at the point where dependencies enter a project. That is where many supply chain risks need to be caught: early, visibly and before they reach production.
For businesses, the practical takeaway is simple. Ask how your website dependencies are monitored, how updates are reviewed, and what checks are in place before code is deployed. A modern website security process should include the supply chain, not treat it as someone else’s problem.
