Wie viele Seiten CMS sind und wie viele maßgeschneiderte Anwendungen

Die Zahlen von W3Techs zeigen, dass rund 68 % der Seiten mit einem erkannten CMS WordPress, Shopify oder eine ähnliche Plattform nutzen. Der Rest, etwas mehr als ein Drittel des überwachten öffentlichen Webs, nutzt keines der CMS, die diese Statistiken erfassen. Darin stecken statische Seiten, aber auch sehr viele individuell entwickelte Anwendungen. Es ist kein perfekter Wert. „Kein CMS erkannt“ entspricht nicht genau „maßgeschneiderte Anwendung“. Aber die Richtung ist klar: handgeschriebene Web-Apps bleiben ein riesiger Teil des Internets.

Unter den PHP-Frameworks für solche Anwendungen ist Laravel heute das am weitesten verbreitete. Die Umfrage State of PHP 2025 von JetBrains, unter mehr als 1.700 Entwicklern, nennt eine Nutzung von 64 % für Laravel. Symfony folgt, aber deutlich dahinter. Auf meinen Hosting-Servern passt die Lage zu diesem Trend. Die individuellen Anwendungen, die ich für Kunden verwalte, sind, wenn es kein WordPress ist, fast immer Laravel-Projekte. Manche Kunden kommen schon mit einem bestehenden Projekt, das gepflegt werden muss. Andere bitten mich, es von null an aufzubauen, weil sie wissen, dass es die verbreitetste Wahl auf dem Markt ist. Absolute Zahlen zu Seiten, aus Quellen wie BuiltWith, sollte man mit Vorsicht lesen: Laravel bringt mehrere Symfony-Komponenten mit, und das verzerrt Statistiken, die nur auf installierten Paketen beruhen, etwas. Doch das Gesamtbild ändert sich dadurch nicht: Wer maßgeschneiderte PHP-Anwendungen schreibt, hat mit Laravel heute den häufigsten Ausgangspunkt, nicht die Ausnahme.

Wie ich Laravel-Sicherheitsupdates überwachen lasse

Ein Laravel-Projekt in Produktion ist nie „fertig und erledigt“. Das Framework, seine Komponenten und die Dutzenden Composer-Pakete, die es mitbringt, erhalten Patches, wenn eine Lücke gefunden wird. Kontrolliert niemand das, kann eine Seite monatelang verwundbar bleiben. Der Kunde merkt es oft nicht einmal. Es ist dasselbe Prinzip, das ich angewendet habe, als ich einen laufenden Angriff auf einem Server während eines PHP-Sicherheitsnotfalls bewältigen musste: lieber vorbeugen mit einer regelmäßigen Kontrolle, als dem Problem hinterherzulaufen, nachdem es schon ausgebrochen ist.

Deshalb habe ich ein einfaches Bash-Skript geschrieben. Ich lasse es per Cron auf jedem Laravel-Projekt laufen, das ich verwalte. Ich binde es auch in die Deploy-Pipelines ein, wenn der Kunde eine hat. Es macht keine Magie: Es liest die Lock-Datei von Composer und vergleicht sie mit Datenbanken bekannter Schwachstellen. Hier ist es, genau so, wie ich es nutze, ohne Änderungen.

Das Audit-Skript

#!/usr/bin/env bash
set -euo pipefail

PROJECT_DIR="${1:-.}"
cd "$PROJECT_DIR"

echo "==> Project: $(pwd)"

if [[ ! -f composer.lock ]]; then
  echo "SKIP: composer.lock non trovato (non sembra un progetto composer installato)."
  exit 0
fi

echo ""
echo "==> Composer audit (vulnerabilità note)"
# --no-interaction utile in CI; fallisce (exit code != 0) se trova advisory
composer audit --no-interaction

echo ""
echo "==> Pacchetti outdated (info)"
composer outdated --direct || true

echo ""
echo "==> Laravel version (se presente)"
php -r '
$lock=json_decode(file_get_contents("composer.lock"), true);
$pkgs=array_merge($lock["packages"] ?? [], $lock["packages-dev"] ?? []);
$laravel=null;
foreach ($pkgs as $p) { if (($p["name"] ?? "")==="laravel/framework") { $laravel=$p["version"] ?? null; break; } }
echo $laravel ? "laravel/framework: $laravel\n" : "laravel/framework non trovato nel lock\n";
'

Hinweis: Das Skript wird wie es ist, zu Informationszwecken bereitgestellt. Die Nutzung erfolgt ausschließlich auf eigenes Risiko: Ich übernehme keine Verantwortung für Datenverlust, Ausfallzeiten oder Fehler, die durch falsche Anwendung oder einen anderen Kontext als den, in dem ich es selbst einsetze, entstehen. Erstelle immer ein unabhängiges Backup, bevor du es in Produktion ausführst.

composer audit ist ein Befehl, der seit Version 2.4 fest in Composer integriert ist. Er liest die genauen Versionen der Pakete aus der composer.lock. Er vergleicht sie mit einer Datenbank veröffentlichter Sicherheits-Advisories. Die Datenbank kommt über Packagist, das sich wiederum auf das Repository FriendsOfPHP/security-advisories und die GitHub Advisory Database stützt. Findet er eine Übereinstimmung, listet er das Paket, die verwundbare Version und das zugehörige Advisory auf. Danach beendet er sich mit einem Exit-Code ungleich null. Genau das ist das Detail, das mich am meisten interessiert. Ein Exit-Code ungleich null ist das, was einem Cron oder einer Pipeline erlaubt, von selbst zu erkennen, dass etwas überprüft werden muss. Ich muss nicht jede Zeile im Log von Hand lesen.

Auf Produktionsprojekten lasse ich es einmal am Tag per Cron laufen, mit der Ausgabe per E-Mail, wenn der Befehl fehlschlägt. Bei manchen strukturierteren Kunden habe ich es auch in die Deploy-Pipeline eingebunden. Findet composer audit ein blockierendes Advisory, stoppt das Deployment, bevor es in Produktion geht. Lieber dort anhalten, als es später zu entdecken, wenn die Seite schon online ist. Diese tägliche Kontrolle, wiederholt auf jedem Projekt, ist der praktische Kern davon, wie ich Laravel-Sicherheitsupdates überwachen lasse, und nicht nur dann, wenn ich von Hand daran denke.

Die zweite Zeile des Skripts, composer outdated --direct, zeigt nur die Abhängigkeiten, die von Hand in der composer.json deklariert sind. Sie zeigt nicht den gesamten Baum der transitiven Abhängigkeiten. Ein durchschnittliches Laravel-Projekt bringt Hunderte indirekte Pakete mit. Würde ich sie alle auflisten, wäre die Ausgabe unlesbar. Am Ende würde ich sie ignorieren, wie es bei zu vielen automatischen Hinweisen passiert. Wenn ich nur die direkten Abhängigkeiten ansehe, sehe ich auf einen Blick, was ich selbst gewählt habe. Ich kann in Ruhe entscheiden, was ich aktualisiere und wann.

Der letzte Teil des Skripts gibt die Version von laravel/framework aus der Lock-Datei aus. Ich mache das, weil der Lebenszyklus der Laravel-Versionen feste Fristen hat. Ich will sie kennen, ohne jedes Projekt einzeln von Hand zu öffnen. Laut der offiziellen Support-Tabelle von Laravel endeten die Sicherheitspatches für Version 11 am 12. März 2026. Version 12 erhält sie bis zum 24. Februar 2027. Seit dem ersten Quartal 2026 ist Laravel 13 die aktuelle Version. Laravel-Sicherheitsupdates überwachen und rechtzeitig planen bedeutet auch das: zu wissen, auf welcher Version jedes Projekt steht, bevor der Support endet.

Die ehrlichen Grenzen dieser Kontrolle

composer audit ist kein Virenscanner. Er liest nicht den Code der Anwendung. Er meldet nur bekannte Schwachstellen, die bereits in einem Advisory veröffentlicht sind. Gegen eine Zero-Day-Lücke, entdeckt, aber noch nicht veröffentlicht, nützt er nichts. Deshalb betrachte ich ihn als Basishygiene, nicht als absolute Garantie. Die regelmäßigen Paket-Updates bleiben die wirksamste Praxis, auch ohne ein laufendes Advisory. Die offizielle Laravel-Dokumentation empfiehlt, auf der aktuellen Version des Frameworks zu bleiben. Sie empfiehlt auch, Tests vor jedem Major-Update zu automatisieren. Das macht das Update zu einer Gewohnheit, nicht zu einem Notfall der letzten Minute.

Fest steht: Ein paar Zeilen Skript, jeden Tag ausgeführt, hätten mir in den Jahren, in denen ich es noch nicht nutzte, so manche peinliche E-Mail an Kunden erspart. Heute gehört es zur Wartungsroutine jedes Laravel-Projekts, das ich betreue. Ich kombiniere es mit der Überwachung der Logs und der Zugriffsversuche auf den Servern. Laravel-Sicherheitsupdates überwachen beseitigt das Risiko nicht. Es verringert es deutlich. Und es kostet sehr wenig, verglichen mit einer kompromittierten Seite und einem Kunden, der das Vertrauen verliert.

The post Laravel-Sicherheitsupdates: wie ich sie im Blick behalte first appeared on Matteo Cisilino.