So sieht ein Bericht aus dem Code Audit aus, von der ersten bis zur letzten Seite.

Das Portal läuft und bringt Umsatz, aber es baut auf Software, die zwischen 2022 und 2025 die letzten Sicherheitsupdates bekommen hat. Drei Probleme müssen noch diese Woche gelöst werden, vor jeder Upgrade-Arbeit:

1. Der Staging-Server lässt sich aus dem Internet übernehmen. Er ist öffentlich erreichbar, läuft im Debug-Modus und enthält eine Komponente mit einer veröffentlichten Lücke zur Ausführung von Schadcode aus der Ferne (CVE-2021-3129). Auf Staging liegt eine wöchentliche Kopie der Produktionsdatenbank, mit Namen, Adressen und Rechnungen von Kunden.
2. Produktionspasswörter und der Verschlüsselungsschlüssel der Anwendung stehen in der Git-Historie. Jeder, der eine Kopie des Repositorys hat oder einmal hatte, kann sie lesen. Sie wurden seit 2021 nicht geändert.
3. Die Backups liegen auf demselben Server wie die Datenbank und wurden nie zurückgespielt. Ein Plattendefekt oder Ransomware auf diesem Server würde Daten und Backups gemeinsam vernichten.

Alle drei lassen sich in ein bis zwei Tagen schließen, ohne den Anwendungscode zu ändern (Abschnitt 6, Etappe 0).

Das größere Problem auf längere Sicht ist die Plattform selbst: PHP 7.4 (Supportende 28. November 2022) und Laravel 6 (Sicherheitsupdates beendet 6. September 2022). Der Abhängigkeitsscan hat 114 veröffentlichte Security Advisories in 20 Paketen gefunden. Einige lassen sich mit Patch-Releases innerhalb von Laravel 6 beheben, die meisten erst mit dem Upgrade.

Automatisierte Tests gibt es kaum (6,1 % Zeilenabdeckung, keine für die sechs geschäftskritischen Pfade), jede Änderung ist heute also ein Ratespiel. Wir empfehlen Option A: zuerst ein Sicherheitsnetz, dann ein Upgrade in zwei Etappen zum Festpreis auf Laravel 13 mit PHP 8.4, in rund vier Monaten, ab Monat 5 mit Care Standard. Option B (auf Laravel 6 bleiben, mit gepatchtem PHP) kostet dieses Jahr weniger. Wann sie sinnvoll ist, steht in Abschnitt 6.

Im Umfang: Anwendungscode im Repository (Branch main, Commit 4f1c9e2), composer.json und composer.lock, Git-Historie, Konfigurationsdateien, vom Kunden bereitgestellte Serverkonfiguration, Deploy-Skript.

Werkzeuge: composer audit (Composer 2, Advisory-Datenbank von Packagist), PHPStan 2.x ohne Laravel-Erweiterung (Larastan für Laravel 6 gibt es nur für die alte PHPStan-Linie 0.12, deshalb wiederholen wir die Analyse mit Larastan nach dem Framework-Upgrade), Rector 2.x im Probelauf (Dry Run), PHP_CodeSniffer mit PHPCompatibility, PHPUnit mit PCOV für die Testabdeckung, gitleaks für Secrets in der Historie, git log für die Änderungshäufigkeit. Danach eine manuelle Prüfung von Routen, Authentifizierung, Datei-Uploads, PDF-Erzeugung, Queues und Cronjobs.

Nicht im Umfang: Penetrationstests, Lasttests, Prüfung der mobilen App, die Systeme des Zahlungsanbieters und das Netzwerk-Setup des Hosters. Wir haben nichts davon aktiv ausgenutzt. Wenn wir eine Lücke als ausnutzbar bezeichnen, heißt das: Die veröffentlichten Voraussetzungen sind in Ihrer Konfiguration erfüllt.

• 42 PHPUnit-Tests, davon 9 rot auf main. Die Fehler stammen aus 2023, seitdem wurden die Tests nicht mehr ausgeführt.
• Zeilenabdeckung 6,1 %. Abgedeckt sind zwei Hilfsklassen und das Login-Formular.
• Kritische Pfade ohne Test: Buchung anlegen, Preisberechnung, Rechnungserzeugung (PDF), Callback des Zahlungsanbieters, Authentifizierung der Fahrer-API, monatlicher Rechnungsexport (XLSX).
• Keine CI-Pipeline. deploy.sh führt auf der Produktion git pull, composer install (ohne --no-dev, deshalb liegen Ignition und Faker auf den Servern) und php artisan migrate --force aus, in dieser Reihenfolge und ohne Backup-Schritt.