Composer 2.10 Release

We are excited to announce the release of Composer 2.10.0, introducing native malware filtering and consolidated future-proof customizable dependency policy configuration to control the handling of security advisories, abandoned packages, and now malware. Fast detection of malware for packages published on Packagist.org is provided by Aikido.

This release is part of our push for improved supply chain security for Composer & Packagist outlined in our blog post yesterday.<br>Software Supply Chains Under Attack<br>Open-source package ecosystems have become an increasingly attractive and common target for supply chain attacks. While typosquatting and dependency confusion attacks have been a concern for years, we are seeing a steady rise in packages that are intentionally malicious. They carry credential stealers, cryptominers, or backdoors often even targeting developer machines rather than production systems. Protection needs to happen earlier than a code review before production deployment, right when a developer first installs a dependency or updates a version of a dependency.<br>Composer already filters software versions reported as vulnerable on public databases, but security advisories typically cover disclosed vulnerabilities in legitimate packages. The publication processes often take several days. They are not designed to handle rapid responses to packages that are outright malware or individual malware versions published to GitHub repositories through credential theft. Just a few days ago, attackers gained access to a GitHub repository through a developer’s machine and published malware to laravel-lang packages. Two weeks earlier the popular package intercom/intercom-php had malicious releases published on packagist.org by an attacker who similarly gained access to the underlying GitHub repository. Only rapid detection and then quick manual intervention on our side prevented the worst.<br>In addition to this release announcement we published an in-depth analysis of the current state of supply chain security for Composer & Packagist on our blog yesterday.<br>Malware Policy<br>Composer 2.10 introduces a malware policy to enable rapid removal of malicious versions published either by attackers who briefly gained control of a legitimate package, or by maintainers acting in bad faith. Flagged versions are removed from the resolution pool, so they cannot be installed via composer update, composer require or composer create-project. Crucially, the check also runs during composer install where versions flagged after a composer.lock was generated will fail the next install. A malicious release that slipped into a lockfile will not be silently pulled in on CI runs or in production deployments. The same versions are surfaced by composer audit, which fails the audit when finding malware by default.<br>Thanks to Aikido providing Packagist.org with a CC-BY 4.0 licensed feed of package versions they flagged as malware. The feature is enabled for all Composer users by default and requires no configuration for users installing packages from Packagist.org. Packages with versions flagged as malware are prominently marked on their respective package pages on Packagist.org, so they are easy to identify when browsing.<br>Private Packagist already supports the new dependency policies for malware, so as a customer you can be sure your applications benefit from the same additional security. Private Packagist Update Review already highlights malware in addition to security advisories. We are working on quickly expanding security monitoring to include malware detection next to handling of security advisories. Malware notifications will be enabled anywhere security advisories are currently enabled. We are going to post additional follow ups over the next few days on new supply chain security functionality in Private Packagist building on this Composer release.<br>This feature was originally implemented in PR #12766 and consolidated under the new policy configuration in PR #12804, as described in issue #12786.<br>Default Dependency Policies<br>The defaults match what most projects want out of the box:<br>Malware is blocked during updates, fails audits and is blocked during composer installs to prevent impact on your systems as quickly as possible.<br>Package versions with security advisories are blocked during updates and fail audits, but can be installed. You get a chance to evaluate if a published vulnerability affects you before you decide to patch.<br>Abandoned packages are only reported by audit but are not blocked during update or install.<br>Dependency Policy Configuration<br>Composer 2.10 unifies configuration for the handling of security advisories, abandoned packages, and now versions flagged as malware together under a unified config.policy object. This new configuration supersedes the previous config.audit settings.<br>Every dependency policy configuration shares the same structure:<br>block controls if matching package versions are removed from...