Composer: Die Paketverwaltung für PHP

Kurz gesagt: Composer ist die Paketverwaltung für PHP. Sie liest aus der Datei composer.json, welche Bibliotheken ein Projekt braucht, lädt sie in den Ordner vendor, hält die exakten Versionen in der composer.lock fest und erzeugt einen Autoloader, der Klassen automatisch findet. Composer verwaltet damit den Code Ihrer Anwendung, nicht den PHP-Interpreter selbst: Ein Composer-Update schließt keine Lücke in PHP wie PHP2Shell.

Was ist Composer und wozu braucht man es?

Kaum eine PHP-Anwendung besteht heute nur aus eigenem Code. Frameworks, Mail-Bibliotheken, PDF-Erzeugung oder Zahlungsanbindungen kommen als fertige Pakete hinzu. Composer, die Paketverwaltung für PHP, sorgt dafür, dass diese Pakete in passenden Versionen zusammenkommen und dass jede Abhängigkeit ihre eigenen Abhängigkeiten mitbringt.

Für Entscheider heißt das: Ein großer Teil des Codes, der auf Ihrem Server läuft, stammt von Dritten. Das ist effizient, verlangt aber Pflege. Für Admins und Entwickler heißt das: Wer Composer sauber einsetzt, kann jederzeit nachvollziehen, welche Version welcher Bibliothek in der Produktion läuft.

Standardquelle für Pakete ist laut Composer-Dokumentation Packagist.org. Weitere Quellen, etwa interne Repositorys einer Agentur, lassen sich in der composer.json unter repositories eintragen.

composer.json, composer.lock und vendor: die drei Bausteine

Composer arbeitet mit drei Dingen, die man kennen sollte, bevor man einen Server übernimmt oder eine Agentur beauftragt.

Unter require stehen Pakete, die die Anwendung im Betrieb braucht. Unter require-dev stehen Werkzeuge für Entwicklung und Tests, etwa Testframeworks oder statische Analyse. Diese Trennung ist wichtig, weil Entwicklungswerkzeuge auf einem Produktionsserver nichts verloren haben.

{
    "require": {
        "php": ">=8.3",
        "monolog/monolog": "^3.0"
    },
    "require-dev": {
        "phpunit/phpunit": "^11.0"
    },
    "autoload": {
        "psr-4": { "App\\": "src/" }
    }
}

Die Versionsangaben im Beispiel sind nur zur Veranschaulichung gewählt. Welche Versionen Ihr Projekt braucht, ergibt sich aus seinen Anforderungen.

install oder update: der Unterschied im Betrieb

Die beiden Befehle klingen ähnlich, haben aber sehr unterschiedliche Folgen.

• composer install liest die composer.lock und installiert genau die dort festgehaltenen Versionen. Das ist reproduzierbar und gehört in die Auslieferung.
• composer update löst alle Abhängigkeiten neu auf, holt die neuesten passenden Versionen und schreibt die composer.lock neu. Das gehört in die Entwicklung, mit anschließenden Tests.

Laut Composer-Dokumentation führt update nach dem Schreiben der Lock-Datei zusätzlich eine Sicherheitsprüfung (Audit) aus, sofern sie nicht mit --no-audit abgeschaltet wird. install prüft standardmäßig nicht; dafür gibt es die Option --audit.

Autoloading: wie Composer Klassen findet

Composer erzeugt die Datei vendor/autoload.php. Wird sie einmal eingebunden, lädt PHP jede Klasse erst dann, wenn sie gebraucht wird. Für eigenen Code wird im Abschnitt autoload festgelegt, welcher Namespace in welchem Ordner liegt. Empfohlen ist dafür PSR-4, ein Standard der PHP-FIG. Wie das genau funktioniert, erklärt die Seite Namespaces und Autoloading; einen Überblick über alle Standards gibt die Seite PSR-Standards.

<?php
require __DIR__ . '/../vendor/autoload.php';

$log = new Monolog\Logger('app');   // wird bei Bedarf automatisch geladen

Composer in der Produktion: sauber ausliefern

Für die Auslieferung hat sich eine feste Reihenfolge bewährt. Sie läuft am besten in einer Build-Pipeline und nicht von Hand auf dem Server.

1. Lock-Datei prüfen: composer validate stellt sicher, dass composer.json gültig und die composer.lock aktuell ist.
2. Ohne Entwicklungspakete installieren: composer install --no-dev lässt require-dev weg.
3. Autoloader optimieren: --optimize-autoloader (kurz -o) wandelt die Regeln in eine Klassenliste um. Mit --classmap-authoritative lädt PHP Klassen ausschließlich aus dieser Liste.
4. Sicherheitsprüfung: composer audit --locked prüft die Versionen aus der Lock-Datei gegen bekannte Sicherheitsmeldungen und meldet aufgegebene Pakete.
5. vendor außerhalb des Webroots: Nur der öffentliche Ordner mit dem Einstiegsskript sollte per URL erreichbar sein.

composer validate
composer install --no-dev --optimize-autoloader
composer audit --locked --no-dev

composer outdated zeigt zusätzlich, welche installierten Pakete neuere Versionen haben. Das ist die Grundlage für geplante Updates statt hektischer Einzelaktionen.

Composer, Sicherheit und PHP2Shell

Composer und PHP2Shell betreffen zwei verschiedene Ebenen. Die Lücken CVE-2026-109618 und CVE-2026-109619 liegen im PHP-Interpreter selbst. Behoben sind sie in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, und alle PHP-Prozesse müssen danach neu gestartet werden. Kein composer update und kein Paket in vendor ändert daran etwas.

Trotzdem gehört Composer in jede Prüfung nach einem Vorfall. Wer Schadcode auf einen Server bringt, kann auch Dateien in vendor verändern, und vendor/autoload.php wird bei jeder Anfrage geladen. Ein frisches composer install aus der geprüften Lock-Datei in ein leeres Verzeichnis ist deshalb eine gute Methode, um den Paketbestand wiederherzustellen. Wie Sie Abhängigkeiten regelmäßig auf bekannte Lücken prüfen, beschreibt der Ratgeber composer audit.

Wie hilft PHP SOS konkret?

• Wir erfassen für jede Anwendung PHP-Version, Composer-Pakete und Lock-Stand und trennen dabei sauber zwischen Interpreter und Bibliotheken.
• Wir prüfen, ob vendor und Lock-Datei zueinander passen und ob Entwicklungspakete oder veränderte Dateien in der Produktion liegen.
• Wir richten eine reproduzierbare Auslieferung mit install --no-dev, optimiertem Autoloader und Audit ein.
• Nach einem Vorfall stellen wir den Paketbestand aus der geprüften Lock-Datei neu her und dokumentieren das Ergebnis.

Häufige Fragen

Quellen

• Composer: Basic usage
• Composer: Command-line interface
• Composer: The composer.json schema