Composer als Risiko: Wo der Alltag oft danebenliegt
Composer? Klar, Standard. Aber jedes Paket von Packagist oder sonstwo: Fremdcode, der unbemerkt alles lahmlegen kann. In der Praxis läuft’s meistens so – composer install, fertig. Wer denkt dabei schon an Angriffe über Abhängigkeiten? Die meisten Schwachstellen kommen eh nicht aus dem eigenen Code, sondern über Dritte. Ein einziges schwaches Paket – schon gibt’s Datenabfluss oder Ausfälle, gern auch Monate unentdeckt.
Typischer Ablauf: Maintainer-Account gehackt, Angreifer schiebt mit dem nächsten Update eine Backdoor rein. Dann reicht ein composer update. Zack, der Server telefoniert nach Hause. Die Kontrolle? Weg. Das ist kein theoretisches Szenario, sondern passiert regelmäßig – nur kriegt es kaum jemand schnell mit.
2026: Wie sieht’s in echten Projekten aus?
Trotz aller Warnungen – die Realität ist oft träge. Agenturen, aber auch größere IT-Abteilungen: composer.json, composer.lock, ab und an ein Update. Das war's. Integritätsprüfung? Selten gesehen. Zugriff auf Paketquellen limitieren? Meist Fehlanzeige. Automatisiertes Monitoring? Luxus.
Das Problem fällt dann auf, wenn’s weh tut. Beispiel aus dem Alltag: Framework-Update, neuer Maintainer, Changelog nichtssagend. Drei Wochen später fällt auf: Da fließen Nutzerdaten durch eine versteckte API an einen Drittserver. Ursache? Ein Paket, das niemand wirklich geprüft hat. Das lief dann einfach – monatelang.
Signaturen: Theoretisch Standard, praktisch selten
Composer kann Pakete mit OpenPGP-Signaturen prüfen – schon länger. Nur: In den meisten Teams bleibt das aus. Aufwand wird gern als Ausrede genommen. Dabei ist das Setup übersichtlich:
- Composer dafür konfigurieren, nur signierte Pakete zuzulassen
- Öffentliche Schlüssel aktuell halten (ja, nervig, aber nötig)
- Build abbrechen lassen, wenn die Signatur fehlt oder nicht stimmt
Dauert beim Einrichten ein bisschen, spart aber im Zweifel Wochen an Ermittlungsarbeit. Gerade mit mehreren Entwicklern oder wechselnden Freelancern: Ohne Signaturprüfung ist’s russisches Roulette.
composer.lock und feste Versionen: Keine Wildwuchs-Updates
Wer bei jedem Deployment flexible Versionen zulässt, lädt das Chaos ein. composer.lock gehört ins Repo. Keine Diskussion. Sonst läuft auf Staging was anderes als auf Live – und das merkt man immer erst zu spät.
Abhängigkeiten sollten gezielt festgelegt werden. Version wild auf ^2.0 oder *? Das reicht selten. Kritische Libraries brauchen eine Kontrolle vor jedem Update. Kein automatisches composer update in CI/CD. Lieber manuell prüfen – ja, kostet Zeit, rettet aber im Zweifel den Hintern.
Security-Checks und Monitoring: Automatisieren, was nervt
CI/CD kann Security-Checks integrieren – nicht nur Unit-Tests. Tools wie Symfony Security Checker oder Snyk laufen im Build mit. Klingelt Alarm, wenn eine bekannte Schwachstelle dabei ist. Funktioniert, ist aber oft noch die Ausnahme.
Was fast nie eingerichtet wird: Paketänderungs-Monitoring. Wer bekommt eine Mail, wenn Maintainer oder Source wechseln? In den meisten Projekten niemand. Das bleibt ein Dauerproblem. Früherkennung? Fehlanzeige.
Meine Einschätzung nach 30 Jahren Webentwicklung
Supply-Chain-Security ist weniger Technik, mehr Disziplin. Tools sind leicht aufgesetzt – aber die Prozesse sind der Stolperstein. In Agenturen ab fünf Köpfen: Zugriffsrechte eng halten, Verantwortlichkeiten für Updates klar verteilen. Composer-Signaturen schulen, Monitoring ernst nehmen. Lohnt sich, spätestens beim ersten Vorfall.
Wer als Einzelkämpfer unterwegs ist, muss composer.lock pflegen, Updates bewusst machen, Security-Tools regelmäßig laufen lassen. Ist nicht sexy, spart aber Geld und Nerven. Ein Vorfall kostet schnell den besten Kunden – oder die Existenz, wenn sensible Daten betroffen sind.
Weiterführend in dieser Serie
- PHP 8.4: Neue Stolpersteine, neue Chancen – was jetzt ansteht
- PHP-Altprojekte absichern: OWASP-Check für SQL-Injection, XSS und Session-Fixation
Fazit
2026 reicht Standard-Composer-Workflow nicht mehr. Ohne Paket-Signaturen, feste Versionen, Security-Checks und klare Abläufe bleibt die PHP-Lieferkette ein Risiko. Ein bisschen Mehraufwand schützt Server und Kundenvertrauen – und rettet im Zweifel das eigene Geschäft.
bye
mo