A word on transparency before this article begins: The PHP ecosystem has been my home since 1998. In the other ecosystems discussed here, I have no first-hand experience worth mentioning. What this article says about npm, PyPI, RubyGems, crates.io, and Maven Central is based on research, not on my own practice. I have researched and written to the best of my knowledge, and I link to the sources so that you can verify my claims. If you find a mistake, I would be happy to hear from you.
In September 2025, the JavaScript world was struck by Shai-Hulud, the first self-replicating worm in the npm ecosystem. More than 500 packages were compromised. A few days earlier, on September 8, attackers had taken over a maintainer's account via phishing and compromised 18 packages, among them chalk and debug, with a combined total of around 2.6 billion weekly downloads. Sonatype counted more than 454,600 new malicious packages in the open source registries in 2025, an increase of 75 percent over the previous year. Over 99 percent of them targeted npm.
In 2026, the PHP world stopped being a mere spectator. On April 30, 2026, intercom/intercom-php was hit: malicious releases, published through a compromised GitHub repository. On May 22, 2026, the laravel-lang packages followed: a credential stealer, published using stolen access tokens. Composer and Packagist are no longer bystanders in this story.
This is the situation in which Nils Adermann and Igor Benko published “An Update on Composer & Packagist Supply Chain Security” on May 27, 2026. It is the most comprehensive roadmap the team has made public so far. One day later, Composer 2.10 was released, the first concrete step of that roadmap. June brought a series of posts on organization-wide malware blocking, Composer version enforcement, and plugin restrictions, all of them features of the commercial Private Packagist. And on July 7, 2026, the next announced milestone for the public registry went live with Immutable Versions on Packagist.
One could turn this into a hero story: PHP, of all ecosystems, is leading the way in supply chain security. It is not quite that simple.
Composer is an ecosystem with unusually strong defaults when it comes to reacting to known threats, and with clear catching up to do on prevention through cryptographic provenance and identity verification. But it now has a clear roadmap for closing that gap.
A third aspect comes into play, one that is becoming increasingly important in the German and European debate: digital sovereignty, the question of who actually controls the infrastructure our code supply chains depend on every day. This question belongs in the assessment, too.
This article traces what Composer maintainers and the PHP community can be proud of, and where a sober look at npm, PyPI, RubyGems, crates.io, and Maven Central still has something to teach us. It shows what the roadmap announced in late May has already delivered, and why the ownership structure of our package registry tells a story of its own.
Early design decisions
Composer's most important security properties are not later additions but design decisions from its earliest days, decisions that would prove far-sighted years later.
Every Composer package carries a vendor/package name. That is not a detail, it is a line of defense. When Alex Birsan showed in 2021 with “Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies” how the internal package names of large corporations could be hijacked via npm, pip, and gems, Nils Adermann explained on the Packagist blog why this class of attack structurally comes to nothing with Composer: once a vendor prefix such as symfony/ has been assigned, nobody else can ever use it for packages.
With Composer 2.0, in October 2020, something became the default that other ecosystems have not enforced to this day: if a package exists in a private repository, Composer ignores all other sources for that name. Even if a higher version number is offered elsewhere.
Packagist does not store any source code. It is a metadata index that points to Git repositories. Nils Adermann describes this in the May 27, 2026 update as a deliberate strength:
Composer's model of distributing packages straight from git tags keeps the artifact directly tied to its source rather than to a separately-uploaded build.
This is a fundamental architectural decision. Hypothetical full access to the servers of Packagist.org is not, by itself, enough to poison packages. npm and PyPI, which host their artifacts centrally, do not have this natural separation.
Since Composer 2.2, plugins must be explicitly authorized via config.allow-plugins. If a new plugin arrives through a transitive dependency, you are asked at installation time. On npm, postinstall scripts run without prompting by default, with the full privileges of the invoking user. Exactly these lifecycle scripts were the dominant attack vector of the 2025 npm attacks.
Behind these properties stands a common design philosophy: security as an architectural property, long before supply chain security became a buzzword.
Defensive defaults: Composer 2.9 and 2.10
In November 2025, Jordi Boggiano published an article on Composer 2.9. The most important new feature sits inconspicuously between other changes in that release announcement:
Composer now automatically blocks updates to packages with known security advisories. This protection is enabled by default.
Before Composer 2.9, composer audit reported security advisories, but composer update installed affected versions anyway. Since 2.9, the resolver refuses to even consider versions with known advisories. By default, and on every resolution of the dependency graph. I have described how this mechanism works in detail in a separate article.
The comparison with other ecosystems is worthwhile. On npm, npm audit runs automatically on every npm install, but by default it only warns. pip ships with no audit at all; pip-audit is a separate tool that has to be installed deliberately. On RubyGems, crates.io, and Maven Central, too, an audit that blocks resolution is not part of the standard workflow, and tools such as cargo-audit, cargo-deny, or OWASP Dependency-Check are opt-in. Composer 2.9 drew a line here that, to my knowledge, runs this clearly in no other mainstream ecosystem.
For the release of Composer 2.10.0, Stephan Vock and Nils Adermann published an article on May 28, 2026. The unremarkable version number is deceptive. The central new concept is the Dependency Policy Framework: a unified configuration under config.policy that replaces the previous config.audit and in which Composer treats security advisories, abandoned packages, and now also malware flags according to the same scheme. Every policy shares the same structure of block (removal from the resolver pool), audit (ignore, report, or fail), and ignore (per-package exceptions).
Andrew Nesbitt has described the model precisely:
uBlock Origin for
composer install.
Named filter lists that anyone can maintain and publish at a URL, plus an active default set and the ability to subscribe to further lists or unsubscribe from them. What ad and tracking blockers established in the browser years ago is coming to the package manager.
The default policies match what most projects want:
- Malware is blocked on updates, makes audits fail, and is also blocked on
composer install. This is the crucial point: a malicious version that is flagged only after thecomposer.lockwas generated fails on the next install instead of silently making its way into CI runs or production deployments. The same check applies tocomposer requireandcomposer create-project. - Security advisories are taken into account on updates and make audits fail, but affected versions can be installed. You get the chance to assess whether a published vulnerability affects you before you patch.
- Abandoned packages are only reported by the audit, not blocked.
Malware protection is active by default for all users of Composer 2.10 and requires no configuration at all for packages from Packagist.org. The data comes from Aikido through a feed licensed under CC-BY 4.0, in other words an open one.
One point Nesbitt carves out particularly sharply: malware is not a reserved name. It is a bundled list with built-in presets, but any other key under config.policy defines its own list with the same options. The data for it can come from a Composer repository that offers a list of that name, from one or more HTTPS endpoints under sources, or from both combined. Composer sends the Package URLs of the project's dependencies to each source and receives filter entries in the same format Packagist delivers. Aikido is the default source on Packagist.org, but malware.ignore-source disables that source, and another one can take its place or run alongside it. No provider holds a special position.
This allows a community-maintained typosquat list, an organization's internal “legal has not cleared these packages yet” list, or a list nobody sells commercially to hook in alongside the built-in lists, with the same syntax for exceptions. At the end of May 2026, Packagist's summary file contained around 70 flagged packages. Issue #12786 already reserves license, support, maintenance, and minimum-release-age as future built-in list names, which will presumably arrive through exactly this mechanism rather than as separate features.
If you need to suspend blocking temporarily, you use the new --no-blocking flag or the COMPOSER_NO_BLOCKING environment variable, and "policy": false is the kill switch for all policies at once. The original feature from pull request #12766 was consolidated under the new policy configuration in pull request #12804. Stephan Vock contributed the bulk of the implementation both in composer/composer and in composer/packagist, funded by the Sovereign Tech Agency and Aikido.
Also in 2.10: the end of source fallbacks. When the download of a packaged dist artifact failed, Composer used to automatically fall back to the source repository. That could become security-relevant, for instance when a mirror holds a known-clean version but a network error triggers the fallback to a malicious tag in the underlying Git repository. In 2.10 this behavior is deprecated and only available through the new source-fallback option; in 2.11 it is scheduled to be removed.
Immutable versions on Packagist
Alongside the client features, a server-side change on Packagist.org shores up the foundation: stable version immutability, announced in May and fully live since July 7, 2026. The rule is simple: once published, the Git reference of a stable version never changes again. If the tag in the source repository is deleted, recreated, or moved to a different commit, the published version keeps its original reference. The retag is blocked, a warning appears on the package page, and all maintainers are notified by email.
This closes an attack vector that nearly every recent Packagist attack used: attackers with compromised GitHub access overwrote existing, trusted tags so that the victims' next composer update pulled in the malicious version. And because this is a server-side change, it also protects older Composer clients that do not understand filter lists.
Along the way, the launch post clears up a misconception that affects well-meaning maintainers, too: the pattern of “quickly delete the tag and set it again, nobody has installed it yet” was never safe. Automated systems react to Packagist's changes feed within seconds. Mirrors cache the archive under the original reference. CI systems with automated dependency updates may already have committed the version to a lockfile. Adermann's recommendation is disarmingly pragmatic: version numbers cost nothing. The fix belongs in the next patch version, if need be as a fourth component, turning 3.2.0 into 3.2.0.1.
Two clarifications matter to put the feature into perspective. First, the scope: what is immutable is the version metadata, the mapping of version number to Git commit. The downloaded archives themselves are not yet. For most packages, the GitHub API generates the zip archives on demand and does not guarantee byte-identical archives for the same commit over time. Immutable artifacts are the declared next goal, planned “in the coming months” through a combination of self-hosted artifacts and verification data in the transparency log.
Second, the question of deletion: if versions are immutable, how do you remove one that really has to go, for instance because a release accidentally contained secrets? The answer is a soft deletion model with explicit reasons. Instead of vanishing without a trace, a version entry is preserved and marked with the reason: no longer present in the source repository, deleted by the maintainer, removed by admins, or hidden by admins. It is shown grayed out on the package page, can no longer be resolved by Composer, and has, where sensible, a recover button. Anyone can trace after the fact what happened to a version and why, instead of discovering that it was silently rewritten or deleted.
The Transparency Log
The public Packagist Transparency Log has been live for a few months and proved its value in the recent attacks. Adermann and Benko write on May 27, 2026:
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.
The log records ownership changes, the addition and removal of maintainers, user changes, and changes to version references. With the immutability launch on July 7, 2026, three more event classes are added: blocked retag attempts, soft deletions with reasons, and recoveries. Each of these actions leaves a permanent public entry. The transparency log was funded by the Sovereign Tech Agency. We will come back to that in a moment.
Server-side or client-side?
A look at other ecosystems shows that most registries handle confirmed malware server-side. PyPI has had Project Quarantine since August 2024: packages are hidden from the simple index so that pip install no longer finds them. npm removes the package and publishes a security holding placeholder under the same name. RubyGems and crates.io yank the affected version. Hex.pm marks a release as retired, which warns during resolution but does not block.
Server-side has one clear advantage: every client gets the protection automatically, including ten-year-old installations that are never updated. The downside: the registry operators are the only judging authority. The list contains only what they themselves have already reviewed and removed. A security vendor that discovered something an hour ago can write a blog post, but cannot put itself between you and pip install.
Composer's design makes the opposite choice: the package stays on the registry with a flag, and which flags are honored is decided by the client configuration, including flags from third parties. The price: an install with Composer 2.8 pulls in a flagged version without objection until Packagist follows up server-side. This is exactly where the server-side additions come in. Stable version immutability and the soft deletion model reach older clients as well, because soft-deleted versions disappear from the metadata every Composer reads.
Composer does not have to choose between the two approaches. It combines client-side diversity of sources with server-side immutability.
Aikido offers its malware detection for npm as well. There, the tool is called Safe Chain, and you have to install it deliberately, as with Socket safe npm or the Socket Firewall as a local registry proxy. The difference between default-on and opt-in is substantial: opt-in protection reaches only those who know about it and turn it on. Default-on protection reaches everyone. That the Composer check also applies at install time is especially valuable: it protects not only developers running updates but every automated pipeline in which nobody actively thinks about dependencies anymore.
Who owns our supply chain?
When we talk about supply chain security, we think of malware, compromised tokens, provenance signatures. We think less often about the fact that every package registry has an owner. And that this owner is the final authority in crisis situations, regulatory shifts, or business decisions. Anyone comparing Composer and Packagist with other ecosystems should not leave this question out. In 2026, it has become a political one.
npm was acquired by GitHub in March 2020, which in turn has belonged to Microsoft since the $7.5 billion acquisition of 2018. The largest package ecosystem in the world by far runs on Microsoft infrastructure today.
PyPI is owned by the Python Software Foundation, a 501(c)(3) nonprofit under Delaware law. The PSF is structurally more independent than npm, but its vulnerability showed clearly in 2025. In October 2025, it withdrew its application for a $1.5 million NSF grant for PyPI's supply chain security even though the grant had already been recommended for funding. The grant conditions would have required the PSF to affirm that it runs no programs advancing diversity, equity, and inclusion; in the board's unanimous assessment, that would have been a betrayal of its mission. In January 2026, Anthropic pledged $1.5 million to the PSF over two years, among other things for exactly the PyPI security work the NSF grant would have funded. The connection between the two events was drawn by observers, not by those involved; the amount, duration, and project description, however, match exactly. A US nonprofit operating fundamental software infrastructure is more dependent on US politics and US corporate money than many European users probably assume.
RubyGems is operated by Ruby Central, likewise a US 501(c)(3) nonprofit. What happened there in 2025 should be read by anyone thinking about registry governance. In August 2025, according to Ruby Central's own incident report, a $250,000 funding commitment was withdrawn. The company behind Sidekiq later publicly justified this with DHH's appearance at RailsConf 2025. In September 2025, Ruby Central revoked the admin rights of the long-time maintainers of RubyGems and Bundler and took control of the projects. Research from the community names pressure from main sponsor Shopify as the background, but this has not been officially confirmed. The affected maintainer Ellen Dash called the process a “hostile takeover” and resigned. In April 2026, the board declared that Ruby Central was in “real financial jeopardy” and parted ways with the executive director, the CFO, and the PR agency. The former maintainers are now building an alternative gem server with gem.coop. The episode shows how quickly seemingly stable open source stewardship can collapse.
crates.io is owned by the Rust Foundation, a Delaware nonprofit. Its platinum-tier members today include Arm, AWS, Google, Huawei, Meta, Microsoft, and OpenAI. Mozilla, one of the founding members in 2021, is in the silver tier today. The infrastructure itself is carried by in-kind donations: file hosting comes from AWS, the CDN from Fastly. This construction makes Rust powerful, and at the same time it makes the ecosystem strongly dependent on a handful of mostly American tech corporations.
Maven Central is operated by Sonatype, a US company from Fulton, Maryland. Since a majority investment in November 2019, Sonatype has been majority-owned by Vista Equity Partners, an American private equity fund. The central registry of the entire Java ecosystem is thus controlled by a for-profit private equity portfolio company.
Composer and Packagist are a special case. The Composer source code lives with the composer organization on GitHub. But the central public registry Packagist.org is operated by Packagist Conductors GmbH, based in Berlin, with Nils Adermann and Jordi Boggiano as managing directors. That is the information recorded in the imprint. The GmbH finances itself through the commercial product Private Packagist, which cross-subsidizes the work on the Composer CLI and the operation of Packagist.org.
The May 27, 2026 update names, for the first time explicitly, all three funding sources of the current security work: Private Packagist as the main pillar, plus the Sovereign Tech Agency and Aikido as external supporters. It also announces a new sponsoring program for companies.
| Ecosystem | Operator of the central registry | Jurisdiction |
|---|---|---|
| npm | Microsoft (via GitHub) | USA |
| PyPI | Python Software Foundation | USA |
| RubyGems | Ruby Central | USA |
| crates.io | Rust Foundation | USA |
| Maven Central | Sonatype (majority owner: Vista Equity Partners) | USA |
| Composer/Packagist | Packagist Conductors GmbH | Germany |
Among the six ecosystems compared here, Packagist is the only central registry not operated by a US entity. In December 2024, the Cyber Resilience Act came into force, the first law to define the role of the open source steward, with Article 24 governing its obligations. Together with the EU debate on digital sovereignty, this turns Packagist Conductors' Berlin domicile into a property with practical relevance for European companies.
What the Sovereign Tech Agency is doing here
The Sovereign Tech Agency is an initiative of the German federal government, founded in 2022 as the Sovereign Tech Fund with money from the Federal Ministry for Economic Affairs, today a subsidiary of the Federal Agency for Disruptive Innovation (SPRIND), funded by the Federal Ministry for Digital Affairs and State Modernization. Its budget grew from 11.5 million euros in 2023 to 17 million euros in 2024. The idea is catching on: an EU counterpart modeled on the German original was proposed in a feasibility study in July 2025, and in June 2026 the EU Commission announced a dedicated funding instrument for the maintenance of critical open source components in its open source strategy. The mission is explicit: secure open source infrastructure Europe depends on with public money, without putting it under state control.
Concretely, the Sovereign Tech Agency funded the Packagist Transparency Log, the very tool that enabled the forensic analysis of the April and May 2026 attacks, as well as parts of the filter list work in Composer 2.10. The next funded phase is the work on organizational package ownership. I know of no other mainstream package ecosystem with a comparable constellation of a European operator, commercial cross-subsidy, and public funding through a democratically legitimized sovereignty initiative.
Sovereignty is not everything
A Berlin GmbH can go bankrupt. German public funding can be cut. A foundation structure like Rust's or Python's has the advantage of greater governance robustness over a GmbH. And Sonatype has operated Maven Central reliably for many years despite its private equity owner. Ownership alone does not determine behavior.
But this is what 2026 looks like: A US government attaches political conditions to research funding (see the PSF). A corporation reportedly pressures a US nonprofit into taking over critical open source repositories (see Ruby Central). And the EU is finally coming to see digital sovereignty as an economic necessity, too. In this situation, it matters that a Berlin GmbH operates the central registry of an ecosystem whose language powers a substantial part of the web.
This is not the most important aspect of the Composer assessment. But it is one the PHP community should not talk down. And one for which Nils Adermann, Jordi Boggiano, and their fellow contributors deserve recognition of its own.
What we can be grateful for
This work has been done for years, underpaid and largely invisible. So let me name names.
As co-founder of Packagist, Nils Adermann made architectural decisions that protect our ecosystem today. His 2021 article on dependency confusion is not just a technical response but a lesson in how a maintainer calmly explains why his platform was built differently. The comprehensive roadmap update of May 27, 2026, which he wrote together with Igor Benko, is an unusually open and detailed commitment for the years ahead.
Jordi Boggiano led Composer as its maintainer for more than a decade. Anyone who has ever run open source projects of this magnitude knows what that means: thousands of issues, hundreds of pull requests, countless edge cases in the version resolver, and, on the side, taking every security incident seriously. The release post for Composer 2.9 bears his name. Without this work, there would be no Automatic Security Blocking.
Stephan Vock implemented most of the malware filter feature and, together with Nils Adermann, was responsible for the release of Composer 2.10. His contribution has been at work in production PHP workflows worldwide since May 28, 2026.
Packagist Conductors GmbH funds a substantial part of the work on the free Composer and the operation of Packagist.org through commercial Private Packagist subscriptions. By its own account, the team reacts to detected incidents “within minutes”. It is one of the few business models in the open source world that pays for security work on a public good directly out of the commercial product. And it keeps the public registry infrastructure of the PHP ecosystem in European hands.
The Sovereign Tech Agency has understood that critical open source infrastructure needs funding before it collapses or gets compromised. That German tax money flows into the security of a package ecosystem used worldwide is a remarkable and welcome development.
Aikido provides the malware feed that has been integrated into Packagist since March 2026. The feed is licensed under CC-BY 4.0 and therefore open, and the integration remains open to further data providers with suitable licenses. A multi-source approach that does not make the platform dependent on a single vendor. With the release of Composer 2.10, Aikido has also become a financial sponsor of Composer and Packagist.org, not just a data supplier but a co-funder of ongoing operations.
If you run composer install today and do not waste a thought on supply chain security, because versions with known vulnerabilities are blocked by default in the background, because Composer 2.10 also keeps malware out of your dependency tree, and because a Berlin team responds to incidents at night, then a handful of people are working to keep your day uneventful. That deserves to be said out loud once in a while.
Learning from other ecosystems
Now for the uncomfortable part. In one central area of supply chain security, Composer/Packagist had catching up to do until May 27, 2026: cryptographic provenance and identity verification. The roadmap post does not close this gap, but it spells out concretely how it is to be closed. Let us look at what the other ecosystems have and hold it against the plan.
PyPI: the pioneer of the modern identity stack
PyPI introduced the concept of Trusted Publishing via OpenID Connect in April 2023. Instead of storing long-lived API tokens in CI systems, where they can leak, be stolen, or be exfiltrated by accident, the build job authenticates directly to PyPI using short-lived OIDC tokens from the identity provider. In November 2024, the Sigstore-based attestations per PEP 740 became generally available, and with Trusted Publishing through the official GitHub Action they are active by default. Mandatory 2FA has applied to all maintainers since January 1, 2024.
What Composer/Packagist has on the roadmap in response: mandatory MFA as a long-term goal, with FIDO2 support. The first steps are to begin in about six months: MFA events become visible in the transparency log, and MFA status appears on maintainer profiles. Trusted Publishing via OIDC is explicitly named as an element of the long-term architecture. SLSA build provenance and Sigstore attestations, verified client-side by Composer, are part of the vision of a future in which Packagist.org hosts immutable build artifacts directly. That will take time. But an open gap has turned into a plan, with explicit reference to the OpenSSF principles and the SLSA dependency track. This commitment to external standards is new.
Maven Central: high hurdles for publishing
Anyone who wants to publish a package to Maven Central in the Java world goes through a process stricter than in any other ecosystem discussed here: a reverse-domain groupId with namespace verification via DNS or code hosting account, a mandatory GPG signature on all artifacts, and a staging workflow with server-side validation.
Composer/Packagist's position on this: in the May 27, 2026 update, Adermann formulates the vision that Packagist.org will, in the long run, host immutable build artifacts directly, with SLSA provenance and Sigstore attestations. That would be a deep intervention in the architecture, because today Composer's strength lies precisely in the separation between metadata index and code repository. The first building block has been in place since July 7, 2026: the version metadata is immutable. The launch post makes the next step concrete, immutable artifacts “in the coming months”, through self-hosted artifacts combined with verification data in the transparency log. The direction is set; delivery comes in stages.
crates.io: collaborative auditing as an alternative path
The Rust community has established a framework for collaborative auditing with cargo-vet. Mozilla audits crates for Firefox, Google audits crates for ChromeOS and Fuchsia, and both publish their audits so that other projects can import them. In projects that use cargo-vet, every crate in the Cargo.lock must be covered by a local or imported audit entry. Anything unaudited fails the build.
One day after the release of Composer 2.10, Andrew Nesbitt makes what may be the most important observation about the new architecture: Composer's wire format already supports allowlist semantics. A mapping of packages to version constraints describes allowed versions just as well as forbidden ones; the only difference is whether the client discards the matches or everything else. A Composer list in allow mode, fed by a community-published “someone has actually read these packages” data source, would give PHP the federated audit model that cargo-vet established for Rust. The reserved future list names license, support, and maintenance point to allow semantics anyway, because license policies are almost always a list of permitted SPDX identifiers.
cargo-vet is so far the only established collaborative auditing framework in the major ecosystems, but Composer's platform design has shipped the mechanism for it. What is needed now are communities that start publishing audit feeds. The Symfony maintainers could make their internal reviews public so that Laravel projects can consume them, and vice versa. The infrastructure for this has been in place since May 28, 2026.
npm: catching up fast, too
It would be wrong to write npm off despite the catastrophic security situation of 2025. The response was substantial. Trusted Publishing with OIDC became generally available in July 2025. On September 22, 2025, right after Shai-Hulud, GitHub announced a security roadmap for npm: mandatory 2FA with no bypass for local publishing, FIDO instead of TOTP, granular publishing tokens with a maximum lifetime of seven days, and the end of classic tokens. Since npm 11.10.0, the client supports a configurable minimum age for releases with min-release-age, as an opt-in. And on May 22, 2026, npm introduced Staged Publishing: a two-step release process in which an uploaded release only becomes installable after a human approves it with a 2FA challenge.
What Composer/Packagist has on the roadmap in response: exactly this feature. A staged release flow with FIDO2 confirmation, mandatory for packages with a large user base. Here, the PHP ecosystem is merely catching up. But it has committed to the same goal.
minimum-release-age, too, is no longer just the open issue #12847. According to the May 27, 2026 update, it is the first designated follow-up policy after the Dependency Policy Framework from 2.10. Adermann calls it one of the most effective defenses against the recent class of attacks, because malicious versions are typically pulled in or detected within hours of publication. It was blocked by prerequisite work on the Packagist side: release metadata must be reliably immutable before the publication timestamp is usable as a security input. With version immutability live since July 7, 2026, that precondition is met.
How much this matters is shown by Nesbitt's survey: pnpm, Yarn, Bun, npm, uv, pip, and Poetry have all introduced cooldown mechanisms within the last twelve months. PHP is a latecomer here. Nesbitt also stresses that cooldowns and filter lists complement each other. A cooldown blocks everything released in the last N days, on the assumption that malicious code is usually discovered within that window. A filter list names specific versions and is only as good as the latency of those who maintain it. A sensible configuration is a short cooldown plus a malware list for everything that slips through. This combination is coming to Composer, and both building blocks sit in the same config.policy block.
RubyGems: malware scanning on upload
A peculiarity of RubyGems: every gem upload is automatically screened, with static and dynamic code analysis, behavioral checks, and metadata review. High risk scores escalate to manual review.
Packagist hosts no code and therefore cannot scan it at publishing time. That is the flip side of the architecture without central code hosting. With Composer 2.10, this gap is closed through external feeds on the resolver side. Should Packagist.org host immutable artifacts directly in the long run, this asymmetry would change.
Four observations on the roadmap
If we take the roadmap of May 27, 2026, the release of Composer 2.10, and the updates published since then seriously, four observations emerge.
First: the plan is remarkably complete. Practically every feature that is established as best practice in other ecosystems and missing from Composer/Packagist today is explicitly on the roadmap: mandatory MFA, FIDO2, Trusted Publishing via OIDC, SLSA provenance, Sigstore attestations, staged releases, minimum-release-age. As target standards, the update names the OpenSSF Principles for Package Repository Security (authorization level 3) and the SLSA dependency track (level 3/4). This is no longer a vague declaration of intent.
Second: the sequence builds on itself, and it is being kept. Version immutability, announced in May and delivered on July 7, is the prerequisite for minimum-release-age. The Dependency Policy Framework in 2.10 is the architecture that further policies will land in. The transparency log was the prerequisite for blocked retags and soft deletions now being logged publicly; exactly that happened with the July launch. Metadata immutability, in turn, is the prerequisite for artifact immutability, which is announced as the next step. And organizational package ownership is the prerequisite for meaningful mandatory MFA in large open source projects such as Symfony and in companies. The plan is technically coherent, and the first milestones were delivered on schedule.
Third: the timeline remains the open point, and funding is the bottleneck. Adermann and Benko avoid concrete dates for the biggest steps, that is, mandatory MFA, Trusted Publishing, and Sigstore. That is honest, and the on-schedule delivery of version immutability in July strengthens confidence in the commitments. But the immutability launch post contains a sentence the PHP community should not skim over: additional corporate sponsors are urgently sought to push this work forward. The work on immutable artifacts, the next big milestone, explicitly depends on additional funding. If your company builds on Composer, this is a very concrete way to secure your own supply chain: sponsoring@packagist.org.
Fourth, and this points beyond Composer: Andrew Nesbitt has documented in recent months how fragmented the policy formats of the various package managers are. Composer's wire protocol, Package URLs as input and filter entries as output, is in his assessment a promising candidate for the cross-ecosystem standard format he had been looking for. His closing remark:
I'd like to see more package managers copy this wholesale.
Coming from someone who surveys the package manager landscape like few others, that sentence carries weight. If the model of Composer 2.10 is picked up by pnpm, npm, pip, or Cargo in the coming months, PHP will be a pioneer in a place where it was long a latecomer.
Conclusion
With Composer 2.9, Composer 2.10, and the version immutability delivered in July, Composer and Packagist proved in 2025 and 2026 that the team understands the threat landscape, acts decisively, and actually delivers announced milestones. On one side stand the structural design decisions of the early days: vendor namespaces, canonical repositories, no central code distribution, a direct tie to the source. On the other, the recent defensive defaults: security blocking, malware filtering at install time as well, immutable version metadata with soft deletion and transparency log records. Together, this adds up to protection that is more robust for ordinary PHP workflows without security expertise than in almost any other ecosystem.
Add to this the ownership structure: with Packagist Conductors GmbH as a European operator and the Sovereign Tech Agency as accompanying public funding, the PHP supply chain sits in a constellation that stands out internationally and has practical relevance in the context of the EU sovereignty debate. That is a real achievement, one the Composer team can be proud of and for which we as a community owe recognition.
At the same time, the work on Trusted Publishing, Sigstore provenance, mandatory MFA, cooldown mechanisms, and SLSA-compliant build artifacts lies ahead of us. PyPI, npm, and Maven Central are ahead here in different constellations. But unlike just a few weeks ago, the open question is no longer whether the PHP world wants to close these gaps, only how fast it can.
And there is a first step every maintainer can take today. Adermann puts it directly in the update:
If you maintain any package on Packagist.org and don't have MFA enabled, please enable it now.
The four most important sources for this article are “An Update on Composer & Packagist Supply Chain Security” by Nils Adermann and Igor Benko (May 27, 2026), the release post for Composer 2.10 by Stephan Vock and Nils Adermann (May 28, 2026), “Composer's dependency policies” by Andrew Nesbitt (May 29, 2026), and “Immutable Versions on Packagist” by Nils Adermann (July 7, 2026). All other sources are linked where they are used in the text.
