Kaum eine PHP-Anwendung kommt ohne fremde Bibliotheken aus, etwa für E-Mail-Versand, PDF-Erzeugung oder ganze Frameworks wie Laravel. Composer, oft als Paketmanager für PHP bezeichnet, übernimmt das Einbinden dieser Pakete. Anders als Paketverwaltungen von Betriebssystemen arbeitet Composer je Projekt: Die Pakete landen im Ordner vendor des jeweiligen Projekts. Standardquelle ist das öffentliche Verzeichnis Packagist, zusätzlich lassen sich eigene oder private Paketquellen einbinden.
Wie Composer funktioniert
- composer.json: Hier steht, welche Pakete ein Projekt braucht und in welchen Versionen. Versionsangaben wie
^3.2erlauben kompatible Aktualisierungen. Viele Pakete folgen dafür der Semantischen Versionierung, bei der eine neue Hauptversion inkompatible Änderungen ankündigt. - composer.lock: Nach der Auflösung hält Composer die exakt installierten Versionen aller Pakete fest, einschließlich der indirekten Abhängigkeiten. Laut Dokumentation sollte diese Datei ins Repository, damit alle Beteiligten, die CI/CD-Pipeline und der Produktivserver dieselben Versionen verwenden.
- vendor: Der Ordner mit dem fremden Code gehört dagegen nicht in die Versionsverwaltung. Er entsteht bei jeder Installation neu.
- Autoloading: Composer erzeugt eine Datei, über die PHP Klassen der Pakete automatisch findet.
Der Unterschied zwischen den zentralen Befehlen ist wichtig: composer install installiert genau die Versionen aus der Lock-Datei. composer update löst die Abhängigkeiten neu auf, holt neuere passende Versionen und schreibt die Lock-Datei neu.
Wichtige Befehle
composer require anbieter/paketnimmt ein Paket auf.composer install --no-devinstalliert für den Produktivbetrieb ohne Entwicklungswerkzeuge.composer update anbieter/paketaktualisiert gezielt ein einzelnes Paket.composer outdatedzeigt, welche Pakete neuere Versionen haben.composer auditprüft die installierten Pakete auf bekannte Sicherheitslücken.
Sicherheit in der Software-Lieferkette
Jedes Paket ist Code von Dritten, der mit den Rechten der Anwendung läuft. Composer bietet dafür mehrere Hilfen:
- composer audit: Laut Dokumentation gleicht der Befehl die Pakete standardmäßig über die Packagist-API mit Sicherheitshinweisen ab und meldet zusätzlich aufgegebene Pakete. Bei Treffern endet er mit Fehlercode, was ihn als automatische Prüfung in einer Pipeline geeignet macht. Mit
--lockedwird die Lock-Datei statt des vendor-Ordners geprüft. - allow-plugins: Composer-Plugins können während eines Composer-Laufs Code ausführen. Seit Composer 2.2 legt die Einstellung
allow-pluginsfest, welche Plugins das dürfen. Ohne Eintrag wird kein Plugin geladen. - Lock-Datei prüfen: Änderungen an composer.lock im Code Review ansehen. Neue Pakete und unerwartete Quellen fallen so auf.
Zusätzlich gilt:
- Neue Pakete vor der Aufnahme bewerten: Wer pflegt sie, wie aktiv ist das Projekt, wie viele weitere Abhängigkeiten bringt es mit?
- Auf Tippfehler bei Paketnamen achten, denn ähnlich klingende Namen sind ein bekannter Angriffsweg.
- Zugangsdaten für private Paketquellen nicht ins Repository legen.
- Regelmäßig aktualisieren, statt Updates zu sammeln. Kleine Schritte lassen sich leichter testen.
- Gefundene Lücken im Schwachstellenmanagement nachverfolgen.
Typische Einsatzbeispiele
- Ein Webshop bindet Zahlungs- und Versandmodule als Pakete ein und aktualisiert sie gezielt.
- Eine Pipeline führt bei jedem Pull Request
composer auditaus und stoppt bei bekannten Lücken. - Vor einem PHP-Upgrade zeigt Composer, welche Pakete die neue Version noch nicht unterstützen, siehe PHP End of Life.
Abgrenzung
Composer verwaltet PHP-Bibliotheken auf Projektebene. PHP-Erweiterungen, die in C geschrieben sind und den Interpreter selbst erweitern, werden dagegen über das Betriebssystem oder PECL installiert. Für JavaScript erfüllt npm eine ähnliche Aufgabe wie Composer. Git versioniert den eigenen Code, Composer die fremden Bausteine.
Häufige Fragen
Wie oft sollten Abhängigkeiten aktualisiert werden?
Sicherheitsupdates so bald wie möglich, sobald composer audit oder ein Sicherheitshinweis sie meldet. Für alle übrigen Aktualisierungen hat sich ein fester Rhythmus bewährt, etwa monatlich, damit sich Änderungen nicht über Jahre stauen und ein großes, schwer testbares Paket entsteht.
Was tun, wenn composer audit eine Lücke meldet?
Zuerst den Hinweis lesen: Welche Versionen sind betroffen, und nutzt die eigene Anwendung die betroffene Funktion? Danach das Paket gezielt aktualisieren, testen und ausliefern. Ist kein Update verfügbar, die Lücke mit Begründung und Ersatzmaßnahme dokumentieren und regelmäßig erneut prüfen.
Darf Composer auf dem Produktivserver laufen?
Üblich ist, Abhängigkeiten in der Pipeline zu installieren und das fertige Paket auszuliefern. Wird Composer doch auf dem Server ausgeführt, dann mit composer install --no-dev auf Basis der geprüften Lock-Datei und nie mit composer update.