PHP Supply Chain Security: Composer und Packagist machen den nächsten Schritt

Die letzten Wochen haben gezeigt, wie verwundbar auch das PHP-Ökosystem gegenüber Angriffen auf die Software-Lieferkette ist. Lange galt Supply Chain Security vor allem als NPM-Problem. Wer die jüngsten Vorfälle rund um laravel-lang (22. Mai) und intercom/intercom-php (30. April) verfolgt hat, weiß: PHP ist nicht weniger betroffen – wir haben es nur seltener auf dem Radar.

In beiden Fällen haben Angreifer kompromittierte GitHub-Accounts oder gestohlene Access-Tokens genutzt, um schadhafte Git-Tags auf Paketen zu veröffentlichen, auf die sie keinen legitimen Zugriff hatten. Das Ergebnis: Schadcode in weit verbreiteten Paketen, der bei einem composer update auf tausenden Systemen landet.

Das Packagist-Team hat jetzt in einem ausführlichen Blog-Post dargelegt, was bereits aktiv ist, was diese Woche ausgeliefert wird und wohin die Reise langfristig geht. Die Roadmap ist beeindruckend – und zeigt, dass hier seit fast einem Jahr konsequent an der Infrastruktur gearbeitet wird.

Was bereits funktioniert

Seit März 2026 ist Aikido-Malware-Erkennung direkt in Packagist.org integriert. Wenn eine Version als schädlich markiert wird, erscheint das sowohl in der Packagist-UI als auch in den Metadaten, die Composer abruft. In den jüngsten Vorfällen hat Aikido die kompromittierten Versionen korrekt geflagged.

Parallel dazu gibt es bereits ein öffentliches Transparenz-Log auf Packagist.org. Dieses Log zeichnet sicherheitsrelevante Ereignisse auf: Eigentümerwechsel, Maintainer-Änderungen, Versionsreferenz-Änderungen. Bei den aktuellen Angriffen – bei denen Angreifer bestehende Git-Tags im Nachhinein manipulierten – hat das Log genau das dokumentiert, was verändert wurde. Das ist solide forensische Infrastruktur.

Was diese Woche kommt: Composer 2.10

Das ist der Teil, der mich am meisten interessiert – und der unmittelbaren Handlungsbedarf schafft.

Unveränderlichkeit stabiler Versionen ist die wichtigste Änderung. Bisher konnte ein Angreifer (oder ein unvorsichtiger Maintainer) ein bestehendes Git-Tag einfach neu setzen – und Packagist aktualisierte die Referenz stillschweigend. Das ist vorbei. Ab diesem Deploy können stabile Versionen nicht mehr lautlos überschrieben werden. Tag-Änderungen am Upstream-Repository werden erkannt und abgelehnt; der Maintainer bekommt eine E-Mail-Benachrichtigung.

Das klingt wie eine Kleinigkeit, ist es aber nicht. Mutable Releases bedeuten: Ein kompromittierter Account kann eine bereits millionenfach installierte, als vertrauenswürdig eingestufte Version mit Backdoor versehen. Wer dann composer update ausführt, bekommt den manipulierten Code, ohne Warnung, ohne Versionsnummernänderung. Diese Angriffsfläche wird jetzt geschlossen.

Composer 2.10 führt außerdem ein einheitliches Dependency Policy Framework ein. Malware-Flags, Sicherheitswarnungen und verwaiste Pakete werden damit über einen gemeinsamen, konfigurierbaren Mechanismus gesteuert statt als Einzelfeatures übereinander gestapelt. Das ist die richtige Architekturentscheidung, weil es einen klaren Erweiterungspunkt für künftige Policies schafft.

Der Source-Fallback wird deprecated und in Version 2.11 komplett entfernt. Bisher konnte Composer bei einem fehlgeschlagenen Dist-Download auf das Git-Repository als Quelle zurückfallen. Das ist ein Verhalten, das in bestimmten Angriffsszenarien zu unerwartetem Code-Download führen konnte. Gut, dass das weg kommt.

Was folgt: Cooldown-Phasen und MFA-Sichtbarkeit

Zwei geplante Features, die ich für besonders wirksam halte:

Minimum Release Age: Eine Policy, die verhindert, dass brandneue Releases sofort in CI/CD-Pipelines installiert werden. Die meisten eingeschleusten schädlichen Versionen werden innerhalb von Stunden entdeckt und entfernt. Wer einen Cooldown von z.B. 24 Stunden erzwingt, nimmt Angreifern das entscheidende Zeitfenster. Diese Policy ist direkt abhängig von der oben beschriebenen Versions-Unveränderlichkeit – deswegen kam sie noch nicht, kommt aber bald.

MFA-Status wird öffentlich sichtbar: Künftig wird der MFA-Status von Maintainern auf ihren Profilen und im Transparenz-Log erscheinen. Das erzeugt sozialen Druck was ich für einen wirkungsvollen Hebel halte. Wer als Maintainer eines viel genutzten Pakets ohne 2FA dasteht, wird das merken.

Was mich dazu bewogen hat, heute zu handeln

Ich pflege mehrere Pakete auf Packagist.org, unter anderem n98-magerun2. Ich habe heute meinen Packagist-Account mit 2FA abgesichert.. Ehrlich gesagt hatte ich das gar nicht auf dem Schirm. Aber lieber spät als gar nicht.

Nicht weil es mich jemand gezwungen hat. Sondern weil mir beim Lesen des Packagist-Blog-Posts klar wurde: Das ist keine hypothetische Bedrohung mehr. Die Vorfälle sind real, die Angriffsvektoren sind dokumentiert, und die Konsequenzen eines kompromittierten Accounts treffen nicht nur mich – sondern alle, die das Tool nutzen.

Wer noch keinen guten Passwortmanager nutzt, sollte das ohnehin ändern. Tools wie 1Password, Bitwarden oder KeePassXC unterstützen heute alle TOTP-basiertes 2FA direkt – kein separates Authenticator-App-Chaos nötig. Ein Passwortmanager, der 2FA abdeckt, senkt die Hürde zur Aktivierung auf nahezu null. Es gibt keine sinnvolle Ausrede mehr.

Vertrauen ist eine Währung. Wer ein weit genutztes Open-Source-Paket pflegt, trägt Mitverantwortung für die Sicherheit der Systeme, auf denen es läuft. Das geht nicht an jemand anderen weiter. Nicht an Packagist, nicht an Composer, nicht an GitHub.

Was ich jedem Maintainer empfehle

1. 2FA auf Packagist.org aktivieren – jetzt. Der MFA-Status wird bald öffentlich einsehbar sein. Wer jetzt handelt, tut das aus Überzeugung und nicht aus Druck.

2. Composer auf 2.10 aktualisieren, sobald die Version veröffentlicht ist. Das Source-Fallback-Verhalten allein ist ein guter Grund.

3. Keine shared Company Accounts für Pakete nutzen. Das Packagist-Team baut gerade Organizational Package Ownership, um diesen Übergang zu erleichtern.

4. Das Transparenz-Log kennen. Wer Pakete pflegt oder nutzt, sollte wissen, dass dort Änderungen protokolliert werden – und ab wann auch MFA-Ereignisse.

Einordnung: Ein Ökosystem zieht die Schrauben an

NPM hatte obligatorisches 2FA für beliebte Pakete bereits früher eingeführt, PyPI machte es im Januar 2024 für alle Maintainer verpflichtend. Das Packagist-Team sagt selbst, dass Composer hier punktuell hinterherhinkt – aber die jetzt angekündigte Roadmap ist keine Ad-hoc-Reaktion. Versions-Unveränderlichkeit, ein Dependency Policy Framework, FIDO2-gestützte Release-Flows, SLSA-Provenance – das ist erkennbar über Monate geplante Arbeit. Die Sovereign Tech Agency hat Teile davon mitfinanziert, was zeigt, dass kritische Open-Source-Infrastruktur inzwischen als schützenswert gilt.

KI hat hier übrigens Dynamik in beide Richtungen gebracht. Automatisierte Analyse hilft beim Erkennen von Anomalien – aber sie senkt auch die Hürde für Angreifer, überzeugende schädliche Commits zu erstellen. Das Wettrüsten ist real.

Was von uns als Community bleibt: unseren Teil tun. Und der beginnt mit dem Aktivieren von 2FA. Das dauert fünf Minuten.