Ihre Composer-Abhängigkeiten werden nicht einfach so ausgemustert, nur weil PHP dies getan hat

Wichtigste Erkenntnisse

• PHP gibt die End-of-Life-Termine bereits Jahre im Voraus bekannt, während bei Composer-Paketen keine Informationen veröffentlicht werden, wenn ein Betreuer nicht mehr aktiv ist.
• Eine veraltete Abhängigkeit ist oft der Grund dafür, dass ein PHP-Upgrade ins Stocken gerät, und nicht etwa eine Nebenwirkung davon.
• composer why-not zeigt Ihnen schnell, was Ihr nächstes Laufzeit-Upgrade verhindert.
• Composer kann veraltete Pakete finden, aber kein Programm in der Toolchain kann diese für Sie aktualisieren.

Ein Team benötigt vier Monate für die Umstellung von PHP 8.1 auf 8.3. Tests, Staging, eine Umstellung am Wochenende – der gesamte Prozess. Es funktioniert.

Dann markiert „composer audit“ ein Paket, das Zahlungs-Webhooks verarbeitet, als aufgegeben markiert. Jemand öffnet das Repository und stellt fest, dass es seit 2021 keine Commits mehr gibt. Keine EOL-Richtlinie, keine Verwendungshinweise – nur ein Projekt, das still und leise keine Aufmerksamkeit mehr erhielt und vier Ebenen tief in einem Abhängigkeitsbaum liegt, den niemand von Anfang bis Ende gelesen hat.

Die Laufzeitumgebung wurde aktualisiert. Die EOL-Software-Risiko hat sich nicht verändert.

In dieser Lücke zwischen „Wir verwenden eine unterstützte PHP-Version“ und „Unsere Anwendung wird unterstützt“ verbergen sich viele PHP-Sicherheitslücken, und diese sind viel schwerer zu erkennen als eine Versionsnummer in php -v.

Der Zeitplan für das Ende des Supports von PHP, den jeder im Auge behält

Die Release-Richtlinien von PHP sind wirklich gut, und genau diese Vorhersehbarkeit ist der Grund dafür, dass das Ende der Laufzeit (EOL) nur die einfache Hälfte dieses Problems darstellt. Jeder Zweig erhält zwei Jahre aktiven Support, gefolgt von zwei weiteren Jahren, in denen ausschließlich kritische Sicherheitsprobleme behoben werden.

Bevor Sie sich die Tabelle ansehen, sollten Sie einen wichtigen Punkt beachten: Dieser Vierjahreszeitraum gilt nur ab PHP 8.1, da der Release-Zyklus im Jahr 2024 verlängert wurde. Für ältere Versionen gab es nur ein Jahr lang Sicherheitsupdates statt zwei, weshalb 7.4 und 8.0 in der Tabelle unten einen kürzeren Zeitraum aufweisen.

So sieht die aktuelle Lage aus, abgeglichen mit der offiziellen Seite zu den unterstützten PHP-Versionen.

PHP 8.1 und 8.2 sind die beiden Versionen, die heute Ihre Aufmerksamkeit verdienen. PHP 8.1 hat im Dezember 2025 das Ende seines Lebenszyklus erreicht im Dezember 2025, sodass alles, was noch darauf läuft, seit Monaten ohne Sicherheitspatches vom Hersteller auskommt. Das EOL von PHP 8.2 endet Ende Dezember 2026, und obwohl 8.2 derzeit zwar noch unterstützt wird, muss jedes Team, das plant, es über dieses Datum hinaus weiter zu nutzen, bereits vorher entsprechende Vorkehrungen treffen.

Teams, die die Migration nicht rechtzeitig abschließen können, können vom Anbieter unterstützte Patches direkt auf die Laufzeitumgebung anwenden und so weiterhin Sicherheitsupdates erhalten, bis die Migration abgeschlossen ist. Genau das bietet der „Endless Lifecycle Support for PHP“ von TuxCare abdeckt, sobald eine PHP-Version das Ende ihres Lebenszyklus erreicht hat – und zwar so lange, wie diese Version in Ihrem Stack verbleibt.

Hinweis: Sich im reinen Sicherheitsfenster zu befinden, ist nicht dasselbe wie unter aktivem Support zu stehen. Regelmäßige Fehlerbehebungen wurden eingestellt. Die Arbeit an der Leistung wurde eingestellt. Die Arbeit an der Kompatibilität wurde eingestellt. Was bleibt, sind kritische Sicherheitskorrekturen auf einem Zweig, den die Release-Manager bereits hinter sich gelassen haben.

Warum Composer-Abhängigkeiten niemals ein Ablaufdatum erhalten

Kaum jemand veröffentlicht eine Support-Richtlinie für ein Paket, das er 2018 an einem Wochenende geschrieben hat.

Das ist der eigentliche Unterschied. PHP verfügt über eine Gruppe von Release-Managern, eine dokumentierte Richtlinie und einen Zeitplan, nach dem man planen kann. Bei einem Composer-Paket hängt oft alles von einer einzelnen Person oder einem kleinen Team ab, und die Beteiligten wechseln den Job, verlieren das Interesse oder werden mit anderen Aufgaben beschäftigt. Wenn das passiert, gibt es keine Ankündigung, da es nie eine Verpflichtung gab, etwas anzukündigen.

Der Verlust der Pflege zeigt sich auf verschiedene Arten, von denen nur eine leicht zu erkennen ist. Ein auf Packagist als „verlassen“ gekennzeichnetes Paket ist der harmlosere Fall, da Composer Sie tatsächlich darauf hinweist. Bei einem auf GitHub archivierten Repository handelt es sich um dieselbe Situation, allerdings ohne jegliche Warnung, und Composer schweigt dazu.

Dann gibt es noch das Paket, dessen letzte Veröffentlichung zwei oder drei Jahre zurückliegt und bei dem sich die ungelösten Probleme häufen; den Betreuer, der zwar noch da ist, aber die Unterstützung für die ältere Hauptversion, an der man gerade festhängt, eingestellt hat; das Paket, das ohne Weiterleitung in ein anderes Projekt integriert wurde; und den Fork, der still und leise zum eigentlichen Projekt wurde, während das Original den Namen behielt.

Ein Paket, das technisch gesehen noch vorhanden ist, noch installiert werden kann, noch einwandfrei aufgelöst wird – und keinerlei Aufmerksamkeit in Bezug auf die Sicherheit erhält –, sieht aus der Perspektive Ihrer composer.lock.

So finden Sie heraus, was bei Ihnen tatsächlich läuft

Nehmen Sie sich pro Anwendung ein paar Minuten Zeit. Die Ausgabe ist in der Regel nicht gerade unterhaltsam zu lesen.

Beginnen Sie mit dem, was Composer bereits weiß.

Komponisten-Audit

Composer 2.4 und höher überprüft Ihre installierten Abhängigkeiten anhand der Advisory-API von Packagist, die die PHP-Sicherheitshinweis-Datenbank und die GitHub-Advisory-Datenbank zusammenfasst. Fügen Sie –locked hinzu, wenn Sie lieber die Datei composer.lock direkt prüfen möchten, ohne es zuvor zu installieren – was in CI die übliche Vorgehensweise ist. Veraltete Pakete wurden mit Composer 2.6.3 eingeführt und fallen seit Version 2.7 standardmäßig bei der Prüfung durch. Daher liefert ein sauberer Durchlauf mit einem modernen Composer bereits mehr Informationen als früher.

Wenn Sie die veraltete Liste nutzen möchten, ohne dass der Build dabei fehlschlägt, gibt es seit Version 2.8 genau dafür ein Flag.

Composer-Prüfung – aufgegeben=Bericht

Dadurch werden aufgegebene Pakete nicht mehr als Fehler, sondern als Meldung eingestuft – was in der Regel genau das ist, was man in der CI wünscht, während ein Rückstand abgebaut wird.

Schau dir nun an, wie weit deine direkten Abhängigkeiten tatsächlich hinterherhinken.

composer show –outdated –direct

Die –direct -Flag ist entscheidend. Lässt man es weg, erhält man den gesamten Baum, in dem die nützlichen Informationen im Rauschen untergehen. Direkte Abhängigkeiten sind diejenigen, die man bewusst ausgewählt hat; daher sind sie der beste Ansatzpunkt für weitere Maßnahmen. Fügen Sie –sort-by-age hinzu, werden die ältesten Versionen zuerst angezeigt – so lassen sich die wirklich veralteten Versionen schneller erkennen.

Wenn etwas veraltet aussieht, überprüfen Sie den tatsächlichen Status des Pakets, anstatt sich auf die Versionsnummer zu verlassen.

composer show vendor/package

Dadurch werden die Metadaten des Pakets abgerufen, darunter auch die Angabe, ob Packagist es als aufgegeben markiert hat und was der Betreuer als Ersatz vorgeschlagen hat – sofern er sich die Mühe gemacht hat, einen Vorschlag zu unterbreiten. Um einen echten Einblick in die Wartungsaktivitäten, die jüngsten Commits, Releases, offenen Issues und die Frage zu erhalten, ob Pull-Requests überhaupt bearbeitet werden, solltest du direkt im Repository nachsehen.

Warum ein PHP-Update dieses Problem nicht behebt

Drehen wir nun die übliche Annahme einmal um. Die nicht mehr unterstützte Abhängigkeit ist in der Regel der Grund dafür, dass Sie noch mit einer alten PHP-Version arbeiten – und nicht ein Symptom dafür.

An unmaintained package requiring php: >=8.1 <8.3 will refuse to install on 8.4, and with nobody maintaining it, that upper bound never gets loosened. The upgrade stalls on a library that stopped receiving maintenance years ago.

Composer zeigt Ihnen genau an, welche Pakete das Problem verursachen.

Composer Why-Not PHP 8.4

Führen Sie das durch, bevor Sie ein Upgrade der Laufzeitumgebung in Betracht ziehen. Dadurch wird aus der Aussage „Die Migration auf PHP 8.4 ist eine große Unbekannte“ eine konkrete und meist kürzer als erwartet ausfallende Liste, auf der oft ein oder zwei Namen stehen, die für Stille im Raum sorgen.

Das Ergebnis sieht in etwa so aus:

Das Paket „php“ mit der Versionsangabe „8.4“ konnte nicht gefunden werden; die folgenden Ergebnisse sind daher höchstwahrscheinlich unvollständig.

acme/webhook-handler 2.0.0 requires php (>=8.1 <8.3)

Haben Sie nicht gefunden, wonach Sie gesucht haben? Versuchen Sie es mit dem Befehl `composer require „php:8.4“ –dry-run`, um das Problem aus einem anderen Blickwinkel zu betrachten.

composer why-not liefert dir die Rohdatenliste, welche Pakete und welche Einschränkungen. Was du mit jedem einzelnen machst, hängt von einer kurzen Nachprüfung ab: `composer show vendor/package` sowie einen Blick in das Repo. Vier mögliche Ergebnisse decken fast alle Fälle ab, auf die du stoßen wirst.

Wenn Sie eine aufgegebene Bibliothek in Ihr eigenes Repository übernehmen, bedeutet dies, dass Ihr Team nun die Verantwortung für die darin enthaltenen CVEs übernimmt – und die meisten Teams, die diesen Weg einschlagen, stellen dafür kein zusätzliches Personal ein. Der Code wird kopiert, die Verantwortung dafür jedoch nicht.

Das Patchen von Composer-Paketen, nachdem der Upstream-Entwickler das Projekt aufgegeben hat, ist ein sehr spezielles Fachgebiet, und genau das ist das Problem SecureChain für PHP wurde entwickelt, um dieses Problem zu bewältigen – und nicht als eine Funktion, die die meisten Entwicklungsabteilungen intern aufbauen und pflegen möchten.

Was passiert mit Sicherheitspatches, wenn sich der Upstream-Entwickler zurückzieht?

Im Vorfeld passiert nichts. Das sollte man ausdrücklich betonen, denn viele Teams gehen stillschweigend davon aus, dass es irgendwo ein Sicherheitsnetz gibt.

Packagist führt keine Korrekturen an Paketen durch. In Sicherheitshinweisdatenbanken werden Sicherheitslücken erfasst – das ist zwar nützlich, hat aber nichts mit deren Behebung zu tun. Ein Sicherheitshinweis zu einem nicht mehr gepflegten Composer-Paket kann auf unbestimmte Zeit ungelöst bleiben, da es keine offizielle, korrigierte Version gibt, auf die man aktualisieren könnte – es sei denn, die Pflege wird wieder aufgenommen oder ein Fork übernimmt die Korrektur.

Von da an sind Ihre Möglichkeiten begrenzt. Sie können einen Fork erstellen und das Problem selbst beheben, die Abhängigkeit ersetzen, das Risiko mit einer dokumentierten Ausgleichsmaßnahme in Kauf nehmen oder jemanden hinzuziehen, dessen eigentliche Aufgabe darin besteht, Korrekturen auf den zurückgelassenen Upstream-Code zurückzuportieren.

Hinweis: Wenn Sie einen Fork patchen, wählen Sie bewusst die Composer-Strategie. Für eine Anwendung sieht der dokumentierte Weg wie folgt aus: ein VCS-Repository, das auf Ihren Fork verweist, der ursprüngliche Paketname bleibt unverändert, und die Einschränkung zielt auf Ihr dev- Branch. Veröffentlichen Sie den Fork stattdessen unter Ihrem eigenen Namen, und Sie müssen ersetzenersetzen, damit alles, was das Original benötigt, weiterhin aufgelöst wird. Inline-Aliase sind die Falle. Sie sind eine Funktion, die nur für den Root-Zweig verfügbar ist, was bedeutet, dass die linke Seite des als für jeden, der von Ihrem Paket abhängig ist, verworfen wird – und der Fehler tritt meist erst Monate später in der CI eines anderen auf.

Entscheidung darüber, wie mit den einzelnen veralteten Abhängigkeiten verfahren werden soll

Berücksichtigen Sie neben der Schwere auch den Auswirkungsbereich. Eine Schwachstelle, die Bereiche wie Authentifizierung, Zahlungen, Datei-Uploads oder Deserialisierung betrifft, verdient selbst bei einem moderaten Befund besondere Aufmerksamkeit. Das gilt jedoch in beide Richtungen. Eine kritische und leicht ausnutzbare Schwachstelle in einem weniger auffälligen Bereich sollte nicht einfach ignoriert werden, nur weil der Auswirkungsbereich kleiner erscheint.

Arbeiten Sie dann die Liste ab. Wenn eine gepflegte Fork-Version existiert und die API kompatibel ist, wechseln Sie, testen Sie und machen Sie weiter. Das deckt mehr Fälle ab, als Teams manchmal erwarten, auch wenn der Aufwand davon abhängt, wie stark sich die API verändert hat und auf wie viel Testabdeckung Sie zurückgreifen können. Wenn das Paket klein ist und Sie es tatsächlich verstehen, stellen Sie es als Vendor-Paket bereit und übernehmen Sie die Pflege – aber halten Sie schriftlich fest, wer dafür verantwortlich ist, denn genau durch nicht zugewiesenen Vendor-Code taucht dieses Problem in drei Jahren wieder auf.

Wenn das Paket groß und sicherheitsrelevant ist und niemand es pflegt, sollten Sie sich die Entscheidung für die Aufnahme in das Vendor-System gut überlegen. Das ist eine langfristige Verpflichtung zur Fehlerbehebung, für die Ihr Team Personal bereitstellen muss, und eine sicherheitsrelevante Bibliothek ohne Verantwortlichen ist schlimmer als eine offensichtliche externe Abhängigkeit.

Falls eine veraltete Abhängigkeit ein PHP-Upgrade blockiert, zu dem Sie sich bereits entschlossen haben, beheben Sie zunächst die Abhängigkeit und führen Sie das Laufzeit-Upgrade erst als zweiten Schritt durch. Der Versuch, beides gleichzeitig zu lösen, verwandelt eine begrenzte Laufzeitmigration in ein viel umfangreicheres Projekt zur Behebung von Abhängigkeiten.

Und falls Sie aufgrund gesetzlicher oder vertraglicher Auflagen nicht nach dem Zeitplan des Upstream-Projekts vorgehen können, bieten vom Anbieter bereitgestellte Patches sowohl für die Laufzeitumgebung als auch für die betroffenen Pakete eine weitere Möglichkeit. So werden weiterhin Sicherheitskorrekturen bereitgestellt, während die Migration nach einem Zeitplan erfolgt, den das Unternehmen tatsächlich finanzieren kann.

Die Dauer hängt stark vom Alter der Anwendung und dem verwendeten Framework ab. Bei einer einigermaßen aktuellen Laravel-Anwendung mit aktiv gepflegten Abhängigkeiten ist das Upgrade in der Regel eine recht unspektakuläre Angelegenheit. Eine zehn Jahre alte Anwendung auf einem selbst entwickelten Framework mit vierzig direkten Abhängigkeiten ist hingegen eine ganz andere Herausforderung, und wer für beides denselben Zeitrahmen angibt, hat noch nie Composer why-not ausgeführt.

In unserem speziellen Leitfaden erfahren Sie außerdem mehr über bewährte Verfahren zur Sicherheit in Laravel und Maßnahmen zur Risikominderung im Framework.

Sicherung der PHP-Lieferkette

Die Zeitpläne für das Ende des Lebenszyklus von PHP werden schon Jahre im Voraus veröffentlicht, und jedes Team, das über einen Kalender verfügt, kann entsprechend planen. Das schwierigere Problem liegt in Ihrer composer.lock steckt – unangekündigt, ungeplant und außerhalb jeglicher Kontrolle, sobald ein Betreuer das Projekt verlässt.

Die Composer-eigenen Tools zeigen Ihnen an, was veraltet ist. Sie werden jedoch keine der betroffenen Komponenten patchen. Das ist die Lücke SecureChain für PHP schließt diese Lücke: Pakete werden aus dem Quellcode neu kompiliert und geprüft, bevor sie in Ihren Build gelangen, und anschließend überwacht und gepatcht, sobald Schwachstellen auftreten. Wenn die Pflege der Upstream-Pakete eingestellt wird, erweitert TuxCare ELS die Patch-Abdeckung – ebenso wie bei PHP-Laufzeitversionen, deren Lebensdauer abgelaufen ist.

Anstatt Bibliotheken in Ihr eigenes Repository zu forken und dabei stillschweigend deren CVEs zu übernehmen, erhalten Sie eine geprüfte, aus dem Quellcode neu kompilierte Alternative zu Packagist, die sich nahtlos in denselben Composer-Workflow einfügt, sodass „eingestellte“ Bibliotheken kein Risiko mehr darstellen, das Ihr Team allein tragen muss.

FAQ

Wann läuft der Support für PHP 8.1 aus?

PHP 8.1 hat bereits am 31. Dezember 2025 das Ende seines Lebenszyklus erreicht. Daher erhalten Systeme, die noch darauf laufen, seitdem keine Sicherheitsupdates mehr vom Hersteller, es sei denn, eine Patch-Lösung eines Drittanbieters schließt diese Lücke.

Welche PHP-Versionen werden noch unterstützt?

PHP 8.2, 8.3, 8.4 und 8.5. Davon werden 8.2 und 8.3 nur noch im Bereich der Sicherheitsupdates unterstützt, wobei 8.2 am 31. Dezember 2026 sogar diese Unterstützung verliert. Den aktuellen Status finden Sie auf der offiziellen Seite zu den unterstützten PHP-Versionen. 

Wie finde ich veraltete Composer-Pakete in meinem Projekt?

Ausführen composer auditaus, was bei Composer 2.7 und höher standardmäßig bei veralteten Paketen fehlschlägt, oder composer audit –abandoned=report , wenn Sie die Liste lieber anzeigen möchten, ohne den Build zu unterbrechen. Führen Sie anschließend `composer show –outdated –direct` aus, um direkte Abhängigkeiten zu finden, für die neuere Versionen verfügbar sind, und fügen Sie –sort-by-age hinzu, um die ältesten Einträge ganz oben anzuzeigen. Die Markierungen für eingestellte Projekte bei Packagist sind nicht vollständig, überprüfen Sie daher die Repository-Aktivität auf Einträge, die veraltet wirken.

Was passiert mit einem Composer-Paket, das eine CVE-Kennung hat und keinen Betreuer?

Die Sicherheitsempfehlung wird veröffentlicht, doch bei einem eingestellten Projekt wird möglicherweise nie eine gepatchte Version veröffentlicht. Sie haben folgende Möglichkeiten: Sie können einen Fork erstellen und das Problem selbst beheben, die Abhängigkeit ersetzen, eine Ausgleichsmaßnahme dokumentieren oder einen Anbieter nutzen, der Korrekturen auf eingestellte Pakete zurückportiert.

Werden veraltete Composer-Abhängigkeiten durch ein PHP-Upgrade behoben?

Nein, und normalerweise verhält es sich genau umgekehrt. Ein veraltetes Paket mit einer engen PHP-Versionsbeschränkung ist oft genau das, was das Upgrade der Laufzeitumgebung verhindert, weshalb „composer why-not php 8.4“ am Anfang jeder Diskussion über den Umfang eines Upgrades stehen sollte und nicht am Ende.

Stellt die Verwendung von PHP-Versionen, deren Lebenszyklus abgelaufen ist, ein Compliance-Problem dar?

Das kann durchaus der Fall sein. Wenn ein Framework die zeitnahe Behebung von Sicherheitslücken oder vom Hersteller unterstützte Software vorschreibt, lässt sich eine EOL-Laufzeitumgebung nur schwer damit vereinbaren, denn sobald keine Upstream-Korrekturen mehr bereitgestellt werden, benötigen die Teams eine andere Möglichkeit, um nachzuweisen, dass neu bekannt gewordene Sicherheitslücken weiterhin behoben werden. Eine erweiterte Sicherheitspatch-Bereitstellung, wie beispielsweise der Support TuxCare bietet, kann dazu beitragen, diesen Nachweis während einer Migration aufrechtzuerhalten, wobei es vom jeweiligen Rahmenwerk und dessen Umsetzung abhängt, was einen Prüfer zufriedenstellt.

Zusammenfassung

Artikel Name

Das Ende des Lebenszyklus von PHP und die Composer-Abhängigkeiten, die niemand im Blick hat

Beschreibung

Die End-of-Life-Termine für PHP lassen sich leicht nachverfolgen. Die veralteten Composer-Pakete in Ihrer Anwendung hingegen nicht – und genau diese sind in der Regel der eigentliche Grund, warum das Upgrade nicht gelingt.

Autor

Tim Walker

Name des Herausgebers

TuxCare

Logo des Herausgebers