# Composer: Die Paketverwaltung für PHP

> Composer erklärt: composer.json, composer.lock, vendor und Autoloader verstehen, sauber in die Produktion ausliefern und Abhängigkeiten sicher pflegen.

Quelle: https://phpsos.de/php/composer/  
Stand: 25.10.2026  
Anbieter: PHP SOS, PHP-Notfallhilfe und Server-Sicherheit. Soforthilfe per WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wir%20brauchen%20Hilfe%20mit%20unserem%20PHP-Server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**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.

| Baustein | Inhalt | Gehört ins Repository? |
|---|---|---|
| `composer.json` | gewünschte Pakete mit Versionsbereichen (`require`, `require-dev`), Autoload-Regeln, Einstellungen | ja |
| `composer.lock` | exakt aufgelöste Versionen aller Pakete, auch der indirekten | ja, laut Composer-Doku ausdrücklich |
| `vendor/` | heruntergeladener Code der Pakete und der erzeugte Autoloader | nein, wird bei der Installation erzeugt |

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.

```json
{
    "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](https://phpsos.de/php/namespaces-autoloading/); einen Überblick über alle Standards gibt die Seite [PSR-Standards](https://phpsos.de/php/psr-standards/).

```php
<?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.

```bash
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](https://phpsos.de/ratgeber/composer-abhaengigkeiten-pruefen/).

> **Wichtig:**
> Ein grünes `composer audit` sagt nichts über den Patchstand von PHP. Prüfen Sie die PHP-Laufzeit getrennt, zum Beispiel mit unserem [PHP-Patch-Service](https://phpsos.de/leistungen/php-patch-service/).

## 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

**Muss die composer.lock ins Git-Repository?**  
Ja. Die Composer-Dokumentation empfiehlt ausdrücklich, die composer.lock zu committen. Nur so installieren Entwicklung, CI und Produktion exakt dieselben Paketversionen.

**Was ist der Unterschied zwischen composer install und composer update?**  
install installiert die Versionen, die in der composer.lock festgehalten sind. update löst die Abhängigkeiten neu auf, holt passende neuere Versionen und schreibt die composer.lock neu. Auf dem Produktionsserver gehört nur install hin.

**Schließt ein Composer-Update die PHP2Shell-Lücke?**  
Nein. Composer verwaltet Bibliotheken Ihrer Anwendung, nicht den PHP-Interpreter. PHP2Shell wird nur durch ein Update der PHP-Laufzeit auf eine behobene Version und den Neustart aller PHP-Prozesse geschlossen.

**Wo sollte der vendor-Ordner liegen?**  
Idealerweise außerhalb des öffentlich erreichbaren Webverzeichnisses. Viele Frameworks legen dafür nur einen public-Ordner in den Webroot, während vendor eine Ebene darüber liegt.

## Quellen

- [Composer: Basic usage](https://getcomposer.org/doc/01-basic-usage.md)
- [Composer: Command-line interface](https://getcomposer.org/doc/03-cli.md)
- [Composer: The composer.json schema](https://getcomposer.org/doc/04-schema.md)