Magento Security Scan Tool richtig nutzen und interpretieren

1. Was das Magento Security Scan Tool ist und wie die Registrierung funktioniert

Das Magento Security Scan Tool ist ein kostenloser, von Adobe betriebener Dienst, der öffentlich erreichbare Magento Shops automatisiert von außen prüft, ohne Zugriff auf Server oder Quellcode zu benötigen. Der Scan läuft ausschließlich gegen die öffentlich sichtbare Oberfläche des Shops, ähnlich wie ein externer Besucher oder ein Bot die Seite sehen würde. Registriert wird ein Shop unter security.magento.com über den Menüpunkt "Add Site", wobei zunächst nur die Domain hinterlegt wird.

Vor dem ersten Scan verlangt das Tool einen Eigentumsnachweis für die Domain, entweder über eine HTML-Verifizierungsdatei im Webroot oder einen Meta-Tag auf der Startseite. Erst nach erfolgreicher Verifizierung wird die Domain für wiederkehrende Scans freigeschaltet. Diese Hürde verhindert, dass Dritte fremde Shops ohne Erlaubnis scannen und dabei möglicherweise sensible Informationen über Schwachstellen einsehen, bevor der eigentliche Betreiber davon erfährt.

#!/usr/bin/env bash
# Verify the domain-ownership file is publicly reachable before
# registering the site at https://security.magento.com/
set -euo pipefail

DOMAIN="shop.example.com"
VERIFICATION_FILE="magento-security-scan-verification.html"

# The verification file must be placed in the webroot so the
# scan tool can confirm domain ownership before the first scan
status=$(curl -s -o /dev/null -w "%{http_code}" "https://${DOMAIN}/${VERIFICATION_FILE}")

if [[ "$status" == "200" ]]; then
  echo "[OK] Verification file is reachable, ready to register at security.magento.com"
else
  echo "[ERROR] Verification file returned HTTP ${status}, check webroot deployment" >&2
  exit 1
fi

2. Was das Tool konkret prüft: CVEs, Dateiberechtigungen, exponierte Dateien

Der Kern des Scans ist der Abgleich der erkannten Magento Version und installierter Patches gegen die öffentliche Datenbank bekannter Schwachstellen. Das Tool erkennt die Version meist über charakteristische Response Header, statische Asset Pfade oder Fingerprints im HTML und vergleicht sie gegen die Liste veröffentlichter Security Patches und CVEs. Fehlt ein kritischer Patch, taucht das entsprechende CVE mit Schweregrad im Report auf.

Zusätzlich prüft das Tool auf typische Konfigurationsfehler: unsichere Dateiberechtigungen, die von außen erkennbar sind, sowie öffentlich erreichbare, eigentlich schützenswerte Pfade wie .git Verzeichnisse, .env Dateien, Composer Lock Dateien oder Backup Archive im Webroot. Solche exponierten Dateien verraten oft Datenbank Zugangsdaten, interne Pfade oder die exakte Paketversion und sind ein beliebtes erstes Ziel automatisierter Angreifer-Bots, die das Internet systematisch nach genau diesen Mustern durchsuchen.

{
  "scan_id": "b41f9e7a-2026-07-12",
  "target": "https://shop.example.com",
  "scanned_at": "2026-07-12T03:00:00Z",
  "summary": { "critical": 1, "high": 2, "medium": 3, "low": 1 },
  "findings": [
    {
      "id": "PATCH-2024-0007",
      "category": "patch_status",
      "severity": "critical",
      "title": "Missing security patch for remote code execution",
      "description": "Installed version is missing a patch that fixes an unauthenticated remote code execution issue.",
      "recommendation": "Apply the corresponding composer security patch and redeploy."
    },
    {
      "id": "EXPOSED-FILE-002",
      "category": "sensitive_file",
      "severity": "high",
      "title": "Exposed .git directory",
      "description": "The .git directory is reachable from the public webroot and can leak source code and history.",
      "recommendation": "Block access via webserver rule or move the repository outside the webroot."
    }
  ]
}

3. Wiederkehrende Scans einrichten und Benachrichtigungen konfigurieren

Nach der Verifizierung lässt sich pro registrierter Domain ein Scan Intervall festlegen, in der Praxis meist wöchentlich. Ein einmaliger Scan liefert nur eine Momentaufnahme, während wiederkehrende Scans Regressionen erkennen, etwa wenn ein Deployment versehentlich eine .env Datei ins öffentliche Verzeichnis kopiert oder ein Patch durch ein späteres Update wieder rückgängig gemacht wird.

Für jede registrierte Domain lässt sich eine E-Mail-Adresse hinterlegen, an die nach jedem Scan eine Zusammenfassung geschickt wird. Diese Benachrichtigung sollte an eine Gruppen-Adresse gehen, die vom gesamten verantwortlichen Team gelesen wird, nicht an eine einzelne Person, die das Unternehmen später verlässt. Sinnvoll ist außerdem, den Empfang der Mails in ein Ticket-System oder einen Slack-Kanal weiterzuleiten, damit neue Befunde nicht in einem übervollen Postfach untergehen.

4. Den Bericht lesen und Befunde nach Schweregrad priorisieren

Der Report gliedert Befunde typischerweise in Kategorien wie Patch Status, Malware, Dateisystem und Konfiguration, jeweils mit einer Einstufung in Schweregrade wie kritisch, hoch, mittel und niedrig. Diese Einstufung orientiert sich meist am CVSS Score der zugrunde liegenden Schwachstelle und an der Ausnutzbarkeit ohne Authentifizierung. Kritische und hohe Befunde, insbesondere fehlende Patches für Remote Code Execution Lücken, gehören immer an die Spitze der Priorisierung.

Bei der Priorisierung hilft eine einfache Matrix aus Schweregrad und tatsächlicher Angriffsfläche: Ein kritischer Befund auf einer öffentlich erreichbaren Checkout Seite wiegt schwerer als derselbe Befund auf einem intern genutzten Admin Endpunkt hinter einer IP-Beschränkung. Wichtig ist, den Report nicht isoliert zu betrachten, sondern gegen die eigene Systemlandschaft zu spiegeln, bevor Ressourcen für die Behebung eingeplant werden.

5. Häufige Findings und wie man sie behebt

Die häufigsten Findings in der Praxis sind fehlende Security Patches, die einfach durch Anwenden des entsprechenden Composer Updates oder Quality Patches behoben werden, gefolgt von exponierten .git Verzeichnissen, die durch eine Webserver Regel blockiert oder besser durch Deployment außerhalb des Webroots vollständig vermieden werden. Auch offen erreichbare phpinfo Dateien oder Debug Endpunkte, die in der Entwicklung nützlich waren, aber vor dem Go-Live vergessen wurden, tauchen regelmäßig auf.

Für Dateiberechtigungs Findings gilt die Grundregel, dass Verzeichnisse mit 750 und Dateien mit 640 Rechten für die meisten Magento Installationen ausreichen, während world-writable Berechtigungen (777) fast nie notwendig sind und Angreifern nach einem ersten Fußfassen das Nachladen von Schadcode erheblich erleichtern. Nach jeder Behebung lohnt sich ein manueller Rescan über das Dashboard, statt auf den nächsten geplanten Lauf zu warten.

#!/usr/bin/env bash
# Internal check mirroring the Security Scan Tool's file permission checks
set -euo pipefail

MAGENTO_ROOT="/var/www/html"

echo "Checking for world-writable files..."
find "$MAGENTO_ROOT" -type f -perm -o+w -not -path "*/var/*" -not -path "*/generated/*"

echo "Checking for world-writable directories..."
find "$MAGENTO_ROOT" -type d -perm -o+w -not -path "*/var/*" -not -path "*/generated/*"

echo "Checking for publicly exposed sensitive files..."
for path in ".git/config" ".env" "app/etc/env.php" "var/log/exception.log"; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://shop.example.com/${path}")
  if [[ "$code" == "200" ]]; then
    echo "[EXPOSED] ${path} is publicly reachable (HTTP ${code})" >&2
  fi
done

6. Falsch-Positive erkennen und Befunde manuell verifizieren

Wie jedes automatisierte Scan Tool erzeugt auch das Magento Security Scan Tool gelegentlich Falsch-Positive, etwa wenn ein CDN oder Reverse Proxy die tatsächliche Backend Version verschleiert und das Tool eine ältere, bereits gepatchte Version vermutet. Auch individuell modifizierte Response Header, die zu Debugging Zwecken gesetzt wurden, können die Versionserkennung in die Irre führen und einen Patch Befund auslösen, der in Wirklichkeit nicht zutrifft.

Vor jeder Eskalation an das Team lohnt sich eine manuelle Verifikation: den tatsächlich installierten Patch Level über bin/magento --version und die Composer Lock Datei prüfen, betroffene Pfade händisch mit curl abrufen und das Ergebnis mit dem Report vergleichen. Nur bestätigte Befunde sollten in die Priorisierung einfließen, unbestätigte Findings sollten dennoch dokumentiert und beim nächsten Scan erneut geprüft werden, statt sie stillschweigend zu ignorieren.

7. Grenzen des Tools: kein vollständiger Penetrationstest

Das Magento Security Scan Tool ist bewusst breit statt tief angelegt: Es prüft bekannte Muster gegen eine Datenbank, führt aber keine aktive Ausnutzung von Schwachstellen durch und interagiert nicht mit Formularen, Checkout Prozessen oder authentifizierten Bereichen. Schwachstellen in individuell entwickeltem Code, etwa in einem selbst geschriebenen Modul oder einer angepassten Checkout Logik, werden grundsätzlich nicht erkannt, weil sie in keiner öffentlichen Signatur Datenbank existieren.

Ebenso bleiben Business Logic Fehler außen vor, etwa ob ein Rabattcode mehrfach einlösbar ist, ob Preise clientseitig manipulierbar sind oder ob ein Kunde auf Bestelldaten anderer Kunden zugreifen kann. Solche Schwachstellen erfordern menschliches Verständnis der Geschäftslogik und lassen sich nicht allein durch Signaturabgleich aufdecken. Das Tool ist ein guter Ausgangspunkt, aber kein Ersatz für strukturierte Sicherheitsprüfungen mit menschlicher Expertise.

8. Ergänzende Tools und Prozesse für vollständige Abdeckung

Statische Codeanalyse mit Tools wie PHPStan oder spezialisierten SAST Scannern deckt Schwachstellen im eigenen Code auf, bevor er überhaupt deployt wird, etwa unsichere SQL Zusammensetzung, fehlende Escaping Aufrufe oder unsichere Deserialisierung. composer audit ergänzt das um eine laufende Prüfung aller Third Party Abhängigkeiten gegen bekannte Advisories, direkt in der lokalen Entwicklungsumgebung oder der CI Pipeline, lange bevor ein externer Scan die veraltete Bibliothek überhaupt bemerken würde.

Eine Web Application Firewall (WAF) fängt Angriffsversuche in Echtzeit ab, unabhängig davon, ob die zugrunde liegende Schwachstelle bereits gepatcht wurde, und liefert zusätzlich wertvolle Logs über tatsächliche Angriffsmuster. Ein jährlicher, von zertifizierten Testern durchgeführter Penetrationstest schließlich deckt Business Logic Schwachstellen und Lücken in Custom Code auf, die weder das Scan Tool noch automatisierte Werkzeuge finden können. Diese vier Bausteine ergänzen sich, statt sich zu ersetzen.

#!/usr/bin/env bash
# composer audit as a complement to the external scan, run in CI
set -euo pipefail

cd /var/www/html

# Fail the pipeline on any advisory of severity high or critical
composer audit --format=json > composer-audit-report.json

critical_count=$(jq '[.advisories[][] | select(.severity == "critical" or .severity == "high")] | length' composer-audit-report.json)

if [[ "$critical_count" -gt 0 ]]; then
  echo "[FAIL] ${critical_count} high or critical severity advisories found" >&2
  exit 1
fi

echo "[OK] No high or critical severity advisories"

9. Integration in einen regelmäßigen Security Review Rhythmus

Der größte Nutzen entsteht, wenn das Security Scan Tool nicht isoliert betrachtet wird, sondern Teil eines wiederkehrenden Rhythmus ist: wöchentlicher externer Scan, monatlicher composer audit Lauf in der CI Pipeline, vierteljährliches internes Review der Dateiberechtigungen und Zugriffsrechte sowie ein jährlicher externer Penetrationstest. Jede Ebene deckt eine andere Angriffsfläche ab und die Kombination reduziert die Zeit, in der eine Schwachstelle unentdeckt bleibt, erheblich.

Wichtig ist, Verantwortlichkeiten klar zuzuweisen: Wer erhält die Scan Mails, wer priorisiert Befunde, wer setzt Patches um und wer bestätigt die Behebung im nächsten Rescan. Ohne definierten Prozess versanden selbst gute Scan Ergebnisse in unbeachteten Postfächern. Ein einfaches Ticket pro kritischem oder hohem Befund, verknüpft mit einer Frist, macht den gesamten Prozess nachvollziehbar und auditierbar.

# /etc/cron.d/security-internal-checks
# Runs weekly internal checks that complement the external
# Magento Security Scan Tool, offset from the external scan window

# min  hour  day  month  weekday  user    command
0      3     *    *      1        deploy  /usr/local/bin/check-file-permissions.sh >> /var/log/security/permissions.log 2>&1
30     3     *    *      1        deploy  /usr/local/bin/composer-audit-ci.sh >> /var/log/security/composer-audit.log 2>&1
0      4     *    *      1        deploy  mail -s "Weekly internal security check" security-team@example.com < /var/log/security/permissions.log

Der Scan deckt einen wichtigen, aber begrenzten Ausschnitt der Angriffsfläche ab. Die folgende Übersicht zeigt, wo das Tool zuverlässig ist und wo eine bewusste Ergänzung notwendig bleibt.

In der Praxis ergänzen sich die Zeilen dieser Tabelle: Der Scan liefert eine breite, kostenlose Grundabsicherung gegen bekannte Muster, während jede fehlende Zeile in der mittleren Spalte auf einen Bereich hinweist, der ohne zusätzliche Maßnahme ungeprüft bleibt. Wer beide Spalten zusammen betrachtet, erkennt schnell, welches Budget in welches Werkzeug fließen sollte.

10. Zusammenfassung

Das Magento Security Scan Tool ist ein kostenloser, leicht einzurichtender erster Baustein der Shop-Sicherheit: Domain registrieren, Eigentum verifizieren, wiederkehrenden Scan mit E-Mail-Benachrichtigung aktivieren und den Report regelmäßig nach Schweregrad und tatsächlicher Angriffsfläche priorisieren. Die häufigsten Findings, fehlende Patches, exponierte .git oder .env Dateien und unsichere Dateiberechtigungen, lassen sich meist innerhalb weniger Stunden beheben und sollten nach der Korrektur über einen manuellen Rescan bestätigt werden.

Gleichzeitig ist das Tool explizit kein vollständiger Penetrationstest: Business-Logic-Fehler, Schwachstellen in Custom Code und komplexe Angriffsketten bleiben unentdeckt. Wer das Scan Tool mit statischer Codeanalyse, composer audit, einer Web Application Firewall und jährlichen manuellen Pentests kombiniert und alles in einen festen Review-Rhythmus einbettet, erreicht ein deutlich robusteres Sicherheitsniveau als mit jedem einzelnen Baustein für sich.

11. FAQ: Magento Security Scan Tool