An Update on Composer & Packagist Supply Chain Security

The last months, and even more so the last weeks, saw an increasing amount of software supply chain attacks targeting open-source ecosystems. A handful of these have hit the PHP ecosystem too, via taken-over GitHub accounts and stolen access tokens that let attackers publish new tags on packages they had no legitimate access to. Most notably laravel-lang on May 22 and intercom/intercom-php on April 30th.<br>This post is an update on where Composer and Packagist.org's supply chain security work stands right now: what's already in place, what ships in the next few weeks, and the longer-running projects we're working through. We've been focused on this area for close to a year, and there's enough to cover that it's worth pulling it together in one place.<br>If you maintain any package on Packagist.org and don't have MFA enabled, please enable it now. We will begin to publish package maintainer MFA status to package transparency logs and it will be visible on profiles. See the MFA section below for details.<br>TL;DR<br>In place today:<br>Aikido malware detection integrated into Packagist.org and the package metadata Composer consumes (open to further data providers with appropriate free licenses).<br>Rapid manual incident response by the Packagist team.<br>Public transparency log, which accurately recorded the git tag modifications used in the recent attacks.<br>Shipping this week:<br>Composer 2.10, introducing a unified dependency policy framework that covers malware-flagged versions, vulnerability advisories, and abandoned packages.<br>Stable version immutability on Packagist.org: Tagged versions can no longer be silently rewritten by re-tagging in git repositories.<br>New supply chain security features in Private Packagist for organization-wide control, to be detailed in follow-up posts over the next few days.<br>More predictable composer install download behavior (deprecation of source fallbacks).<br>Coming in the next weeks and months:<br>Minimum-release-age / cooldown dependency policy in Composer.<br>Improved admin tooling on Packagist.org: manual malware feed overrides, delisting for older Composer clients, package freezing during active account compromises.<br>MFA events surfaced in the transparency log; MFA status visible on maintainer profiles.<br>Organizational Package Ownership, replacing shared company accounts with proper multi-user management and package vendor scoped configuration options.<br>Longer-term direction:<br>Mandatory MFA across Packagist.org, with stricter requirements at the organization level<br>FIDO2-backed staged release flow, required for packages with large userbases<br>Packagist.org hosting immutable build artifacts directly, with SLSA build provenance and Sigstore attestations verified on the Composer client side.<br>Bringing the Composer + Packagist stack to OpenSSF Securing Software Repositories Working Group Principles for Package Repository Security Authorization L3 and SLSA Working Draft Dependency Track L3 and L4.<br>The rest of the post goes through each of these in detail.<br>Detection and Incident Response<br>In March 2026, Packagist.org started importing malware detection results from Aikido (see composer/packagist#1681). When a version is flagged, the warning shows up prominently in the Packagist.org UI and is included in package metadata served to Composer. Aikido flagged the malicious versions in each of the recent incidents.<br>The team operating Packagist.org has been responding to each incident within minutes of detection, pulling affected packages or versions before they can be installed at scale. Manual intervention is not the type of rapid response we want this process to depend on long-term, though, and most of what follows is about replacing reaction with prevention.<br>The Transparency Log<br>Packagist.org has a public transparency log (login required) that records security-relevant events across the repository. It covers things like package ownership changes, maintainer additions and removals, user changes, and changes to version references.<br>The log is a tool for investigative use cases and continuous monitoring for risks. If you're interested in building tools or integrations on top of it, get in touch at contact@packagist.org or GitHub issues and help shape the API for this log.<br>Work on the transparency log was funded by the German Sovereign Tech Agency and it has been directly useful in handling the recent attacks. One of the key elements of nearly every recent supply chain attack on Packagist involved attackers modifying existing git tags after the fact. The transparency log accurately recorded each of these modifications, which let us identify exactly what had been manipulated and reconstruct precise timelines of each attack.<br>Why does this kind of record matter in general?<br>Ownership changes and takeovers. When a package changes hands, every downstream user has a legitimate interest in knowing. A public log means a sudden new maintainer on a widely used library is visible...