Dependency-Scanning mit Composer Audit und Co.

1. Warum Dependency-Schwachstellen in Magento- und PHP-Projekten zählen

Ein typisches Magento 2 Projekt bindet über die composer.json vielleicht 40 bis 60 Pakete direkt ein. Im tatsächlich installierten Abhängigkeitsbaum stehen aber, wenn man alle transitiven Abhängigkeiten mitzählt, häufig 300 bis 500 Composer-Pakete im vendor-Verzeichnis. Jedes einzelne davon ist potenziell angreifbar, unabhängig davon, ob der eigene Code jemals direkt damit interagiert. Bekannt gewordene Schwachstellen in weit verbreiteten Bibliotheken wie guzzlehttp/guzzle, symfony/http-foundation oder monolog/monolog werden von automatisierten Scannern binnen Stunden nach Veröffentlichung eines CVE im großen Stil im Internet gesucht. Ein gezielter Angriff auf einen bestimmten Shop ist dafür gar nicht nötig, es reicht, dass eine verwundbare Versionsnummer über einen HTTP-Header oder ein öffentlich sichtbares composer.lock erkennbar ist.

Magento-spezifisch kommt hinzu, dass viele Drittanbieter-Extensions eigene Composer-Abhängigkeiten mit engen Versionsconstraints mitbringen, die ein composer update über Monate blockieren, weil ein Update sonst zu Versionskonflikten führt. Genau in dieser Konstellation bleiben veraltete, verwundbare Pakete unbemerkt im Projekt liegen, oft über Jahre hinweg, weil niemand regelmäßig prüft, ob eine bereits installierte Version zwischenzeitlich als unsicher eingestuft wurde. Dependency-Scanning schließt genau diese Lücke: Es prüft nicht den eigenen Code, sondern systematisch, ob eine der eingebundenen Versionen in einer öffentlichen Advisory-Datenbank als verwundbar gelistet ist, und macht damit ein Risiko sichtbar, das ohne Scan komplett unbemerkt bliebe.

2. composer audit: eingebauter Befehl, Nutzung und Output

Seit Composer 2.4 gehört composer audit als eingebauter Befehl zur Standardinstallation, ganz ohne zusätzliches Plugin. Der Befehl vergleicht die in composer.lock fixierten Versionen gegen die FriendsOfPHP Security Advisories Datenbank, eine kuratierte Sammlung bekannter PHP-Paket-Schwachstellen, die auch Packagist selbst als Datenquelle für den Sicherheitsstatus eines Pakets nutzt. Der einfache Aufruf composer audit reicht für eine sofortige, menschenlesbare Übersicht mit Paketname, betroffenem Versionsbereich, Schweregrad und Link zur jeweiligen Advisory.

Für die CI-Integration ist composer audit --format=json --locked die relevante Variante: --locked liest ausschließlich die composer.lock, ohne den Vendor-Ordner tatsächlich zu installieren, was den Scan deutlich beschleunigt und auch in schlanken Build-Containern ohne volle Dependency-Installation funktioniert. Das JSON-Ergebnis liefert zwei Top-Level-Schlüssel: advisories mit den eigentlichen Schwachstellenfunden je Paket, und abandoned mit Paketen, die als nicht mehr gepflegt markiert sind, was ein eigenes, subtileres Risiko darstellt. composer audit gibt bei gefundenen Advisories einen Exit-Code ungleich null zurück, wodurch sich der Befehl ohne zusätzliches Tooling direkt als CI-Gate verwenden lässt.

# Run composer audit against the locked dependency tree
composer audit

# Machine-readable output for tooling and CI pipelines
composer audit --format=json --locked

# Example JSON output (abbreviated) for a vulnerable guzzlehttp/psr7 version
{
    "advisories": {
        "guzzlehttp/psr7": [
            {
                "advisoryId": "PKSA-h4kf-cchx-w9wf",
                "packageName": "guzzlehttp/psr7",
                "affectedVersions": "<1.9.1|>=2,<2.4.5",
                "title": "Bypass of file:// URI validation in MimeType detection",
                "cve": "CVE-2023-29197",
                "link": "https://github.com/advisories/GHSA-wxmh-65f7-jcvw",
                "severity": "medium"
            }
        ]
    },
    "abandoned": {
        "swiftmailer/swiftmailer": null
    }
}

# Exit code 1 signals at least one open advisory, useful for CI gating
echo "Exit code: $?"

Ein wichtiges Detail für Magento-Projekte: composer audit prüft standardmäßig auch require-dev Pakete mit. Für reine Produktions-Deployments, bei denen PHPUnit, Symfony VarDumper oder andere Dev-Tools ohnehin nicht mit ausgeliefert werden, kann --no-dev die Zahl der gemeldeten Advisories deutlich reduzieren und den Fokus auf tatsächlich produktionsrelevante Pakete lenken. Für die tägliche CI-Pipeline empfiehlt sich trotzdem ein separater Lauf ohne --no-dev, weil auch eine kompromittierte Dev-Abhängigkeit während des Build-Prozesses selbst zum Risiko werden kann, etwa durch eine bösartige Post-Install-Hook-Ausführung.

3. Severity richtig einordnen: CVSS, Exploitability, Reachability

Jede Advisory in der composer audit Ausgabe trägt einen Schweregrad, meist low, medium, high oder critical, abgeleitet aus dem Common Vulnerability Scoring System (CVSS). CVSS bewertet eine Schwachstelle anhand mehrerer Achsen: Angriffsvektor (lokal oder über das Netzwerk erreichbar), Angriffskomplexität, benötigte Rechte und die Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit. Ein hoher CVSS-Wert bedeutet, dass die Schwachstelle theoretisch schwerwiegend ist, sagt aber nichts darüber aus, ob der eigene Code den verwundbaren Codepfad überhaupt jemals aufruft.

Genau hier setzt das Konzept der Reachability an: Eine kritische Deserialisierungslücke in einer XML-Bibliothek ist für ein Projekt, das diese Bibliothek nur zum Schreiben, nie zum Parsen fremder Eingaben nutzt, in der Praxis oft irrelevant. Die realistische Einschätzung erfordert deshalb immer einen kurzen Blick in den betroffenen Code: Wird die verwundbare Funktion mit Nutzereingaben aufgerufen, oder nur intern mit statischen, vertrauenswürdigen Daten? Exploitability ergänzt diese Frage um die Verfügbarkeit von öffentlich bekanntem Exploit-Code oder aktiver Ausnutzung in freier Wildbahn, Informationen, die in der Advisory selbst oder über Referenzen wie die GitHub Security Advisory Database meist verlinkt sind.

Die Faustregel für Magento-Teams: critical und high Advisories mit Netzwerk-Angriffsvektor und bekanntem Exploit werden immer priorisiert und zeitnah behoben, unabhängig von der Reachability-Einschätzung, weil das Risiko einer Fehleinschätzung zu hoch ist. Bei medium und low Advisories lohnt sich die zusätzliche Reachability-Prüfung, um Aufwand gezielt dort einzusetzen, wo er tatsächlich Risiko reduziert, statt jede einzelne Fundstelle mit gleicher Priorität abzuarbeiten.

4. Roave Security Advisories: Schwachstellen schon bei der Installation verhindern

Während composer audit nachträglich prüft, ob bereits installierte Pakete verwundbar sind, verfolgt roave/security-advisories einen präventiven Ansatz. Das Paket enthält selbst keinen Code, sondern ausschließlich eine composer.json mit expliziten conflict-Einträgen für jede bekannte verwundbare Versionsspanne quer über hunderte PHP-Pakete. Wird roave/security-advisories als require-dev Abhängigkeit eingebunden, verweigert Composer automatisch die Installation oder das Update auf eine Version, die in dieser Conflict-Liste als verwundbar markiert ist, noch bevor der Code überhaupt im Projekt landet.

{
    "require-dev": {
        "roave/security-advisories": "dev-latest",
        "phpunit/phpunit": "^10.5"
    },
    "config": {
        "allow-plugins": {
            "dealerdirect/phpcodesniffer-composer-installer": true
        },
        "sort-packages": true
    },
    "scripts": {
        "post-update-cmd": [
            "@php bin/magento setup:di:compile"
        ]
    }
}

Der entscheidende Unterschied zu composer audit: Roave verhindert das Problem proaktiv zum Zeitpunkt von composer require oder composer update, während composer audit es erst im Nachhinein aufdeckt, wenn die verwundbare Version bereits im composer.lock steht. Beide Ansätze ergänzen sich, ersetzen sich aber nicht gegenseitig: Roave schützt nicht rückwirkend gegen bereits installierte Altlasten, und composer audit greift nicht ein, bevor ein Update tatsächlich ausgeführt wird. Die dev-latest Variante von Roave wird kontinuierlich aktualisiert, sodass neue Advisories automatisch in die Conflict-Liste einfließen, sobald sie veröffentlicht werden, ohne dass das eigene Projekt manuell etwas tun muss.

In der Praxis zeigt sich ein Nachteil: Roave kann bei sehr eng gefassten Versionsconstraints anderer Pakete zu Auflösungskonflikten führen, wenn ein Projekt aus guten Gründen auf einer als verwundbar markierten Version verharren muss, etwa weil ein Fix nicht kompatibel mit der genutzten PHP- oder Magento-Version ist. Für diesen Fall bietet Composer die Möglichkeit, einzelne conflict-Einträge über eine eigene replace-Direktive in der Projekt-composer.json gezielt zu überschreiben, was dokumentiert und mit einer bewussten Risikoentscheidung verknüpft werden sollte, nicht stillschweigend erfolgen darf.

5. CI-Integration mit GitHub Actions

Ein composer audit, der nur gelegentlich manuell auf der eigenen Maschine läuft, verliert seinen Wert, sobald ein Entwickler den Schritt vergisst oder unter Zeitdruck überspringt. Die zuverlässige Lösung ist ein automatisierter CI-Job, der bei jedem Pull Request und zusätzlich auf einem festen Zeitplan läuft. Der Zeitplan ist wichtig, weil neue Advisories jederzeit veröffentlicht werden können, auch für Code, der sich seit Wochen nicht mehr geändert hat: Ein bereits gemergter Stand kann also nachträglich verwundbar werden, ohne dass ein neuer Commit das auslöst.

name: Dependency Audit

on:
  pull_request:
  schedule:
    - cron: "0 6 * * 1" # weekly Monday scan, catches new advisories on unchanged code

jobs:
  composer-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: "8.4"
          tools: composer:v2

      - name: Install dependencies (locked, no scripts)
        run: composer install --no-scripts --prefer-dist

      - name: Run composer audit
        run: composer audit --locked --format=json > audit-report.json
        continue-on-error: true

      - name: Evaluate audit report against severity threshold
        run: bash ./bin/ci-audit-gate.sh audit-report.json high

      - name: Upload audit report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: composer-audit-report
          path: audit-report.json

Wichtig für Magento-Projekte ist die Installation mit --no-scripts, weil composer install sonst versucht, projektspezifische Post-Install-Hooks wie eine Magento-Modul-Kompilierung auszuführen, was in einem schlanken Audit-Job unnötige Laufzeit kostet und zusätzliche Voraussetzungen wie eine funktionierende Datenbankverbindung erfordern würde, die für einen reinen Abhängigkeits-Scan gar nicht nötig sind. Das Hochladen des JSON-Reports als Artefakt sorgt dafür, dass auch bei einem fehlgeschlagenen Audit-Job die konkreten Advisory-Details im GitHub-Interface nachvollziehbar bleiben, statt nur einen roten Status ohne Kontext zu zeigen.

6. CI-Integration mit GitLab CI und Allowlist für akzeptierte Risiken

In GitLab CI folgt der composer_audit Job demselben Grundprinzip, ergänzt aber häufig eine projektspezifische Allowlist für Advisories, die bewusst als akzeptables Risiko eingestuft wurden. Ohne diesen Mechanismus führt jede unfixbare oder bewusst hingenommene Advisory dazu, dass die Pipeline dauerhaft rot bleibt, was Teams schnell dazu verleitet, den gesamten Audit-Schritt zu deaktivieren, statt ihn gezielt zu verfeinern, ein klassisches Alert-Fatigue-Problem.

composer_audit:
  stage: test
  image: php:8.4-cli
  before_script:
    - curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
    - composer install --no-scripts --prefer-dist
  script:
    - composer audit --locked --format=json > audit-report.json || true
    - |
      # Filter out advisories explicitly accepted in security/allowlist.json
      jq --slurpfile allow security/allowlist.json '
        .advisories
        | to_entries
        | map(.value |= map(select(.advisoryId as $id | ($allow[0].acceptedAdvisories | index($id)) | not)))
        | map(select(.value | length > 0))
      ' audit-report.json > unresolved-advisories.json
    - |
      if [ "$(jq "length" unresolved-advisories.json)" -gt 0 ]; then
        echo "Unresolved advisories found, failing pipeline:"
        cat unresolved-advisories.json
        exit 1
      fi
  artifacts:
    when: always
    paths:
      - audit-report.json
      - unresolved-advisories.json

Die Allowlist selbst liegt als versionierte JSON-Datei im Repository, etwa unter security/allowlist.json, mit den Feldern acceptedAdvisories für die Advisory-IDs, reason für die fachliche Begründung und reviewDate für das Datum der letzten Prüfung. Dieses Vorgehen macht die Risikoakzeptanz nachvollziehbar und versionskontrolliert, statt sie in einer stillschweigenden Ausnahme im Kopf eines einzelnen Entwicklers zu belassen. Ein regelmäßiger Review-Termin, etwa quartalsweise, prüft, ob eine akzeptierte Advisory inzwischen doch einen Fix bekommen hat und die Allowlist entsprechend bereinigt werden kann.

7. Unfixbare transitive Abhängigkeiten und False Positives

Nicht jede gemeldete Advisory lässt sich mit einem einfachen composer update beheben. Eine verwundbare Version kann tief in der transitiven Abhängigkeitskette eines Drittanbieter-Moduls stecken, dessen Maintainer selbst noch keinen kompatiblen Fix veröffentlicht hat. In diesem Fall hilft composer why-not paketname version, um die genaue Kette sichtbar zu machen, welches direkte Paket welche verwundbare Transitivabhängigkeit erzwingt, und composer prohibits, um herauszufinden, welche Version tatsächlich benötigt würde, um den Konflikt aufzulösen.

False Positives entstehen in der Praxis vor allem durch drei Muster: Advisories für Codepfade, die im eigenen Projekt nie erreicht werden, Advisories für require-dev-only Pakete, die nie in Produktion ausgeliefert werden, und veraltete Advisory-Metadaten, bei denen ein Fix zwar längst existiert, die Datenbank aber die neue, sichere Version noch nicht als solche markiert hat. Jeder dieser Fälle rechtfertigt eine dokumentierte Ausnahme über die Allowlist, aber keiner rechtfertigt, den Scan komplett zu deaktivieren, weil sich die Einschätzung mit jedem Advisory-Update wieder ändern kann.

Ein pragmatischer Zwischenschritt bei unfixbaren Paketen: prüfen, ob eine alternative Bibliothek mit vergleichbarem Funktionsumfang existiert, die das verwundbare Paket ersetzen kann, ohne auf ein komplettes Modul-Update zu warten. composer.json erlaubt zudem gezielte replace-Einträge, um ein Paket durch eine eigene, gepatchte Fork-Version zu ersetzen, eine Notlösung, die dokumentiert und beim nächsten offiziellen Fix wieder zurückgebaut werden sollte.

8. Triage-Workflow und Risikoakzeptanz dokumentieren

Ein wiederholbarer Triage-Workflow verhindert, dass Dependency-Scanning zum ignorierten Pflichttermin verkommt. Der erste Schritt nach jedem Scan-Ergebnis ist die Klassifizierung: sofort fixbar, fixbar mit Aufwand, oder aktuell unfixbar. Sofort fixbare Advisories, meist ein einfaches composer update paketname, werden direkt im selben Pull Request behoben. Advisories mit größerem Aufwand, etwa ein Major-Version-Update mit Breaking Changes, werden je nach Schweregrad als eigenes Ticket mit Frist angelegt.

#!/usr/bin/env bash
# ci-audit-gate.sh - fail CI only when advisories reach a given severity
set -euo pipefail

REPORT_FILE="${1:?Usage: ci-audit-gate.sh <report.json> <min-severity>}"
MIN_SEVERITY="${2:-high}"

declare -A SEVERITY_RANK=( [low]=1 [medium]=2 [high]=3 [critical]=4 )
threshold="${SEVERITY_RANK[$MIN_SEVERITY]}"

# Extract every advisory severity from the composer audit JSON report
mapfile -t severities < <(jq -r '.advisories[][] | .severity // "medium"' "$REPORT_FILE")

blocking=0
for sev in "${severities[@]}"; do
  rank="${SEVERITY_RANK[$sev]:-2}"
  if (( rank >= threshold )); then
    blocking=$((blocking + 1))
  fi
done

total="${#severities[@]}"
echo "Found $total advisories, $blocking at or above severity '$MIN_SEVERITY'"

if (( blocking > 0 )); then
  echo "Blocking advisories detected, failing pipeline" >&2
  exit 1
fi

echo "No advisories at or above threshold, pipeline continues"
exit 0

Für unfixbare Advisories ist die Dokumentation der Risikoakzeptanz der entscheidende Schritt, der in der Praxis am häufigsten übersprungen wird. Eine vollständige Risikoakzeptanz-Notiz enthält mindestens vier Angaben: die Advisory-ID, die konkrete Begründung, warum das Risiko im Projektkontext als akzeptabel eingestuft wird, den Namen der verantwortlichen Person und ein Wiedervorlagedatum. Ohne diese Dokumentation verschwindet das Wissen über eine bewusste Entscheidung innerhalb weniger Monate, und ein neuer Teamkollege trifft dieselbe Analyse erneut oder übersieht das Risiko komplett, weil es nirgendwo sichtbar vermerkt ist.

Das Schwellenwert-Skript aus dem Codebeispiel oben trennt bewusst zwischen Report-Erstellung und Bewertung: composer audit selbst kennt kein Konzept von Ausnahmen oder Schwellenwerten, es meldet jede gefundene Advisory gleichwertig. Die Bewertungslogik gehört deshalb in ein separates, versioniertes Skript, das zusammen mit der Allowlist im Repository liegt und bei jeder Änderung denselben Code-Review-Prozess durchläuft wie jeder andere Produktionscode auch.

9. Ergänzende Tools und Vergleich der Scan-Ansätze

Neben composer audit und Roave Security Advisories lohnt sich ein Blick auf ergänzende Werkzeuge. Der ursprüngliche Symfony CLI Security Checker wurde 2022 eingestellt, seine Funktion lebt aber in der Symfony CLI über symfony security:check weiter und nutzt dieselbe FriendsOfPHP Advisory-Datenbank wie composer audit, liefert aber teilweise andere Ausgabeformate für bestehende Tooling-Integrationen. GitHub Dependabot arbeitet grundsätzlich anders: Es scannt nicht nur composer.lock, sondern erstellt automatisch Pull Requests mit vorgeschlagenen Versions-Updates, sobald eine Advisory für ein genutztes Paket veröffentlicht wird, inklusive Changelog-Verweis und Kompatibilitätsscore.

Dependabot und composer audit ergänzen sich gut: Dependabot automatisiert die Update-Vorschläge, composer audit in der CI-Pipeline verifiziert unabhängig davon, dass tatsächlich keine verwundbare Version mehr im composer.lock landet, auch wenn ein Dependabot-Pull-Request aus irgendeinem Grund nicht gemergt wurde. Für Magento-spezifische Pakete jenseits des reinen PHP-Ökosystems bleibt außerdem ein Blick in den Adobe Security Bulletin Feed relevant, weil Magento-Core-Patches teilweise außerhalb des regulären Composer-Advisory-Flusses veröffentlicht werden und eigene Versionsnummern-Schemata verwenden.

In der Praxis ist keiner dieser Ansätze isoliert ausreichend. composer audit in der CI-Pipeline verhindert, dass verwundbarer Code unbemerkt live geht. Roave Security Advisories verhindert, dass er überhaupt erst installiert wird. Dependabot automatisiert die Update-Vorschläge, und eine dokumentierte Triage mit Allowlist sorgt dafür, dass das Team nicht in Scan-Rauschen ertrinkt, sondern sich auf echte, priorisierte Risiken konzentriert.

10. Zusammenfassung

Zuverlässiges Dependency-Scanning für Magento- und PHP-Projekte kombiniert immer mehrere Ebenen: composer audit deckt bereits installierte, verwundbare Versionen im composer.lock auf und lässt sich dank eingebautem JSON-Format und aussagekräftigem Exit-Code ohne Zusatz-Tooling in jede CI-Pipeline integrieren. Roave Security Advisories ergänzt das um eine präventive Ebene, die verwundbare Versionen erst gar nicht ins Projekt lässt. Severity-Werte aus CVSS geben eine erste Priorisierung, sind aber ohne eine Reachability-Einschätzung nur die halbe Wahrheit, weil ein hoher Schweregrad nichts über die tatsächliche Ausnutzbarkeit im eigenen Codepfad aussagt.

Der entscheidende Erfolgsfaktor liegt nicht im Scan selbst, sondern im Umgang mit seinen Ergebnissen. Eine dokumentierte Allowlist mit Begründung und Wiedervorlagedatum verhindert, dass unfixbare transitive Abhängigkeiten oder klare False Positives zur Dauerbaustelle werden. Ein Schwellenwert-Gate, das nur ab einer bestimmten Severity tatsächlich blockiert, hält die CI-Pipeline grün für echte, priorisierte Risiken, statt bei jeder neuen Advisory sofort Alarm zu schlagen. Wer composer audit, Roave Security Advisories, Dependabot und einen dokumentierten Triage-Prozess kombiniert, reduziert das Risiko unbemerkter Schwachstellen erheblich, ohne das Team mit Scan-Rauschen zu überfordern.

11. FAQ: Dependency-Scanning mit Composer Audit