Composer Audit ist ein seit Composer 2.4 integrierter Befehl, der alle installierten PHP Pakete automatisch gegen die Packagist.org Security Advisory API prüft. Der Befehl liest die composer.lock Datei, gleicht jede Paketversion mit der PHP Security Advisories Database ab und gibt bei bekannten Schwachstellen einen Bericht mit CVE Kennung, Schweregrad und betroffenen Versionen aus.
Das Besondere: composer audit beendet sich mit einem Exit Code ungleich Null, wenn Schwachstellen gefunden werden. Damit lässt sich der Befehl direkt in jede CI/CD Pipeline einbauen und blockiert unsichere Deployments automatisch. Seit Composer 2.7 warnt composer audit zusätzlich vor abandoned Packages, also Paketen, die keine Sicherheitsupdates mehr erhalten.
Die Datenbank hinter dem Befehl kombiniert zwei Quellen: das Community Repository FriendsOfPHP/security-advisories und die GitHub Advisory Database. Packagist dedupliziert automatisch und liefert so eine umfassende Abdeckung bekannter PHP Schwachstellen. Für Symfony Projekte, Laravel Anwendungen und jedes andere Composer basierte Setup ist composer audit 2026 das absolute Minimum an Dependency Security.
Wir sind Experten für PHP und helfen Ihnen, Ihre digitalen Herausforderungen zu meistern. Unser erfahrenes Team unterstützt Sie bei PHP Updates, PHP Refactoring und berät Sie remote zu allen Fragen rund um PHP. Mit unseren vollautomatischen CI/CD Deployments und einer robusten Docker-Infrastruktur bringen wir Ihre PHP-Projekte auf das nächste Level. Vertrauen Sie auf unsere Expertise für zuverlässige und skalierbare PHP-Lösungen.
Der einfachste Aufruf ist composer audit im Projektverzeichnis. Composer liest die composer.lock, fragt die Packagist API ab und listet alle betroffenen Pakete mit CVE, Schweregrad und betroffenen Versionsbereichen auf. Der Exit Code entspricht der Anzahl gefundener Advisories, was die Auswertung in Skripten trivial macht.
# Alle installierten Pakete prüfen
composer audit
# Nur Produktionsabhängigkeiten prüfen (ohne require-dev)
composer audit --no-dev
# Audit basierend auf composer.lock ohne Installation
composer audit --locked
# JSON Output für automatisierte Auswertung
composer audit --format=json
# Audit bei composer update automatisch mitlaufen lassen
composer update --audit
Die Option --locked ist besonders praktisch für CI Umgebungen: Sie prüft ausschließlich die composer.lock ohne dass die Pakete tatsächlich installiert sein müssen. Das spart Zeit und Ressourcen in Build Pipelines. Mit --no-dev lassen sich Development Dependencies ausschließen, wenn nur der Produktionsstack relevant ist.
Seit Composer 2.4 läuft bei jedem composer update und composer require automatisch ein verkürztes Audit mit. Diese Kurzversion zeigt nur Advisory IDs und betroffene Versionen. Für den vollständigen Bericht mit CVE Details, Links und Veröffentlichungsdatum muss explizit composer audit aufgerufen werden.
Der größte Mehrwert von composer audit entfaltet sich in automatisierten Build Pipelines. Durch den Non Zero Exit Code bricht jede Standard CI/CD Pipeline automatisch ab, wenn bekannte Schwachstellen in den Dependencies stecken. Kein unsicheres Deployment erreicht die Produktion, ohne dass ein Entwickler die Warnung bewusst quittiert.
# GitHub Actions Beispiel
name: Security Audit
on: [push, pull_request]
jobs:
audit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: shivammathur/setup-php@v2
with:
php-version: 8.4
- run: composer install --no-dev --prefer-dist
- run: composer audit --no-dev
In GitLab CI, Jenkins oder Bitbucket Pipelines funktioniert das identisch: composer audit --locked als eigenen Step einbauen und der Build scheitert bei Schwachstellen automatisch. Teams, die GrumPHP nutzen, können composer audit als Pre Commit Hook konfigurieren und Schwachstellen bereits vor dem Push abfangen.
Für Unternehmen mit strengen Compliance Anforderungen empfiehlt sich ein zweistufiger Ansatz: composer audit blockiert den Build bei kritischen CVEs, während ein wöchentlicher Scheduled Run auch niedrig priorisierte Advisories erfasst. So entsteht ein lückenloses Security Gate ohne den Entwicklungsflow zu bremsen. NCA implementiert diese Security Pipelines als Teil von PHP Update und Refactoring Projekten, inklusive automatisierter Benachrichtigung bei neuen CVEs.
composer audit ist nicht das einzige Werkzeug für PHP Dependency Security, aber das mit der niedrigsten Einstiegshürde. Hier die wichtigsten Alternativen und wie sie sich ergänzen:
composer audit nach der Installation warnt, verhindert Roave die Installation unsicherer Versionen von vornherein. Beide zusammen bilden ein solides Fundament.symfony check:security prüft ebenfalls gegen die FriendsOfPHP Datenbank. Sinnvoll für Teams, die die Symfony CLI bereits im Einsatz haben.composer audit perfekt: Audit fängt Probleme beim Deployment ab, Dependabot zwischen den Deployments.composer audit entsteht ein vollständiges Bild der Dependency Hygiene.Die Empfehlung für 2026: composer audit --locked in jeder CI Pipeline als Pflicht, Roave/SecurityAdvisories als zusätzliche Absicherung und Dependabot für kontinuierliches Monitoring. Wer diese drei Ebenen kombiniert, hat die Supply Chain Security für PHP Projekte im Griff.
Ein aktuelles Beispiel zeigt, warum regelmäßige Composer Updates und composer audit unverzichtbar sind: Im April 2026 wurden zwei kritische Command Injection Schwachstellen im Perforce VCS Treiber von Composer entdeckt. CVE-2026-40176 (CVSS 7.8) und CVE-2026-40261 (CVSS 8.8) ermöglichten Angreifern die Ausführung beliebiger Befehle auf dem Server, wenn ein manipuliertes composer.json mit Perforce Repository Konfiguration verarbeitet wurde.
Die Fixes sind in Composer 2.9.6 und der LTS Version 2.2.27 enthalten. Packagist.org hat die Veröffentlichung von Perforce Metadaten vorsorglich deaktiviert. Dieser Vorfall betrifft nicht nur Teams, die Perforce aktiv nutzen: Auch ohne Perforce Konfiguration waren Systeme potenziell angreifbar.
Die Konsequenz ist klar: composer self-update gehört genauso in die regelmäßige Wartung wie das Update der PHP Abhängigkeiten selbst. Teams, die composer audit in der Pipeline haben, werden bei solchen Vorfällen automatisch gewarnt und können sofort reagieren. NCA unterstützt Unternehmen bei der Einrichtung automatisierter Security Workflows für PHP Projekte, von der Pipeline Konfiguration bis zum Incident Response Prozess. Kontakt: roland@nevercodealone.de | +49 176 24747727.
Finde das passende Angebot für dein Projekt
Anfrage-Konfiguration
Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.
Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.
Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.
Anfrage-Konfiguration
Wähle die Expertise, die dein Projekt jetzt am dringendsten benötigt.
Die wichtigsten Fragen und Antworten rund um composer audit, Security Advisories und PHP Dependency Management 2026.
Composer Audit prüft alle in der composer.lock aufgeführten PHP Pakete gegen die Packagist Security Advisory API. Der Befehl meldet bekannte Schwachstellen mit CVE Kennung, Schweregrad und betroffenen Versionen. Seit Composer 2.7 werden auch abandoned Packages gemeldet.
Fügen Sie composer audit --locked als eigenen Step in Ihre Pipeline ein. Der Non Zero Exit Code sorgt dafür, dass der Build bei Schwachstellen automatisch fehlschlägt. In GitHub Actions, GitLab CI oder Jenkins funktioniert das ohne zusätzliche Konfiguration.
Composer Audit fragt die Packagist.org Security Advisory API ab, die Daten aus zwei Quellen aggregiert: FriendsOfPHP/security-advisories und die GitHub Advisory Database. Packagist dedupliziert automatisch und liefert eine umfassende Abdeckung.
Ja. Mit der Option --locked werden ausschließlich Paketinformationen aus der lokalen composer.lock gegen die öffentliche Packagist API geprüft. Es werden keine projektspezifischen Daten übertragen. Die API ist aus Deutschland erreichbar und wird von der Packagist Conductors GmbH in Berlin betrieben.
Composer Audit ist ein lokaler CLI Befehl, der beim Deployment prüft. Dependabot ist ein GitHub Service, der kontinuierlich überwacht und automatisch Pull Requests erstellt. Beide ergänzen sich: Audit sichert den Deployment Zeitpunkt ab, Dependabot die Zeit dazwischen.
Der Exit Code entspricht der Anzahl gefundener Security Advisories. Ein Exit Code von 0 bedeutet keine bekannten Schwachstellen. Jeder Wert größer 0 signalisiert mindestens eine bekannte Schwachstelle in den installierten Paketen.
Ja, mit composer audit --no-dev werden nur Produktionsabhängigkeiten geprüft. Development Dependencies wie PHPUnit oder PHP CS Fixer werden dann übersprungen. Für maximale Sicherheit empfiehlt sich dennoch die Prüfung aller Dependencies.
Composer Audit warnt nach der Installation vor bekannten Schwachstellen. Roave SecurityAdvisories verhindert die Installation verwundbarer Versionen von vornherein durch Composer Conflicts. Beide zusammen bilden ein zweistufiges Sicherheitsnetz.
Bei jedem Deployment automatisch über die CI/CD Pipeline und zusätzlich mindestens wöchentlich als Scheduled Job. Neue Advisories werden laufend veröffentlicht, daher reicht eine einmalige Prüfung nicht aus.
Prüfen Sie ob ein Update für das betroffene Paket verfügbar ist mit composer update paketname. Wenn ein Major Update nötig ist, pinnen Sie zunächst die letzte sichere Minor Version in der composer.json. Bei Paketen ohne Fix: Alternative suchen oder Risiko dokumentiert akzeptieren.
Ja, mit der Option --locked prüft Composer Audit ausschließlich die composer.lock Datei ohne dass Pakete im vendor Verzeichnis installiert sein müssen. Das ist besonders in CI Umgebungen nützlich und spart Build Zeit.
Composer Audit unterstützt die Formate table (Standard), plain, json und summary. Für automatisierte Auswertung in Skripten oder Dashboards eignet sich das JSON Format mit composer audit --format=json.
