Composer und Packagist im Supply Chain-Stresstest

Ein Wort zur Transparenz, bevor dieser Artikel beginnt: Im PHP-Ökosystem bin ich seit 1998 zuhause. In den anderen Ökosystemen, um die es hier geht, habe ich keine nennenswerte Erfahrung aus erster Hand. Was dieser Artikel über npm, PyPI, RubyGems, crates.io und Maven Central sagt, beruht auf Recherche, nicht auf eigener Praxis. Ich habe nach bestem Wissen und Gewissen recherchiert und geschrieben, und ich verlinke die Quellen, damit du meine Aussagen nachprüfen kannst. Wenn du einen Fehler findest, freue ich mich über eine Nachricht.

Im September 2025 wurde die JavaScript-Welt von Shai-Hulud heimgesucht, dem ersten selbstreplizierenden Wurm im npm-Ökosystem. Mehr als 500 Pakete wurden kompromittiert. Wenige Tage zuvor, am 8. September, hatten Angreifer per Phishing den Account eines Maintainers übernommen und 18 Pakete kompromittiert, darunter chalk und debug, mit zusammen rund 2,6 Milliarden wöchentlichen Downloads. Sonatype zählte 2025 insgesamt mehr als 454.600 neue Schad-Pakete in den Open Source-Registries, ein Plus von 75 Prozent gegenüber dem Vorjahr. Über 99 Prozent davon entfielen auf npm.

2026 hat die PHP-Welt nicht mehr nur zugeschaut. Am 30. April 2026 traf es intercom/intercom-php: bösartige Releases, publiziert über ein kompromittiertes GitHub-Repository. Am 22. Mai 2026 folgten die laravel-lang-Pakete: ein Credential Stealer, publiziert über gestohlene Access Tokens. Composer und Packagist sind nicht mehr die Unbeteiligten dieser Geschichte.

Genau in dieser Lage haben Nils Adermann und Igor Benko am 27. Mai 2026 „An Update on Composer & Packagist Supply Chain Security“ veröffentlicht. Es ist die umfassendste Roadmap, die das Team bisher öffentlich gemacht hat. Einen Tag später wurde Composer 2.10 veröffentlicht, der erste konkrete Schritt dieser Roadmap. Im Juni folgte eine Serie von Posts zu organisationsweitem Malware Blocking, Composer Versions Enforcement und Plugin-Restriktionen, allesamt Features des kommerziellen Private Packagist. Und am 7. Juli 2026 ging mit Immutable Versions on Packagist der nächste angekündigte Meilenstein für die öffentliche Registry live.

Daraus ließe sich eine Heldengeschichte machen: Ausgerechnet PHP marschiert in der Supply Chain Security vorneweg. Ganz so einfach ist es nicht.

Composer ist ein Ökosystem mit ungewöhnlich starken Defaults bei der Reaktion auf bekannte Bedrohungen, das in der Prävention durch kryptographische Provenance und Identity Verification deutlichen Nachholbedarf hat. Aber es hat jetzt eine klare Roadmap, dieses Defizit zu schließen.

Ein dritter Aspekt kommt hinzu, der in der deutschen und europäischen Diskussion zunehmend wichtig wird: digitale Souveränität, also die Frage, wer eigentlich die Infrastruktur kontrolliert, auf die unsere Code-Lieferketten täglich angewiesen sind. Auch diese Frage gehört in die Bilanz.

Dieser Artikel zeichnet nach, worauf Composer-Maintainer und PHP-Community stolz sein dürfen und wo wir mit nüchternem Blick von npm, PyPI, RubyGems, crates.io und Maven Central noch lernen können. Er zeigt, was die Ende Mai angekündigte Roadmap bereits konkret geliefert hat und warum die Eigentumsstruktur unserer Package Registry eine eigene Geschichte erzählt.

Designentscheidungen der Anfangszeit

Die wichtigsten Sicherheitseigenschaften von Composer sind keine späteren Anbauten, sondern Designentscheidungen aus der Anfangszeit, die sich Jahre später als weitsichtig erweisen sollten.

Jedes Composer-Paket trägt einen vendor/package-Namen. Das ist kein Detail, sondern eine Verteidigungslinie. Als Alex Birsan 2021 mit „Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies“ zeigte, wie sich über npm, pip und gems die internen Paketnamen großer Konzerne kapern ließen, erklärte Nils Adermann im Packagist-Blog, warum diese Angriffsklasse bei Composer strukturell ins Leere läuft: Sobald ein Vendor-Prefix wie symfony/ einmal vergeben ist, kann ihn niemand anders mehr für Pakete verwenden.

Mit Composer 2.0 wurde im Oktober 2020 zum Default, was andere Ökosysteme bis heute nicht durchgesetzt haben: Wenn ein Paket in einem privaten Repository existiert, ignoriert Composer für diesen Namen alle anderen Quellen. Auch dann, wenn dort eine höhere Versionsnummer angeboten wird.

Packagist speichert keinen Quellcode. Es ist ein Metadaten-Index, der auf Git-Repositories verweist. Nils Adermann beschreibt das im Update vom 27. Mai 2026 als bewusste Stärke:

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.

Das ist eine fundamentale Architekturentscheidung. Ein hypothetischer Vollzugriff auf die Server von Packagist.org allein reicht nicht, um Pakete zu vergiften. Bei npm und PyPI, die ihre Artefakte zentral hosten, gibt es diese natürliche Trennung nicht.

Seit Composer 2.2 müssen Plugins explizit über config.allow-plugins autorisiert werden. Wer ein neues Plugin über eine transitive Abhängigkeit hereinbekommt, wird zur Installationszeit gefragt. Bei npm laufen postinstall-Scripts standardmäßig ohne Nachfrage, mit den vollen Rechten des aufrufenden Users. Genau diese Lifecycle-Scripts waren der dominante Angriffsvektor der npm-Angriffe von 2025.

Hinter diesen Eigenschaften steht eine gemeinsame Designphilosophie: Sicherheit als Architekturmerkmal, lange bevor Supply Chain Security zum Schlagwort wurde.

Defensive Defaults: Composer 2.9 und 2.10

Im November 2025 veröffentlichte Jordi Boggiano einen Artikel zu Composer 2.9. Das wichtigste neue Feature steht im in diesem Release Announcement unscheinbar zwischen anderen Änderungen:

Composer now automatically blocks updates to packages with known security advisories. This protection is enabled by default.

Vor Composer 2.9 hat composer audit Security Advisories zwar gemeldet, aber composer update hat betroffene Versionen trotzdem installiert. Seit 2.9 weigert sich der Resolver, Versionen mit bekannten Advisories überhaupt in Betracht zu ziehen. Standardmäßig und bei jeder Auflösung des Abhängigkeitsgraphen. Wie dieser Mechanismus im Detail funktioniert, habe ich in einem eigenen Artikel beschrieben.

Der Vergleich mit anderen Ökosystemen lohnt sich. Bei npm läuft npm audit automatisch bei jedem npm install, warnt aber standardmäßig nur. pip bringt von Haus aus gar keinen Audit mit; pip-audit ist ein separates Werkzeug, das bewusst installiert werden muss. Auch bei RubyGems, crates.io und Maven Central ist ein Audit, der die Auflösung blockiert, nicht Teil des Standard-Workflows und Werkzeuge wie cargo-audit, cargo-deny oder OWASP Dependency-Check sind Opt-in. Composer 2.9 hat hier eine Linie gezogen, die meines Wissens in keinem anderen Mainstream-Ökosystem so klar verläuft.

Zur Veröffentlichung von Composer 2.10.0 haben Stephan Vock und Nils Adermann am 28. Mai 2026 einen Artikel veröffentlicht. Die unscheinbare Versionsnummer täuscht. Das zentrale neue Konzept ist das Dependency Policy Framework: eine einheitliche Konfiguration unter config.policy, die das bisherige config.audit ablöst und in der Composer Security Advisories, abandoned Packages und jetzt auch Malware-Flags nach demselben Schema behandelt. Jede Policy teilt dieselbe Struktur aus block (Entfernung aus dem Resolver-Pool), audit (ignore, report oder fail) und ignore (Ausnahmen pro Paket).

Andrew Nesbitt hat das Modell präzise beschrieben:

uBlock Origin for composer install.

Benannte Filterlisten, die irgendjemand pflegt und unter einer URL veröffentlicht, dazu ein aktives Default-Set und die Möglichkeit, weitere Listen zu abonnieren oder abzubestellen. Was Werbe- und Tracking-Blocker im Browser seit Jahren etabliert haben, kommt damit in den Package Manager.

Die Default-Policies treffen das, was die meisten Projekte wollen:

• Malware wird bei Updates blockiert, lässt Audits fehlschlagen, und wird auch bei composer install blockiert. Das ist der entscheidende Punkt: Eine bösartige Version, die erst nach Erzeugung der composer.lock geflaggt wird, schlägt beim nächsten Install fehl, statt stillschweigend in CI-Läufe oder Production-Deployments einzuziehen. Derselbe Check greift bei composer require und composer create-project.
• Security Advisories werden bei Updates berücksichtigt und lassen Audits fehlschlagen, betroffene Versionen können aber installiert werden. Du bekommst die Chance zu bewerten, ob dich eine veröffentlichte Schwachstelle betrifft, bevor du patchst.
• Abandoned Packages werden nur vom Audit gemeldet, aber nicht blockiert.

Der Malware-Schutz ist für alle Nutzenden von Composer 2.10 standardmäßig aktiv und erfordert für Pakete von Packagist.org keinerlei Konfiguration. Die Datengrundlage liefert Aikido über einen unter CC-BY 4.0 lizenzierten, also offenen Feed.

Einen Punkt arbeitet Nesbitt besonders scharf heraus: malware ist kein reservierter Name. Es ist eine mitgelieferte Liste mit eingebauten Voreinstellungen, aber jeder andere Schlüssel unter config.policy definiert eine eigene Liste mit denselben Optionen. Die Daten dafür können aus einem Composer-Repository kommen, das eine Liste dieses Namens anbietet, aus einem oder mehreren HTTPS-Endpoints unter sources, oder aus beidem kombiniert. Composer schickt die Package URLs der Projekt-Dependencies an jede Quelle und bekommt Filtereinträge im selben Format zurück, das auch Packagist liefert. Aikido ist die Default-Quelle auf Packagist.org, aber mit malware.ignore-source lässt sich diese Quelle abschalten und durch eine andere ersetzen oder ergänzen. Kein Anbieter hat eine Sonderstellung.

Damit können sich eine von der Community gepflegte Typosquat-Liste, die interne „diese Pakete hat Legal noch nicht freigegeben“-Liste einer Organisation oder eine Liste, die niemand kommerziell verkauft, neben die eingebauten Listen einklinken, mit derselben Syntax für Ausnahmen. Ende Mai 2026 enthielt die Summary-Datei von Packagist rund 70 geflaggte Pakete. Das Issue #12786 reserviert bereits license, support, maintenance und minimum-release-age als künftige eingebaute Listennamen, die vermutlich über genau diesen Mechanismus kommen werden statt als separate Features.

Wer das Blocking temporär aussetzen muss, nutzt das neue --no-blocking-Flag oder die Umgebungsvariable COMPOSER_NO_BLOCKING und "policy": false ist der Kill-Switch für alle Policies auf einmal. Das ursprüngliche Feature aus Pull Request #12766 wurde unter der neuen Policy-Konfiguration in Pull Request #12804 konsolidiert. Stephan Vock hat den Großteil der Implementierung sowohl in composer/composer als auch in composer/packagist beigesteuert, finanziert durch die Sovereign Tech Agency und Aikido.

Ebenfalls in 2.10: das Ende der Source Fallbacks. Wenn der Download eines gepackten Dist-Artefakts fehlschlug, zog Composer bisher automatisch das Source Repository als Fallback heran. Das konnte sicherheitsrelevant werden, etwa wenn ein Mirror eine bekanntermaßen saubere Version bereithält, ein Netzwerkfehler aber den Fallback auf einen bösartigen Tag im darunterliegenden Git Repository auslöst. In 2.10 ist dieses Verhalten deprecated und nur noch über die neue source-fallback-Option aktivierbar; in 2.11 soll es entfernt werden.

Unveränderliche Versionen auf Packagist

Begleitend zu den Client-Features sichert eine serverseitige Änderung auf Packagist.org das Fundament ab: Stable Version Immutability, angekündigt im Mai und seit dem 7. Juli 2026 vollständig live. Die Regel ist einfach: Einmal publiziert, ändert sich die Git-Referenz einer stabilen Version nie wieder. Wird der Tag im Source Repository gelöscht, neu erstellt oder auf einen anderen Commit verschoben, behält die publizierte Version ihre ursprüngliche Referenz. Der Retag wird blockiert, eine Warnung erscheint auf der Paketseite, und alle Maintainer werden per E-Mail benachrichtigt.

Das schließt einen Angriffsvektor, den nahezu jeder der jüngsten Packagist-Angriffe genutzt hat: Angreifer mit kompromittiertem GitHub-Zugang überschrieben bestehende, vertrauenswürdige Tags, sodass das nächste composer update der Opfer die bösartige Version einzog. Und weil dies eine serverseitige Änderung ist, schützt sie auch ältere Composer-Clients, die keine Filterlisten verstehen.

Nebenbei löst der Launch-Post ein Missverständnis auf, das auch gutmeinende Maintainer betrifft: Das Muster „schnell den Tag löschen und neu setzen, hat ja noch niemand installiert“ war nie sicher. Automatisierte Systeme reagieren binnen Sekunden auf den Changes-Feed von Packagist. Mirrors cachen das Archiv unter der Original-Referenz. CI-Systeme mit automatischen Dependency-Updates haben die Version womöglich schon in ein Lockfile committet. Adermanns Empfehlung ist entwaffnend pragmatisch: Versionsnummern kosten nichts. Der Fix gehört in die nächste Patch-Version, notfalls als vierte Komponente, aus 3.2.0 wird 3.2.0.1.

Zwei Präzisierungen sind wichtig, um das Feature korrekt einzuordnen. Erstens der Scope: Unveränderlich sind die Versions-Metadaten, also die Zuordnung von Versionsnummer zu Git-Commit. Die heruntergeladenen Archive selbst sind es noch nicht. Für die meisten Pakete generiert die GitHub-API die Zip-Archive on demand und garantiert keine byte-identischen Archive für denselben Commit über die Zeit. Unveränderliche Artefakte sind das erklärte nächste Ziel, geplant „in den nächsten Monaten“ durch eine Kombination aus eigenem Artefakt-Hosting und Verifikationsdaten im Transparency Log.

Zweitens die Löschfrage: Wenn Versionen unveränderlich sind, wie entfernt man eine, die wirklich weg muss, etwa weil ein Release versehentlich Secrets enthielt? Die Antwort ist ein Soft Deletion-Modell mit expliziten Gründen. Statt spurloser Löschung bleibt ein Versionseintrag erhalten, markiert mit dem Grund: nicht mehr im Source Repository vorhanden, vom Maintainer gelöscht, von Admins entfernt oder von Admins versteckt. Er wird ausgegraut auf der Paketseite angezeigt, ist für Composer nicht mehr auflösbar und hat, wo sinnvoll, einen Recover-Button. Jeder kann im Nachhinein nachvollziehen, was mit einer Version passiert ist und warum, statt zu entdecken, dass sie stillschweigend umgeschrieben oder gelöscht wurde.

Das Transparency Log

Das öffentliche Packagist Transparency Log ist seit einigen Monaten live und hat in den jüngsten Angriffen seinen Wert bewiesen. Adermann und Benko schreiben dazu am 27. Mai 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.

Das Log erfasst Ownership-Änderungen, das Hinzufügen und Entfernen von Maintainern, User-Änderungen und Änderungen an Versions-Referenzen. Mit dem Immutability-Launch am 7. Juli 2026 kommen drei weitere Ereignisklassen hinzu: blockierte Retag-Versuche, Soft-Deletions mit Grund und Recoveries. Jede dieser Aktionen hinterlässt einen permanenten öffentlichen Eintrag. Finanziert wurde das Transparency Log von der Sovereign Tech Agency. Darauf kommen wir gleich zurück.

Server-side oder client-side?

Wenn man in andere Ökosysteme schaut, fällt auf: Die meisten Registries behandeln bestätigte Malware serverseitig. PyPI hat seit August 2024 die Project Quarantine: Pakete werden aus dem Simple Index versteckt, sodass pip install sie nicht mehr findet. npm entfernt das Paket und veröffentlicht einen Security Holding-Platzhalter unter demselben Namen. RubyGems und crates.io ziehen die betroffene Version zurück (yank). Hex.pm markiert ein Release als retired, was bei der Auflösung warnt, aber nicht blockiert.

Server-side hat einen eindeutigen Vorteil: Jeder Client bekommt den Schutz automatisch, auch zehn Jahre alte Installationen, die nie aktualisiert werden. Der Nachteil: Die Registry-Betreiber sind die einzige Urteilsinstanz. Auf der Liste steht nur, was sie selbst bereits geprüft und entfernt haben. Ein Sicherheitsanbieter, der etwas vor einer Stunde entdeckt hat, kann einen Blogpost schreiben, sich aber nicht zwischen dich und pip install schalten.

Das Design von Composer trifft die umgekehrte Wahl: Das Paket bleibt mit einer Flag-Markierung auf der Registry, und welche Flags berücksichtigt werden, entscheidet die Client-Konfiguration, einschließlich der Flags von Drittanbietern. Der Preis dafür: Ein Install mit Composer 2.8 zieht eine geflaggte Version unbeanstandet ein, bis Packagist serverseitig nachzieht. Genau hier greifen die serverseitigen Ergänzungen. Stable Version Immutability und das Soft Deletion-Modell erreichen auch ältere Clients, denn soft-gelöschte Versionen verschwinden aus den Metadaten, die jeder Composer liest.

Composer muss sich zwischen beiden Ansätzen nicht entscheiden. Es kombiniert client-seitige Vielfalt der Quellen mit server-seitiger Unveränderlichkeit.

Aikido bietet seine Malware-Erkennung auch für npm an. Dort heißt das Werkzeug Safe Chain, und man muss es bewusst installieren, wie auch Socket safe npm oder die Socket Firewall als lokalen Registry-Proxy. Der Unterschied zwischen Default-on und Opt-in ist erheblich: Opt-in-Schutz erreicht nur die, die ihn kennen und aktivieren. Default-on-Schutz erreicht alle. Dass der Composer-Check auch zur Install-Zeit greift, ist dabei besonders wertvoll: Er schützt nicht nur Entwicklerinnen und Entwickler beim Update, sondern auch jede automatisierte Pipeline, in der niemand mehr aktiv über Dependencies nachdenkt.

Wem gehört unsere Lieferkette?

Wenn wir über Supply Chain Security reden, denken wir an Malware, an kompromittierte Tokens, an Provenance-Signaturen. Wir denken seltener daran, dass jede Package-Registry einen Eigentümer hat. Und dass dieser Eigentümer in Krisensituationen, bei regulatorischen Verschiebungen oder Geschäftsentscheidungen die letzte Instanz ist. Wer Composer und Packagist mit anderen Ökosystemen vergleicht, sollte diese Frage nicht aussparen. Sie ist im Jahr 2026 eine politische geworden.

npm wurde im März 2020 von GitHub übernommen, das seinerseits seit der 7,5-Milliarden-Dollar-Übernahme von 2018 zu Microsoft gehört. Das mit Abstand größte Package-Ökosystem der Welt wird heute auf Microsoft-Infrastruktur betrieben.

PyPI ist im Eigentum der Python Software Foundation, einer 501(c)(3)-Nonprofit nach Delaware-Recht. Die PSF ist strukturell unabhängiger als npm, aber ihre Verletzlichkeit zeigte sich 2025 deutlich. Im Oktober 2025 zog sie ihren Antrag auf einen NSF-Grant über 1,5 Millionen Dollar für die Supply Chain Security von PyPI zurück, obwohl er bereits zur Förderung empfohlen war. Die Förderbedingungen hätten von der PSF die Zusicherung verlangt, keinerlei Programme zu betreiben, die Diversity, Equity und Inclusion fördern; das wäre nach einstimmiger Einschätzung des Boards ein Verrat an ihrer Mission gewesen. Im Januar 2026 sagte Anthropic der PSF 1,5 Millionen Dollar über zwei Jahre zu, unter anderem für genau die PyPI-Sicherheitsarbeit, die der NSF-Grant finanziert hätte. Den Zusammenhang zwischen beiden Ereignissen haben Beobachter hergestellt, nicht die Beteiligten; Betrag, Laufzeit und Projektbeschreibung sind allerdings deckungsgleich. Eine US-Nonprofit, die fundamentale Software-Infrastruktur betreibt, ist von der US-Politik und von US-Unternehmensgeldern abhängiger, als viele europäische Nutzende vermutlich annehmen.

RubyGems wird von Ruby Central betrieben, ebenfalls einer US-501(c)(3)-Nonprofit. Was dort 2025 passiert ist, sollte jeder lesen, der über Registry-Governance nachdenkt. Im August 2025 wurde laut Ruby Centrals eigenem Incident-Report eine Förderzusage über 250.000 Dollar zurückgezogen. Die Firma hinter Sidekiq begründete das später öffentlich mit dem Auftritt von DHH auf der RailsConf 2025. Im September 2025 entzog Ruby Central den langjährigen Maintainern von RubyGems und Bundler die Admin-Rechte und übernahm die Kontrolle über die Projekte. Recherchen aus der Community nennen Druck des Hauptsponsors Shopify als Hintergrund, aber offiziell bestätigt ist das nicht. Die betroffene Maintainerin Ellen Dash nannte den Vorgang einen „hostile takeover“ und trat zurück. Im April 2026 erklärte der Vorstand, Ruby Central befinde sich in „real financial jeopardy“, und trennte sich vom Executive Director, dem CFO und der PR-Agentur. Die früheren Maintainer bauen inzwischen mit gem.coop einen alternativen Gem-Server auf. Die Episode zeigt, wie schnell scheinbar stabile Open Source-Stewardship kollabieren kann.

crates.io ist Eigentum der Rust Foundation, einer Delaware-Nonprofit. Zu den Mitgliedern im Platinum-Tier gehören heute Arm, AWS, Google, Huawei, Meta, Microsoft und OpenAI. Mozilla, 2021 eines der Gründungsmitglieder, ist heute im Silver-Tier. Die Infrastruktur selbst wird durch Sachspenden getragen: das File-Hosting kommt von AWS, das CDN von Fastly. Diese Konstruktion macht Rust leistungsfähig, und sie macht das Ökosystem zugleich stark von einer Handvoll überwiegend amerikanischer Tech-Konzerne abhängig.

Maven Central wird von Sonatype betrieben, einer US-Firma aus Fulton, Maryland. Sonatype ist seit einer Mehrheitsinvestition im November 2019 mehrheitlich im Besitz von Vista Equity Partners, einem amerikanischen Private-Equity-Fonds. Die zentrale Registry des gesamten Java-Ökosystems wird also von einem profitorientierten Private-Equity-Portfolio-Unternehmen kontrolliert.

Composer und Packagist sind ein Sonderfall. Der Composer-Quellcode liegt bei der composer-Organisation auf GitHub. Aber die zentrale öffentliche Registry Packagist.org wird betrieben von der Packagist Conductors GmbH mit Sitz in Berlin, Geschäftsführer sind Nils Adermann und Jordi Boggiano. Das ist die im Impressum verzeichnete Information. Die GmbH finanziert sich über das kommerzielle Produkt Private Packagist, das die Arbeit an der Composer-CLI und den Betrieb von Packagist.org querfinanziert.

Das Update vom 27. Mai 2026 nennt erstmals explizit alle drei Finanzierungsquellen der aktuellen Sicherheitsarbeit: Private Packagist als Hauptträger, dazu die Sovereign Tech Agency und Aikido als externe Förderer. Zudem wird ein neues Sponsoring-Programm für Unternehmen angekündigt.

Ökosystem	Betreiber der zentralen Registry	Rechtsraum
npm	Microsoft (via GitHub)	USA
PyPI	Python Software Foundation	USA
RubyGems	Ruby Central	USA
crates.io	Rust Foundation	USA
Maven Central	Sonatype (Mehrheitseigner: Vista Equity Partners)	USA
Composer/Packagist	Packagist Conductors GmbH	Deutschland

Unter den sechs hier verglichenen Ökosystemen ist Packagist die einzige zentrale Registry, die nicht von einer US-Entität betrieben wird. Im Dezember 2024 ist der Cyber Resilience Act in Kraft getreten, der erstmals die Rolle des Open Source Stewards rechtlich definiert, Artikel 24 regelt dessen Pflichten. Zusammen mit der EU-Diskussion um digitale Souveränität macht das aus dem Berliner Domizil von Packagist Conductors eine Eigenschaft mit praktischer Bedeutung für europäische Unternehmen.

Was die Sovereign Tech Agency hier tut

Die Sovereign Tech Agency ist eine Initiative der deutschen Bundesregierung, 2022 als Sovereign Tech Fund mit Mitteln des Bundeswirtschaftsministeriums gegründet, heute eine Tochtergesellschaft der Bundesagentur für Sprunginnovationen (SPRIND), finanziert vom Bundesministerium für Digitales und Staatsmodernisierung. Ihr Budget wuchs von 11,5 Millionen Euro im Jahr 2023 auf 17 Millionen Euro im Jahr 2024. Die Idee macht Schule: Ein EU-Pendant nach deutschem Vorbild wurde im Juli 2025 in einer Machbarkeitsstudie vorgeschlagen, und die EU-Kommission hat im Juni 2026 in ihrer Open Source-Strategie ein eigenes Förderinstrument für die Pflege kritischer Open Source-Komponenten angekündigt. Die Mission ist explizit: Open Source-Infrastruktur, von der Europa abhängt, durch öffentliche Mittel absichern, ohne sie unter staatliche Kontrolle zu stellen.

Konkret hat die Sovereign Tech Agency das Packagist Transparency Log finanziert, jenes Werkzeug, das bei den Angriffen vom April und Mai 2026 die forensische Aufklärung ermöglicht hat, sowie Teile der Filterlisten-Arbeit in Composer 2.10. Die nächste geförderte Phase ist die Arbeit an organisatorischer Package Ownership. Mir ist kein anderes Mainstream Package-Ökosystem bekannt, das eine vergleichbare Konstellation aus europäischem Betreiber, kommerzieller Quersubventionierung und staatlicher Förderung durch eine demokratisch legitimierte Souveränitäts-Initiative hat.

Souveränität ist nicht alles

Eine Berliner GmbH kann insolvent werden. Deutsche Staatsförderung kann gekürzt werden. Eine Foundation-Struktur wie bei Rust oder Python hat gegenüber einer GmbH den Vorteil größerer Governance-Robustheit. Und Sonatype betreibt Maven Central trotz Private Equity-Eigentümer seit vielen Jahren zuverlässig. Eigentum allein bestimmt nicht das Verhalten.

Aber das Jahr 2026 sieht so aus: Eine US-Regierung knüpft politische Bedingungen an Forschungsförderung (siehe PSF). Ein Konzern übt Berichten zufolge Druck auf eine US-Nonprofit aus, kritische Open Source-Repositories zu übernehmen (siehe Ruby Central). Und die EU begreift digitale Souveränität endlich auch als wirtschaftspolitische Notwendigkeit. In dieser Lage ist es relevant, dass eine Berliner GmbH die zentrale Registry eines Ökosystems betreibt, dessen Sprache einen erheblichen Teil des Webs antreibt.

Das ist nicht der wichtigste Aspekt der Composer-Bilanz. Aber es ist einer, den die PHP-Community nicht kleinreden sollte. Und einer, für den Nils Adermann, Jordi Boggiano und ihre Mitstreiter eigene Anerkennung verdienen.

Wofür wir dankbar sein dürfen

Diese Arbeit ist über Jahre hinweg unterbezahlt und weitgehend unsichtbar geleistet worden. Deshalb möchte ich an dieser Stelle Namen nennen.

Nils Adermann hat als Mitgründer von Packagist Architekturentscheidungen getroffen, die unser Ökosystem heute schützen. Sein Artikel von 2021 zu Dependency Confusion ist nicht nur eine technische Antwort, sondern ein Lehrstück darüber, wie ein Maintainer mit ruhiger Klarheit erklärt, warum seine Plattform anders gebaut wurde. Das umfassende Roadmap-Update vom 27. Mai 2026, das er gemeinsam mit Igor Benko verfasst hat, ist eine ungewöhnlich offene und detaillierte Selbstverpflichtung für die nächsten Jahre.

Jordi Boggiano hat Composer über mehr als ein Jahrzehnt als Maintainer geführt. Wer einmal Open Source-Projekte dieser Größenordnung betrieben hat, weiß, was das bedeutet: tausende Issues, hunderte Pull Requests, unzählige Edge Cases im Versions-Resolver, und nebenbei jeden Sicherheitsvorfall ernsthaft adressieren. Der Release-Post zu Composer 2.9 trägt seinen Namen. Ohne diese Arbeit gäbe es kein Automatic Security Blocking.

Stephan Vock hat das Malware Filter-Feature maßgeblich implementiert und das Release von Composer 2.10 gemeinsam mit Nils Adermann verantwortet. Sein Beitrag wirkt seit dem 28. Mai 2026 in produktiven PHP-Workflows weltweit.

Die Packagist Conductors GmbH finanziert über kommerzielle Subscriptions von Private Packagist einen erheblichen Teil der Arbeit am freien Composer und den Betrieb von Packagist.org. Das Team reagiert laut eigenem Bericht „innerhalb von Minuten“ auf erkannte Vorfälle. Das ist eines der wenigen Geschäftsmodelle in der Open Source-Welt, das Sicherheitsarbeit am Public Good direkt aus dem kommerziellen Produkt heraus bezahlt. Und es hält die öffentliche Registry-Infrastruktur des PHP-Ökosystems in europäischer Hand.

Die Sovereign Tech Agency hat verstanden, dass kritische Open Source-Infrastruktur Finanzierung braucht, bevor sie kollabiert oder kompromittiert wird. Dass deutsche Steuergelder in die Sicherheit eines weltweit genutzten Package-Ökosystems fließen, ist eine bemerkenswerte und gute Entwicklung.

Aikido stellt den Malware-Feed bereit, der seit März 2026 in Packagist integriert ist. Der Feed ist unter CC-BY 4.0 lizenziert und damit offen, und die Integration bleibt für weitere Datenanbieter mit passenden Lizenzen offen. Ein Multi Source-Ansatz, der die Plattform nicht von einem einzelnen Anbieter abhängig macht. Mit dem Release von Composer 2.10 ist Aikido zudem finanzieller Sponsor von Composer und Packagist.org geworden, also nicht nur Datenlieferant, sondern auch Mitfinanzier des laufenden Betriebs.

Wenn du heute composer install aufrufst und keinen Gedanken an Supply Chain Security verschwendest, weil im Hintergrund standardmäßig Versionen mit bekannten Schwachstellen blockiert werden, weil mit Composer 2.10 auch Malware aus deinem Dependency Tree ferngehalten wird und weil ein Berliner Team auch nachts auf Vorfälle reagiert, dann arbeitet eine Handvoll Menschen dafür, dass dein Tag normal verläuft. Das darf man ruhig einmal aussprechen.

Was wir von anderen Ökosystemen lernen

Jetzt zum unbequemen Teil. In einem zentralen Bereich der Supply Chain Security hatte Composer/Packagist bis zum 27. Mai 2026 Aufholbedarf: kryptographische Provenance und Identity Verification. Der Roadmap-Post schließt diese Lücke nicht, aber er benennt konkret, wie sie geschlossen werden soll. Schauen wir, was die anderen Ökosysteme haben, und stellen es dem Plan gegenüber.

PyPI: der Pionier des modernen Identity Stacks

PyPI hat im April 2023 das Konzept des Trusted Publishing über OpenID Connect eingeführt. Statt langlebige API-Tokens in CI-Systemen zu speichern, die geleakt, gestohlen oder versehentlich exfiltriert werden können, authentifiziert sich der Build-Job direkt gegenüber PyPI über kurzlebige OIDC-Tokens des Identity Providers. Im November 2024 wurden die Sigstore-basierten Attestations nach PEP 740 allgemein verfügbar und bei Trusted Publishing über die offizielle GitHub Action sind sie standardmäßig aktiv. Seit dem 1. Januar 2024 gilt mandatorisches 2FA für alle Maintainer.

Was bei Composer/Packagist dazu auf der Roadmap steht: Mandatory MFA als langfristiges Ziel, mit FIDO2-Support. Die ersten Schritte sollen in etwa sechs Monaten beginnen: MFA-Ereignisse werden im Transparency Log sichtbar, der MFA-Status erscheint auf Maintainer-Profilen. Trusted Publishing über OIDC wird explizit als Element der langfristigen Architektur genannt. SLSA Build Provenance und Sigstore-Attestations, client-seitig durch Composer verifiziert, sind Teil der Vision einer Zukunft, in der Packagist.org unveränderliche Build-Artefakte direkt hostet. Das wird dauern. Aber aus einer offenen Lücke ist ein Plan geworden, mit explizitem Bezug auf die OpenSSF-Prinzipien und den SLSA Dependency Track. Diese Selbstverpflichtung auf externe Standards ist neu.

Maven Central: hohe Hürden beim Publishing

Wer in der Java-Welt ein Paket auf Maven Central veröffentlichen will, durchläuft einen Prozess, der strenger ist als in jedem anderen hier diskutierten Ökosystem: eine Reverse-Domain-groupId mit Namespace-Verifikation per DNS oder Code-Hosting-Account, eine verpflichtende GPG-Signatur aller Artefakte und ein Staging Workflow mit serverseitiger Validierung.

Die Position von Composer/Packagist dazu: Adermann formuliert im Update vom 27. Mai 2026 die Vision, dass Packagist.org langfristig unveränderliche Build-Artefakte direkt hostet, mit SLSA-Provenance und Sigstore-Attestations. Das wäre ein tiefer Eingriff in die Architektur, denn heute liegt die Stärke von Composer gerade in der Trennung zwischen Metadaten-Index und Code Repository. Der erste Baustein ist seit dem 7. Juli 2026 gesetzt: Die Versions-Metadaten sind unveränderlich. Der Launch-Post konkretisiert den nächsten Schritt, unveränderliche Artefakte „in den nächsten Monaten“, durch eigenes Artefakt-Hosting kombiniert mit Verifikationsdaten im Transparency Log. Die Richtung steht, geliefert wird in Etappen.

crates.io: kollaboratives Auditing als alternativer Weg

Die Rust-Community hat mit cargo-vet ein Framework für kollaboratives Auditing etabliert. Mozilla auditiert Crates für Firefox, Google auditiert Crates für ChromeOS und Fuchsia, und beide veröffentlichen ihre Audits, sodass andere Projekte sie importieren können. In Projekten, die cargo-vet einsetzen, muss jedes Crate in der Cargo.lock durch einen lokalen oder importierten Audit-Eintrag gedeckt sein. Alles, was nicht auditiert wurde, lässt den Build fehlschlagen.

Andrew Nesbitt macht einen Tag nach dem Release von Composer 2.10 die vielleicht wichtigste Beobachtung zur neuen Architektur: Composers Wire-Format unterstützt bereits Allowlist-Semantik. Eine Abbildung von Paketen auf Versions-Constraints beschreibt erlaubte Versionen genauso gut wie verbotene; der Unterschied liegt nur darin, ob der Client die Treffer verwirft oder alles andere. Eine Composer-Liste im Allow-Modus, gespeist von einer community-publizierten „diese Pakete hat tatsächlich jemand gelesen“-Datenquelle, würde PHP das föderierte Audit-Modell geben, das cargo-vet bei Rust etabliert hat. Die reservierten künftigen Listennamen license, support und maintenance deuten ohnehin auf Allow-Semantik hin, denn Lizenz-Policies sind fast immer eine Liste erlaubter SPDX-Identifier.

cargo-vet ist bislang das einzige etablierte kollaborative Auditing-Framework in den großen Ökosystemen, aber Composers Plattform-Design hat den Mechanismus dafür mitgeliefert. Es braucht jetzt Communities, die anfangen, Audit-Feeds zu publizieren. Die Maintainer von Symfony könnten ihre internen Reviews öffentlich machen, sodass Laravel-Projekte sie konsumieren, und umgekehrt. Die Infrastruktur dafür ist seit dem 28. Mai 2026 da.

npm: auch der Verfolger lernt schnell

Es wäre falsch, npm trotz der katastrophalen Sicherheitslage von 2025 abzuschreiben. Die Reaktion war substantiell. Trusted Publishing mit OIDC wurde im Juli 2025 allgemein verfügbar. Am 22. September 2025, direkt nach Shai-Hulud, kündigte GitHub einen Sicherheits-Fahrplan für npm an: verpflichtende 2FA ohne Bypass-Möglichkeit für das lokale Publishing, FIDO statt TOTP, granulare Publishing-Tokens mit maximal sieben Tagen Laufzeit und das Ende der klassischen Tokens. Seit npm 11.10.0 unterstützt der Client mit min-release-age ein konfigurierbares Mindestalter für Releases, als Opt-in. Und am 22. Mai 2026 hat npm Staged Publishing eingeführt: eine zweistufige Veröffentlichung, bei der ein hochgeladenes Release erst installierbar wird, nachdem ein Mensch es mit einer 2FA-Challenge freigegeben hat.

Was Composer/Packagist dazu auf der Roadmap hat: genau dieses Feature. Ein Staged Release Flow mit FIDO2-Bestätigung, verpflichtend für Pakete mit großer Userbase. Hier holt das PHP-Ökosystem also nur auf. Aber es hat sich erklärtermaßen dasselbe Ziel gesetzt.

Auch minimum-release-age ist nicht mehr nur das offene Issue #12847. Es ist laut dem Update vom 27. Mai 2026 die erste designierte Folge-Policy nach dem Dependency Policy Framework aus 2.10. Adermann bezeichnet sie als eine der wirksamsten Verteidigungen gegen die jüngste Angriffsklasse, weil bösartige Versionen typischerweise innerhalb von Stunden nach der Publikation eingezogen oder erkannt werden. Sie war durch Vorarbeit auf der Packagist-Seite blockiert: Release-Metadaten müssen zuverlässig unveränderlich sein, bevor der Publikationszeitpunkt als Sicherheits-Input taugt. Mit der am 7. Juli 2026 live gegangenen Version Immutability ist diese Vorbedingung erfüllt.

Wie wichtig das ist, zeigt Nesbitts Bestandsaufnahme: pnpm, Yarn, Bun, npm, uv, pip und Poetry haben alle innerhalb der letzten zwölf Monate Cooldown-Mechanismen eingeführt. PHP ist hier Nachzügler. Nesbitt betont zudem, dass Cooldown und Filterlisten einander ergänzen. Ein Cooldown blockiert alles, was in den letzten N Tagen erschienen ist, unter der Annahme, dass Bösartiges meist innerhalb dieses Fensters entdeckt wird. Eine Filterliste benennt spezifische Versionen und ist nur so gut wie die Latenz derer, die sie pflegen. Eine vernünftige Konfiguration ist ein kurzer Cooldown plus eine Malware-Liste für alles, was durchschlüpft. Diese Kombination steht Composer bevor, und beide Bausteine sitzen im selben config.policy-Block.

RubyGems: Malware-Scan beim Upload

Eine Eigenheit von RubyGems: Jeder Gem-Upload wird automatisch durchleuchtet, mit statischer und dynamischer Code-Analyse, Behavioral Checks und Metadaten-Review. Hohe Risk-Scores eskalieren zu manuellem Review.

Packagist hostet keinen Code und kann ihn beim Publizieren daher auch nicht scannen. Das ist die Kehrseite der Architektur ohne zentrales Code-Hosting. Diese Lücke wird mit Composer 2.10 über externe Feeds auf der Resolver-Seite geschlossen. Sollte Packagist.org langfristig unveränderliche Artefakte direkt hosten, würde sich diese Asymmetrie ändern.

Vier Beobachtungen zur Roadmap

Wenn wir die Roadmap vom 27. Mai 2026, das Release von Composer 2.10 sowie die seither erschienenen Updates ernst nehmen, ergeben sich vier Beobachtungen.

Erstens: Der Plan ist erstaunlich vollständig. Praktisch jedes Feature, das in anderen Ökosystemen als Best Practice etabliert ist und Composer/Packagist heute fehlt, steht explizit auf der Roadmap: Mandatory MFA, FIDO2, Trusted Publishing über OIDC, SLSA-Provenance, Sigstore-Attestations, Staged Releases, minimum-release-age. Als Zielstandards benennt das Update die OpenSSF Principles for Package Repository Security (Authorization Level 3) und den SLSA Dependency Track (Level 3/4). Das ist keine vage Absichtserklärung mehr.

Zweitens: Die Reihenfolge ist sequenziell aufgebaut, und sie wird eingehalten. Version Immutability, angekündigt im Mai und geliefert am 7. Juli, ist die Voraussetzung für minimum-release-age. Das Dependency Policy Framework in 2.10 ist die Architektur, in der weitere Policies landen. Das Transparency Log war die Voraussetzung dafür, dass blockierte Retags und Soft-Deletions jetzt öffentlich protokolliert werden; genau das ist mit dem Juli-Launch eingetreten. Die Unveränderlichkeit von Metadaten ist wiederum die Voraussetzung für die Unveränderlichkeit von Artefakten, die als nächster Schritt angekündigt ist. Und organisatorische Package Ownership ist die Voraussetzung für sinnvolles mandatorisches MFA in großen Open Source-Projekten wie Symfony oder in Unternehmen. Der Plan ist technisch schlüssig, und die ersten Meilensteine wurden termingerecht abgeliefert.

Drittens: Die Zeitachse bleibt der offene Punkt, und die Finanzierung ist der Engpass. Adermann und Benko vermeiden konkrete Termine für die größten Schritte, also Mandatory MFA, Trusted Publishing und Sigstore. Das ist ehrlich, und die termingerechte Lieferung der Version Immutability im Juli stärkt das Vertrauen in die Zusagen. Aber der Launch-Post zur Immutability enthält einen Satz, den die PHP-Community nicht überlesen sollte: Es werden dringend zusätzliche Unternehmens-Sponsoren gesucht, um diese Arbeit voranzutreiben. Die Arbeit an Immutable Artifacts, dem nächsten großen Meilenstein, hängt explizit an zusätzlicher Finanzierung. Wer als Unternehmen auf Composer baut, hat hier eine sehr konkrete Möglichkeit, die eigene Lieferkette abzusichern: sponsoring@packagist.org.

Viertens, und das weist über Composer hinaus: Andrew Nesbitt hat in den letzten Monaten dokumentiert, wie fragmentiert die Policy-Formate der verschiedenen Package Manager sind. Composers Wire-Protokoll, Package URLs als Input und Filtereinträge als Output, ist nach seiner Einschätzung ein vielversprechender Kandidat für das ökosystemübergreifende Standard-Format, das er gesucht hatte. Seine Schlussbemerkung:

I'd like to see more package managers copy this wholesale.

Von jemandem, der die Landschaft der Package Manager so gut überblickt wie kaum ein anderer, hat dieser Satz Gewicht. Wenn das Modell von Composer 2.10 in den nächsten Monaten von pnpm, npm, pip oder Cargo aufgegriffen wird, dann ist PHP an einer Stelle Vorreiter, an der es lange Nachzügler war.

Bilanz

Composer und Packagist haben 2025 und 2026 mit Composer 2.9, Composer 2.10 und der im Juli gelieferten Version Immutability bewiesen, dass das Team die Bedrohungslage versteht, entschlossen handelt und angekündigte Meilensteine tatsächlich abliefert. Auf der einen Seite stehen die strukturellen Designentscheidungen der Anfangszeit: Vendor-Namespaces, kanonische Repositories, keine zentrale Code-Distribution, direkte Bindung an die Source. Auf der anderen Seite die jüngsten defensiven Defaults: Security Blocking, Malware-Filter auch zur Install-Zeit, unveränderliche Versions-Metadaten mit Soft-Deletion und Transparency-Log-Protokollierung. Zusammen ergibt das einen Schutz, der für gewöhnliche PHP-Workflows ohne Sicherheitsexpertise robuster ist als in fast jedem anderen Ökosystem.

Hinzu kommt die Eigentumsstruktur: Mit der Packagist Conductors GmbH als europäischem Betreiber und der Sovereign Tech Agency als öffentlicher Begleitfinanzierung steht die PHP-Lieferkette in einer Konstellation, die im internationalen Vergleich heraussticht und im Kontext der EU-Souveränitätsdebatte praktische Bedeutung hat. Das ist eine echte Leistung, auf die das Composer-Team stolz sein darf und für die wir als Community Anerkennung schulden.

Gleichzeitig liegt vor uns die Arbeit an Trusted Publishing, Sigstore-Provenance, mandatorischem MFA, Cooldown-Mechanismen und SLSA-konformen Build-Artefakten. PyPI, npm und Maven Central laufen hier in unterschiedlichen Konstellationen voraus. Aber anders als noch vor wenigen Wochen ist nicht mehr offen, ob die PHP-Welt diese Lücken schließen will, sondern nur noch, wie schnell sie es kann.

Und es gibt einen ersten Schritt, den jede Maintainerin und jeder Maintainer heute tun kann. Adermann formuliert ihn im Update direkt:

If you maintain any package on Packagist.org and don't have MFA enabled, please enable it now.

Die vier wichtigsten Quellen für diesen Artikel sind „An Update on Composer & Packagist Supply Chain Security“ von Nils Adermann und Igor Benko (27. Mai 2026), der Release-Post zu Composer 2.10 von Stephan Vock und Nils Adermann (28. Mai 2026), „Composer's dependency policies“ von Andrew Nesbitt (29. Mai 2026) sowie „Immutable Versions on Packagist“ von Nils Adermann (7. Juli 2026). Alle weiteren Quellen sind an der jeweiligen Stelle im Text verlinkt.