Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Ein vernachlässigtes Paket bleibt über Packagist weiterhin installierbar – trotz offener CVEs und allem –, da die Behebung von Fehlern in Paketen nie zu den Aufgaben von Packagist gehörte.
- SecureChain kompiliert PHP-Pakete vor der Installation neu und überprüft sie; anschließend werden sie weiterhin mit Patches versorgt, wenn die Wartung durch den Upstream-Entwickler nachlässt oder eingestellt wird.
- Sie können Ihre gesamte Composer-Konfiguration über SecureChain leiten oder nur die Pakete senden, bei denen dies erforderlich ist.
- Private Packagist hostet und speichert Ihre Pakete, während SecureChain diejenigen patcht, die von niemandem mehr gepflegt werden.
Ein veraltetes Composer-Paket mit einer offenen CVE bringt Sie in eine unangenehme Lage. Eine Korrektur durch den Upstream-Entwickler ist wahrscheinlich nicht zu erwarten, und Ihre Optionen beschränken sich darauf, selbst einen Fork zu erstellen, das Paket auszutauschen oder eine Ausgleichsmaßnahme zu dokumentieren und zu hoffen, dass ein Prüfer diese akzeptiert. Eine Packagist-Alternative, die darauf ausgelegt ist, solche Probleme zu beheben. SecureChain erstellt PHP-Pakete neu und überprüft sie, bevor sie in Ihren Build gelangen, und liefert dann im Rahmen eines SLA weiterhin Korrekturen, lange nachdem der ursprüngliche Betreuer sich nicht mehr meldet – entweder anstelle von Packagist oder parallel dazu.
Hier erfahren Sie, was diese Lösung konkret umfasst und wie sie sich in den Composer-Workflow einfügt, den Sie bereits nutzen.
Warum Teams nach einer Alternative zu Packagist suchen
Packagist erfüllt genau den Zweck, für den es entwickelt wurde. Es indexiert Paket-Repositorys und teilt Composer mit, woher der Code bezogen werden soll – und diese Aufgabe erfüllt es gut. Wofür es jedoch niemals entwickelt wurde, ist das Beheben von Problemen. Wenn ein Maintainer keine neuen Versionen mehr veröffentlicht, liefert Composer weiterhin problemlos eine bereits vorhandene, anfällige Version über die Metadaten von Packagist, einschließlich CVE und allem, was dazugehört.
Dieses Bild hat sich in diesem Jahr geändert. Composer 2.10, das Ende Mai veröffentlicht wurde, blockiert Versionen, die bei der Auflösung als Malware gekennzeichnet wurden, sowie bei der Installation aus einer bestehenden Sperrdatei, und fasst Sicherheitshinweise, aufgegebene Pakete und Malware in einer einzigen Abhängigkeitsrichtlinie zusammen. Packagist folgte im Juli mit der Einführung der Unveränderlichkeit veröffentlichter stabiler Versionen, sodass eine neu getaggte Version nicht mehr unbemerkt das ersetzen kann, was Sie bereits gesperrt haben. Beide Änderungen stellen echte Verbesserungen dar, und keine von beiden schreibt einen Patch. Das Blockieren einer fehlerhaften Version lässt Sie jedoch weiterhin mit einem aufgegebenen Paket zurück, das eine offene CVE aufweist und für dessen Behebung es keinen Upstream-Entwickler gibt.
Das ist in der Regel der Moment, in dem ein Team nach einer Packagist-Alternative sucht, anstatt sich mit einer einmaligen Notlösung zu begnügen. Der Unterschied ist entscheidend. Eine Notlösung behebt einen einzelnen Audit-Befund. Eine auf Patches basierende Alternative geht davon aus, dass dies auch weiterhin passieren wird – und zwar nicht nur bei dem einen veralteten Paket, das gerade auf Ihrem Schreibtisch liegt. Weitere Informationen dazu, warum Composer-Abhängigkeiten im Gegensatz zu PHP niemals ein End-of-Life-Datum erhalten, finden Sie im Artikel „Ihre Composer-Abhängigkeiten werden nicht ausgemustert, nur weil PHP es wurde“, der sich eingehend damit befasst, was das für die Pakete bedeutet, die in Ihrer App noch laufen.
Auch hier ist PHP kein Einzelfall. Vorfälle in der Lieferkette, die sich im Jahr 2026 in mehreren Open-Source-Ökosystemen ereigneten, haben Teams Anlass gegeben, das Vertrauen in Registries zu überdenken, und dieses Muster beschränkt sich nicht auf eine bestimmte Programmiersprache.
Wie SecureChain auch nach dem Rückzug von Upstream weiterhin Patches bereitstellt
SecureChain betrachtet dies als ein Problem des gesamten Lebenszyklus und nicht als einmalige Lösung. Jedes PHP-Paket, das SecureChain bereitstellt, wird in einer isolierten Umgebung aus dem Quellcode neu kompiliert, bevor es zur Installation bereitsteht. So wird alles, was in Ihren Build gelangt, von Anfang bis Ende überprüft, anstatt direkt aus einem Upstream-Artefakt übernommen zu werden, das niemand neu kompiliert oder überprüft hat. Die Pakete werden zudem auf bekannte Malware und verdächtige Codemuster überprüft, und alles, was die Überprüfung nicht besteht, wird blockiert, bevor es Sie erreicht – und nicht erst nachträglich gekennzeichnet.
Die Arbeit ist noch nicht beendet, sobald ein Paket diese erste Prüfung bestanden hat. Solange der Upstream weiterhin Releases veröffentlicht, werden aktive Komponenten im Rahmen des SLA überwacht und gepatcht, sobald neue CVEs auftauchen – genau so, wie man es von einem Maintainer erwarten würde, der weiterhin am Ball bleibt. Sobald es seitens des Upstream-Entwicklers still wird, übernimmt TuxCare die direkte Pflege des Pakets, und etwa sechs Monate nach der letzten Upstream-Version übernimmt der „Endless Lifecycle Support“ und liefert weiterhin Korrekturen, solange Sie auf das Paket angewiesen sind – unabhängig davon, ob der ursprüngliche Betreuer jemals zurückkehrt oder nicht.
Genau in dieser Lücke – zwischen der Erkennung eines Problems und dessen tatsächlicher Behebung – scheitern viele Supply-Chain-Tools. Für Teams, die ihre Arbeit nachweisen müssen, erstellt SecureChain zudem eine Herkunftsnachweis nach SLSA Level 3, eine SBOM sowie VEX-Daten, sodass hinter der Aussage „das wurde gepatcht“ ein Nachweis steht und es sich nicht nur um eine Behauptung handelt, die man blind glauben muss.
Wie sich SecureChain in das Packagist-Ökosystem einfügt
Dafür müssen Sie die bestehende Arbeitsweise Ihres Teams mit Composer in keiner Weise ändern. SecureChain ist ein Composer-kompatibles Repository, auf das Sie anstelle des öffentlichen Packagist oder zusätzlich dazu verweisen können – und wie viel Ihres Datenverkehrs darüber läuft, entscheiden Sie selbst.
Einige Teams leiten ihre gesamte Composer-Konfiguration über SecureChain, sodass alle von ihnen abgerufenen Pakete vor der Installation neu kompiliert und überprüft werden – und nicht nur die veralteten Pakete. Andere verfolgen einen enger gefassten Ansatz und senden nur die Pakete, von denen sie wissen, dass sie veraltet oder risikoreich sind, während alles andere genau wie bisher über Packagist bezogen wird. Alles, was noch nicht im Katalog enthalten ist, kann auf Anfrage hinzugefügt werden. So oder so nutzen die Entwickler weiterhin dasselbe composer install und composer update Befehle, die sie bereits kennen, und sobald das Repository konfiguriert ist, bleibt der tägliche Arbeitsablauf unverändert.
Was sich ändert, ist der Ablauf hinter diesen Befehlen für alles, was über SecureChain geleitet wird. Anstatt dass Composer von der Stelle herunterlädt, auf die die Metadaten von Packagist verweisen – sei es ein Quell-Repository oder ein Distributionsarchiv –, bezieht es das Paket aus einem Repository, in dem es bereits neu kompiliert, geprüft und gepatcht wurde. Ihre Lock-Datei speichert weiterhin die Versionen und Referenzen, die Composer aufgelöst hat. Der Unterschied liegt darin, woher sie stammen: Es handelt sich um ein neu kompiliertes und gepflegtes Paket, das aus dem Repository von TuxCare bereitgestellt wird, anstatt aus der Quelle, die der normale Upstream-Pfad Ihnen geliefert hätte.
SecureChain in Ihren Composer-Stack integrieren
Wenn bei Ihrem letzten Audit zwei oder drei veraltete Pakete mit offenen Sicherheitswarnungen festgestellt wurden, ist das ein überschaubarer, klar abgegrenzter Ansatzpunkt – und kein Grund, Ihre gesamte Abhängigkeitsstruktur neu zu gestalten. Ist die Liste der veralteten Pakete länger, lautet die sinnvollere erste Frage, welche dieser Pakete realistisch gesehen gepatcht werden können, da dies ausschlaggebend dafür ist, in welchem Umfang es sinnvoll ist, Ihre Composer-Konfiguration von Anfang an über SecureChain zu leiten.
SecureChain ist kein Ersatz für Private Packagist, und es ist hilfreich, die beiden voneinander zu unterscheiden. Private Packagist von Packagist Conductors, dem Unternehmen hinter Composer und Packagist.org, kümmert sich um das Hosting privater Pakete, die Spiegelung und die Kontrolle der Verteilung und hat im Laufe des letzten Jahres eine ganze Reihe eigener Tools zur Sicherheit der Lieferkette hinzugefügt. Was es jedoch nicht tut, ist das Backportieren von Fehlerbehebungen für eine Abhängigkeit, deren Betreuer schon vor Jahren aufgehört hat, zu antworten. Ein Team, dessen Hauptanforderung das private Hosting ist, ist dort besser aufgehoben, und der gleichzeitige Einsatz beider Lösungen ist durchaus sinnvoll, da keine der beiden die Aufgaben der anderen übernimmt.
Wenn Ihnen bei PHP-Paketen die Abdeckung fehlt, sehen Sie sich SecureChain für PHP an, um genauer zu erfahren, wie dies funktioniert, oder fordern Sie ein Angebot für eine detaillierte Darstellung an, was in Ihrem spezifischen Stack abgedeckt würde.
FAQ
Was ist eine Alternative zu Packagist?
Eine Packagist-Alternative ist ein Composer-kompatibles Repository, das anstelle des öffentlichen Packagist oder parallel dazu genutzt wird. Teams greifen darauf zurück, wenn sie etwas benötigen, was das öffentliche Packagist nicht bietet, wie beispielsweise privates Hosting, kontrollierte Verteilung, strengere Sicherheitsprüfungen oder fortlaufende Patches für Pakete, die niemand mehr pflegt.
Was genau behebt SecureChain eigentlich?
SecureChain behebt Sicherheitslücken über den gesamten Lebenszyklus eines PHP-Pakets hinweg. Aktive Pakete werden im Rahmen des SLA gepatcht; sobald die Entwicklung durch den Upstream-Anbieter eingestellt wird, übernimmt TuxCare die direkte Wartung, und der „Endless Lifecycle Support“ gewährleistet danach eine langfristige Absicherung, solange Sie das Paket nutzen.
Muss ich Packagist komplett ersetzen, um SecureChain nutzen zu können?
Nein. Sie können Ihre gesamte Composer-Umgebung über SecureChain leiten oder bestimmte Pakete darüber leiten, während alles andere wie gewohnt weiterhin über Packagist bezogen wird.
Ersetzt dies „Private Packagist“?
Nein, sie lösen unterschiedliche Probleme. Private Packagist bietet privates Paket-Hosting, Spiegelung und Kontrollmöglichkeiten bei der Verteilung, während SecureChain Pakete patcht, deren Upstream-Betreuer die Behebung von Sicherheitslücken eingestellt hat.
Müssen Entwickler ihre Vorgehensweise bei der Nutzung von Composer ändern?
Nein. Sobald das Repository konfiguriert ist, bleiben die Composer-Befehle und -Abläufe unverändert. Was sich ändert, ist das, was hinter den installierten Paketen steckt.
