Der größte Teil Ihrer PHP-Anwendung stammt von Leuten, die Sie nicht kennen. Er kommt als Paket über Composer und wird bei jeder Installation mitgeliefert. Das ist normal und richtig so, niemand schreibt PDF-Erzeugung oder Verschlüsselung selbst. Es wirft aber drei Fragen auf, die oft erst gestellt werden, wenn ein Kunde, ein Auditor oder ein Vorfall dazu zwingt.
Haben Sie Ihre Abhängigkeiten im Griff?
Machen Sie die Probe. In der composer.json steht, was jemand bewusst eingebunden hat, meist ein bis zwei Dutzend Pakete. In der composer.lock steht, was tatsächlich installiert wird, und das sind schnell über hundert. Die Differenz hat niemand im Unternehmen ausgewählt. Sie kommt mit, weil jedes Paket eigene Abhängigkeiten hat und die wiederum ihre.
Was in dieser Differenz steckt, zeigt ein Beispiel. Polyfills rüsten Funktionen neuerer PHP-Versionen für ältere nach oder springen ein, falls dem Server eine PHP-Erweiterung fehlt. Läuft Ihre Anwendung auf PHP 8.3 mit allen üblichen Erweiterungen, hat ein Polyfill für Funktionen aus PHP 7.2 dort keine Aufgabe mehr. Installiert wird er trotzdem, weil eine Bibliothek drei Ebenen tiefer ihn noch verlangt. Für sich genommen ist das harmlos. Es zeigt aber, dass Code auf Ihrem Server landet, den die Anwendung nicht braucht und nach dem niemand gefragt hat.
Das Risiko steckt in der Menge. Jedes Paket hängt an mindestens einem Entwicklerkonto, und ein gekapertes Konto reicht, um Schadcode an alle auszuliefern, die das Paket beim nächsten Update beziehen. In der JavaScript-Welt ist das 2025 mehrfach mit weit verbreiteten npm-Paketen passiert. Composer-Projekte sind nach demselben Prinzip gebaut.
Im Griff haben Sie Ihre Abhängigkeiten, wenn vier Dinge zutreffen:
- Sie können die Liste aller Pakete heute vorlegen (
composer show --tree) und für jedes sagen, wer es verlangt (composer why paketname). - Bekannte Sicherheitslücken und aufgegebene Pakete werden bei jedem Build automatisch geprüft (
composer audit). - Das letzte Update der Abhängigkeiten liegt Wochen zurück und keine Jahre.
- Ein neues Paket kommt nur mit einer Begründung dazu, und was keine Aufgabe mehr hat, fliegt raus.
Zum letzten Punkt: Überflüssige Polyfills lassen sich über den replace-Abschnitt der composer.json abbestellen. Das geht nur gut, wenn jeder Ihrer Server die Funktion wirklich selbst mitbringt, sonst endet es mit einem Fatal Error im Betrieb.
Wer kümmert sich darum?
Die übliche Antwort lautet: der Entwickler. Gemeint ist meist, dass er es könnte, wenn er Zeit hätte. Abhängigkeiten zu pflegen bringt kein sichtbares Feature und fällt deshalb in jeder Planung hinten herunter. Hat eine Agentur die Anwendung gebaut und übergeben, ist die Antwort noch kürzer: niemand. Der Hoster patcht das Betriebssystem, die Pakete in Ihrer Anwendung fasst er nicht an.
Zuständig ist jemand erst, wenn das hier feststeht:
- eine Person mit Namen, die dafür Zeit im Plan hat
- ein fester Rhythmus für Updates, monatlich reicht für die meisten Anwendungen
- ein Weg, auf dem eine neue Sicherheitsmeldung bei dieser Person ankommt, ohne dass sie danach suchen muss
Ob das intern jemand übernimmt oder ein Dienstleister, ist zweitrangig. Intern scheitert es an der Zeit, die das Tagesgeschäft auffrisst. Extern scheitert es, wenn Updates eingespielt werden, ohne dass Tests zeigen, ob danach noch alles läuft. Ein Update, das niemand prüfen kann, wird beim zweiten Mal nicht mehr gemacht.
Brauchen Sie eine Migration?
Pflege reicht, solange sich die Pakete auf Ihrer vorhandenen Plattform aktualisieren lassen. Sie reicht nicht mehr, sobald die Plattform selbst die Updates verhindert. Daran erkennen Sie es:
- Für wichtige Pakete gibt es neue Versionen, aber Composer installiert sie nicht, weil sie ein neueres PHP verlangen.
- Das Framework steht auf einer Version, für die es keine Sicherheitsupdates mehr gibt.
- Ein zentrales Paket ist aufgegeben, und der Nachfolger setzt eine neuere PHP- oder Framework-Version voraus.
- Seit Jahren hat niemand ein Update gewagt, weil unklar ist, was danach bricht.
- Es gibt gar keine
composer.json, die Bibliotheken liegen als Kopien im Projektordner. Wie man da herauskommt, steht in Composer in ein altes PHP-Projekt einführen.
In diesen Fällen können Sie eine Sicherheitslücke in einer Abhängigkeit nicht schließen, weil die Korrektur nur in einer Version existiert, die bei Ihnen nicht läuft. Dann muss zuerst die Basis auf einen unterstützten Stand, also PHP-Version und Framework, und zwar in kleinen Schritten, wie ich sie in Veraltete PHP-Abhängigkeiten sicher aktualisieren beschreibe. Danach ist Pflege wieder möglich.
Eine lange Paketliste allein ist kein Grund für eine Migration. Eine Anwendung auf aktuellem PHP mit 130 bekannten, gepflegten Paketen steht besser da als eine mit 20, die seit 2019 niemand angefasst hat.
Die ersten beiden Fragen lassen sich an einem Nachmittag mit Ihrem Entwickler klären. Bei der dritten lohnt eine Bestandsaufnahme, bevor jemand einen Preis nennt, damit der Umfang feststeht und nicht geschätzt wird.
