{"id":1390,"date":"2026-11-03T09:00:00","date_gmt":"2026-11-03T08:00:00","guid":{"rendered":"https:\/\/www.cisilino.com\/?p=1390"},"modified":"2026-11-03T09:02:50","modified_gmt":"2026-11-03T08:02:50","slug":"laravel-sicherheitsupdates-ueberwachen-composer-audit","status":"publish","type":"post","link":"https:\/\/www.cisilino.com\/de\/2026\/11\/03\/laravel-sicherheitsupdates-ueberwachen-composer-audit\/","title":{"rendered":"Laravel-Sicherheitsupdates: wie ich sie im Blick behalte"},"content":{"rendered":"\n

Ich verwalte mehrere Produktionsserver. Der gr\u00f6\u00dfte Teil des Traffics, der \u00fcber mein Hosting l\u00e4uft, geht an WordPress-Seiten. Aber nicht alles. Wenn ein Kunde eine ma\u00dfgeschneiderte Verwaltungssoftware, ein Backend f\u00fcr eine App oder einen kleinen Onlineshop mit Sonderregeln braucht, reicht das CMS nicht mehr aus. Dann kommen PHP-Frameworks ins Spiel. Um Laravel-Sicherheitsupdates \u00fcberwachen<\/strong> zu k\u00f6nnen, habe ich eine Kontrolle aufgebaut, die ich wirklich laufen lasse, nicht nur in der Theorie.<\/p>\n\n\n\n

\"Laravel-Sicherheitsupdates<\/figure>\n\n\n\n

Wie viele Seiten CMS sind und wie viele ma\u00dfgeschneiderte Anwendungen<\/h2>\n\n\n\n

Die Zahlen von W3Techs zeigen, dass rund 68 % der Seiten mit einem erkannten CMS WordPress, Shopify oder eine \u00e4hnliche Plattform nutzen. Der Rest, etwas mehr als ein Drittel des \u00fcberwachten \u00f6ffentlichen 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\u00dfgeschneiderte Anwendung“. Aber die Richtung ist klar: handgeschriebene Web-Apps bleiben ein riesiger Teil des Internets.<\/p>\n\n\n\n

Unter den PHP-Frameworks f\u00fcr 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\u00fcr Laravel. Symfony folgt, aber deutlich dahinter. Auf meinen Hosting-Servern passt die Lage zu diesem Trend. Die individuellen Anwendungen, die ich f\u00fcr 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 \u00e4ndert sich dadurch nicht: Wer ma\u00dfgeschneiderte PHP-Anwendungen schreibt, hat mit Laravel heute den h\u00e4ufigsten Ausgangspunkt, nicht die Ausnahme.<\/p>\n\n\n\n

Wie ich Laravel-Sicherheitsupdates \u00fcberwachen lasse<\/h2>\n\n\n\n

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\u00fccke 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\u00e4hrend eines PHP-Sicherheitsnotfalls bew\u00e4ltigen<\/a> musste: lieber vorbeugen mit einer regelm\u00e4\u00dfigen Kontrolle, als dem Problem hinterherzulaufen, nachdem es schon ausgebrochen ist.<\/p>\n\n\n\n

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 \u00c4nderungen.<\/p>\n\n\n\n

Das Audit-Skript<\/h3>\n\n\n\n
#!\/usr\/bin\/env bash\nset -euo pipefail\n\nPROJECT_DIR=\"${1:-.}\"\ncd \"$PROJECT_DIR\"\n\necho \"==> Project: $(pwd)\"\n\nif [[ ! -f composer.lock ]]; then\n  echo \"SKIP: composer.lock non trovato (non sembra un progetto composer installato).\"\n  exit 0\nfi\n\necho \"\"\necho \"==> Composer audit (vulnerabilit\u00e0 note)\"\n# --no-interaction utile in CI; fallisce (exit code != 0) se trova advisory\ncomposer audit --no-interaction\n\necho \"\"\necho \"==> Pacchetti outdated (info)\"\ncomposer outdated --direct || true\n\necho \"\"\necho \"==> Laravel version (se presente)\"\nphp -r '\n$lock=json_decode(file_get_contents(\"composer.lock\"), true);\n$pkgs=array_merge($lock[\"packages\"] ?? [], $lock[\"packages-dev\"] ?? []);\n$laravel=null;\nforeach ($pkgs as $p) { if (($p[\"name\"] ?? \"\")===\"laravel\/framework\") { $laravel=$p[\"version\"] ?? null; break; } }\necho $laravel ? \"laravel\/framework: $laravel\\n\" : \"laravel\/framework non trovato nel lock\\n\";\n'\n<\/code><\/pre>\n\n\n\n
Hinweis<\/strong>: Das Skript wird wie es ist, zu Informationszwecken bereitgestellt. Die Nutzung erfolgt ausschlie\u00dflich auf eigenes Risiko: Ich \u00fcbernehme keine Verantwortung f\u00fcr 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\u00e4ngiges Backup, bevor du es in Produktion ausf\u00fchrst.<\/p>\n\n\n\n
composer audit<\/code> ist ein Befehl, der seit Version 2.4 fest in Composer integriert ist. Er liest die genauen Versionen der Pakete aus der composer.lock<\/code>. Er vergleicht sie mit einer Datenbank ver\u00f6ffentlichter Sicherheits-Advisories. Die Datenbank kommt \u00fcber Packagist, das sich wiederum auf das Repository FriendsOfPHP\/security-advisories und die GitHub Advisory Database st\u00fctzt. Findet er eine \u00dcbereinstimmung, listet er das Paket, die verwundbare Version und das zugeh\u00f6rige 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 \u00fcberpr\u00fcft werden muss. Ich muss nicht jede Zeile im Log von Hand lesen.<\/p>\n\n\n\n
Auf Produktionsprojekten lasse ich es einmal am Tag per Cron laufen, mit der Ausgabe per E-Mail, wenn der Befehl fehlschl\u00e4gt. Bei manchen strukturierteren Kunden habe ich es auch in die Deploy-Pipeline eingebunden. Findet composer audit<\/code> ein blockierendes Advisory, stoppt das Deployment, bevor es in Produktion geht. Lieber dort anhalten, als es sp\u00e4ter zu entdecken, wenn die Seite schon online ist. Diese t\u00e4gliche Kontrolle, wiederholt auf jedem Projekt, ist der praktische Kern davon, wie ich Laravel-Sicherheitsupdates \u00fcberwachen lasse, und nicht nur dann, wenn ich von Hand daran denke.<\/p>\n\n\n\n
Die zweite Zeile des Skripts, composer outdated --direct<\/code>, zeigt nur die Abh\u00e4ngigkeiten, die von Hand in der composer.json<\/code> deklariert sind. Sie zeigt nicht den gesamten Baum der transitiven Abh\u00e4ngigkeiten. Ein durchschnittliches Laravel-Projekt bringt Hunderte indirekte Pakete mit. W\u00fcrde ich sie alle auflisten, w\u00e4re die Ausgabe unlesbar. Am Ende w\u00fcrde ich sie ignorieren, wie es bei zu vielen automatischen Hinweisen passiert. Wenn ich nur die direkten Abh\u00e4ngigkeiten ansehe, sehe ich auf einen Blick, was ich selbst gew\u00e4hlt habe. Ich kann in Ruhe entscheiden, was ich aktualisiere und wann.<\/p>\n\n\n\n
Der letzte Teil des Skripts gibt die Version von laravel\/framework<\/code> 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 \u00f6ffnen. Laut der offiziellen Support-Tabelle von Laravel endeten die Sicherheitspatches f\u00fcr Version 11 am 12. M\u00e4rz 2026. Version 12 erh\u00e4lt sie bis zum 24. Februar 2027. Seit dem ersten Quartal 2026 ist Laravel 13 die aktuelle Version. Laravel-Sicherheitsupdates \u00fcberwachen und rechtzeitig planen bedeutet auch das: zu wissen, auf welcher Version jedes Projekt steht, bevor der Support endet.<\/p>\n\n\n\n
Die ehrlichen Grenzen dieser Kontrolle<\/h2>\n\n\n\n
composer audit<\/code> ist kein Virenscanner. Er liest nicht den Code der Anwendung. Er meldet nur bekannte Schwachstellen, die bereits in einem Advisory ver\u00f6ffentlicht sind. Gegen eine Zero-Day-L\u00fccke, entdeckt, aber noch nicht ver\u00f6ffentlicht, n\u00fctzt er nichts. Deshalb betrachte ich ihn als Basishygiene, nicht als absolute Garantie. Die regelm\u00e4\u00dfigen Paket-Updates<\/a> 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.<\/p>\n\n\n\n
Fest steht: Ein paar Zeilen Skript, jeden Tag ausgef\u00fchrt, h\u00e4tten mir in den Jahren, in denen ich es noch nicht nutzte, so manche peinliche E-Mail an Kunden erspart. Heute geh\u00f6rt es zur Wartungsroutine jedes Laravel-Projekts, das ich betreue. Ich kombiniere es mit der \u00dcberwachung der Logs und der Zugriffsversuche auf den Servern. Laravel-Sicherheitsupdates \u00fcberwachen 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.<\/p>\n\n","protected":false},"excerpt":{"rendered":"
Wie ich auf meinen Laravel-Projekten Laravel-Sicherheitsupdates \u00fcberwachen lasse: composer audit per Cron und in der Deploy-Pipeline, plus die Grenzen dieser Kontrolle.<\/p>\n","protected":false},"author":1,"featured_media":1388,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"wpai_generated_summary":"","footnotes":""},"categories":[363],"tags":[342,519,520,378,373,334],"class_list":["post-1390","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server-datenbanken","tag-bash-skript","tag-composer","tag-laravel","tag-php-de","tag-server-management-de","tag-update"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t