Pangram verdict · v3.3
We believe that this document is primarily human-written, with some AI-generated content detected
AI likelihood · overall
MixedArticle text · 1,609 words · 5 segments analyzed
composer
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.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.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.TL;DRIn place today:Aikido malware detection integrated into Packagist.org and the package metadata Composer consumes (open to further data providers with appropriate free licenses).Rapid manual incident response by the Packagist team.Public transparency log, which accurately recorded the git tag modifications used in the recent attacks.Shipping this week:Composer 2.10, introducing a unified dependency policy framework that covers malware-flagged versions, vulnerability advisories, and abandoned packages.Stable version immutability on Packagist.org: Tagged versions can no longer be silently rewritten by re-tagging in git repositories.New supply chain security features in Private Packagist for organization-wide control, to be detailed in follow-up posts over the next few days.More predictable composer install download behavior (deprecation of source fallbacks).Coming in the next weeks and months:Minimum-release-age / cooldown dependency policy in Composer.Improved admin tooling on Packagist.org: manual malware feed overrides, delisting for older Composer clients, package freezing during active account compromises.MFA events surfaced in the transparency log; MFA status visible on maintainer profiles.
Organizational Package Ownership, replacing shared company accounts with proper multi-user management and package vendor scoped configuration options.Longer-term direction:Mandatory MFA across Packagist.org, with stricter requirements at the organization levelFIDO2-backed staged release flow, required for packages with large userbasesPackagist.org hosting immutable build artifacts directly, with SLSA build provenance and Sigstore attestations verified on the Composer client side.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.The rest of the post goes through each of these in detail.Detection and Incident ResponseIn 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.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.The Transparency LogPackagist.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.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.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.Why does this kind of record matter in general?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 to anyone who is interested, not just to the Packagist.org admins.Account security review. If you need to review your own account, a maintainer's account, or a package you maintain or use, the log gives you a place to check what happened and when.Incident timelines. When a compromise is investigated, sometimes days or weeks after the fact, a record of what changed and when is often the difference between a confident postmortem and a guess.Observability for consumers. Anyone depending on a package can inspect the history of changes that affect it: who maintains it, when ownership moved, when references changed. If something bad happens, it leaves traces that anyone can audit.We plan to keep expanding what the log captures. The next additions are on the account security side.MFA Events, Profile Visibility, and a Path to Mandatory MFAWe already collect MFA-related events internally (enabling, disabling, recovery code usage, and similar). In about six months, these events will start appearing publicly in the transparency log alongside the existing entries. This ties directly into the "account security review" point above: it lets anyone see whether the maintainers of a package are actively keeping their accounts secure.Once that is in place, we will go a step further and surface MFA status on maintainer profiles, so it is visible whether the people behind a package have MFA enabled. We expect this to nudge the ecosystem toward stronger account security, and it is one more reason to enable MFA on your account now if you haven't already.Attackers already prioritize targets by download counts and dependency graphs, both of which are public information, MFA status doesn't change which packages are worth attacking, only how feasible an attack is once a target is chosen. Meanwhile the consumers of those packages have a legitimate interest in knowing the security posture of what they depend on, and today they have no way to see it.
Making MFA status visible turns it from a private hygiene question into a property of the package that downstream users can see, ask about, and factor into their decisions. We expect this shift will get MFA adopted across the ecosystem faster than any amount of individual nudging.Beyond that, we intend to implement FIDO2 support and eventually require MFA for all Packagist.org accounts. There is no fixed date yet, but the direction is set, and we want to give maintainers enough lead time to enable it without disruption.A practical note for organizations using shared company user accounts and struggling with MFA: Please move to individual accounts per maintainer ahead of these changes. Organizational Package Ownership, which we are actively building, is designed to make that transition straightforward. You will be able to have an organization own packages and vendor prefixes, while individual users act on behalf of the organization, without the security and accountability problems of a shared login.Dependency Policies in Composer 2.10Composer 2.10 is shipping later this week, with a dedicated release announcement to follow on this blog. This section is a short summary of the parts most relevant to supply chain security.The headline change is the introduction of dependency policies, a single framework for configuring how Composer treats vulnerability advisories, abandoned packages, and now packages flagged as malware.
The framework matters because it gives us a clean place to add more policies later, rather than bolting each new check on as a one-off feature.The first follow-up that we have already designed is a minimum release age policy (also known as cooldown period): refuse to install a version that was published less than N hours or days ago. This is one of the more effective defenses against the recent class of attacks, because malicious versions are typically pulled or detected within hours of publication. The policy is currently blocked by prerequisite work on the Packagist.org side. We need release metadata to be reliably immutable before we can safely treat "publication time" as a security input. More on that below.Composer 2.10 will disable and deprecate source fallbacks for package downloads, to be removed entirely in 2.11. Previously, failing stable dist artifact downloads would automatically fall back to the underlying source repository. This behavior could lead to unexpected behaviors when the repository intentionally removes or blocks specific versions available on the underlying source repository.Administrative Tooling for Active ResponseOperating Packagist.org under active attack has surfaced some sharp edges in our internal tools. The work currently in progress includes:Manual malware feed overrides, so an admin can flag (or unflag) a version without waiting for the automated feed to catch up.Delisting confirmed malware versions for older Composer clients that don't yet support the dependency policy framework, so they don't silently install something we already know is malicious.Freezing packages while the corresponding VCS or GitHub repository is under attacker control, so no new tags can show up on Packagist.org until the underlying account compromise is resolved.None of this is glamorous, but a lot of incident response time today is spent working around tooling gaps.Version ImmutabilityThis is the larger change, and the one we have been working through the details on for a while. The first piece is imminent: stable versions on Packagist.org will become immutable as part of a deploy scheduled for this week, see https://github.com/composer/packagist/pull/1742.Today, the transparency log already records when a version's source reference changes (you can filter the log by version_reference_changed to see this). That's useful for detection. But detection after the fact is a weak help compared to not allowing the change in the first place.