Kurz gesagt: Ein Docker-Image enthält PHP im Stand seines Bauzeitpunkts und veraltet auch ohne Codeänderung. Wer Images automatisch neu baut, zeitgesteuert und bei Sicherheitsmeldungen, die PHP-Version in der Pipeline prüft und per Digest ausrollt, bringt Patches wie gegen PHP2Shell planbar in Produktion. Ein grüner Build allein ist dabei kein Nachweis; zählen tut die Version im laufenden Container.
Warum Images ohne Codeänderung veralten
In vielen Teams startet die Build-Pipeline nur, wenn jemand Code ändert. Für die Anwendung ist das logisch. Für die Sicherheit ist es ein Problem, denn das PHP im Image stammt aus dem Basis-Image vom Tag des letzten Builds.
PHP2Shell hat das sichtbar gemacht. Die behobenen Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 erschienen am 21. Oktober 2026. Ein Projekt, an dem in diesen Tagen niemand gearbeitet hat, bekam keinen neuen Build und lief mit dem alten PHP weiter, obwohl das Basis-Image längst aktualisiert war. Den manuellen Weg aus dieser Lage beschreibt PHP in Docker-Containern patchen. Dieser Beitrag zeigt, wie Sie ihn automatisieren.
Docker-Images automatisch neu bauen: drei Auslöser
Ein robuster Prozess kombiniert mehrere Auslöser, damit keiner allein tragen muss.
| Auslöser | Umsetzung | Zu beachten |
|---|---|---|
| Zeitplan | zeitgesteuerter Workflow, z. B. wöchentlich | holt Patches auch ohne Codeänderung ab |
| Neues Basis-Image | Werkzeug, das Basis-Images überwacht und Änderungen vorschlägt | wirkt vor allem bei festen Versions-Tags |
| Sicherheitsmeldung | manueller Start der Pipeline durch das Betriebsteam | braucht einen klaren Verantwortlichen |
Bei GitHub Actions übernimmt das Ereignis schedule den Zeitplan. Laut GitHub-Dokumentation nutzt es die Cron-Syntax mit fünf Feldern, läuft in UTC und nur auf dem Standard-Branch. Geplante Läufe können bei hoher Last verzögert starten, und in öffentlichen Repositories schaltet GitHub sie nach 60 Tagen ohne Aktivität ab. Gerade Letzteres trifft ruhige Projekte, also genau die, die den automatischen Neubau am dringendsten brauchen.
Für den zweiten Auslöser unterstützt Dependabot laut GitHub-Dokumentation das Ökosystem docker und schlägt neue Stände von Basis-Images als Pull Request vor. Zwei Einschränkungen sollten Sie kennen. Erstens muss jemand den Pull Request prüfen und zusammenführen, sonst bleibt er liegen. Zweitens ändert sich bei einem Zweig-Tag wie php:8.3-fpm im Dockerfile nichts, wenn das Basis-Image neu gebaut wird. Ein Werkzeug, das Textänderungen vorschlägt, hat dann nichts vorzuschlagen. Genau deshalb braucht es zusätzlich den zeitgesteuerten Neubau.
Der dritte Auslöser klingt banal, scheitert in der Praxis aber oft an der Frage, wer ihn auslöst. Legen Sie fest, wer Sicherheitsmeldungen zu PHP verfolgt und wer die Pipeline starten darf, auch am Wochenende. Bei PHP2Shell lag zwischen Vorankündigung und Patch nur ein Tag.
Eine Pipeline, die veraltetes PHP abfängt
Das folgende Beispiel für GitHub Actions baut das Image wöchentlich und auf Knopfdruck, prüft die PHP-Version und bricht ab, wenn sie unter dem behobenen Stand liegt. Registry, Namen und Mindestversion passen Sie an.
name: php-image-rebuild
on:
schedule:
- cron: "0 3 * * 1" # montags 03:00 UTC
workflow_dispatch: {} # manueller Start bei Sicherheitsmeldungen
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Image ohne Cache und mit frischem Basis-Image bauen
run: docker build --pull --no-cache -t app:${{ github.run_id }} .
- name: PHP-Version prüfen (Mindeststand des Zweigs 8.3)
run: |
docker run --rm app:${{ github.run_id }} php -v
docker run --rm app:${{ github.run_id }} \
php -r 'exit(version_compare(PHP_VERSION, "8.3.36", ">=") ? 0 : 1);'
Die Versionsprüfung funktioniert bei offiziellen PHP-Images, deren Versionsnummer den tatsächlichen Stand angibt. Nutzt Ihr Image PHP-Pakete einer Distribution, bleibt die Nummer nach einem Backport oft gleich. Dann prüfen Sie statt der Nummer den Paket-Changelog auf die CVE-Nummern, wie im Beitrag CVE-Nummern im Paket-Changelog nachweisen beschrieben.
Nach der Prüfung folgen in der Praxis drei weitere Schritte: das Image auf bekannte Schwachstellen scannen, es mit Datum und Digest in die Registry schieben und den Digest an die Bereitstellung übergeben. Welche Tags und Varianten sich als Basis eignen, erklärt Offizielle PHP-Docker-Images.
Vom Build zum laufenden Container
Der häufigste Denkfehler: Die Pipeline ist grün, also ist alles gepatcht. Tatsächlich liegt das neue Image nur in der Registry. Wirksam wird der Patch erst, wenn jeder Container aus dem neuen Image neu erstellt wurde.
- Per Digest ausrollen: Die Bereitstellung referenziert den Digest des neuen Images, nicht einen wandernden Tag.
- Erst Staging, dann Produktion: Automatische Tests auf einer Kopie fangen Brüche durch neue Basis-Images ab.
- Im Betrieb prüfen: Nach dem Rollout
php -vim laufenden Container ausführen und den Digest mit dem Build vergleichen. - Rückweg begrenzen: Das alte Image bleibt für einen kurzen Rückweg verfügbar, enthält aber das verwundbare PHP.
In Kubernetes gelten dafür eigene Regeln, etwa zur Pull-Policy; sie stehen unter PHP in Kubernetes patchen.
Typische Lücken in der Kette
- Build-Cache auf dem Runner: Ohne
--pullund--no-cachewird das alte Basis-Image wiederverwendet. - Registry-Spiegel: Ein interner Zwischenspeicher liefert noch den alten Stand des Basis-Images.
- Mehrstufige Builds: Die PHP-Version der letzten Stufe zählt, geprüft wird aber oft nur die erste.
- Nebenimages: Queue-Worker, Cron-Container und interne Werkzeuge haben eigene Pipelines oder gar keine.
- Fest eingetragene Digests: Ein einmal festgeschriebener Digest des Basis-Images wird nie aktualisiert, wenn kein Werkzeug ihn überwacht.
Ein Neubau ersetzt PHP, nicht die Daten. Schadcode, der vor dem Patch in Volumes, Upload-Ordner oder die Datenbank gelangt ist, bleibt erhalten und muss gesondert geprüft werden.
Wer reagiert, wenn der Neubau scheitert?
Ein automatischer Neubau ist nur so gut wie die Reaktion auf seinen Fehlschlag. Schlägt die Versionsprüfung an oder bricht der Build wegen eines geänderten Basis-Images ab, muss das jemand bemerken. In vielen Teams landen solche Meldungen in einem Postfach, das niemand liest, oder in einem Kanal, in dem rote Builds längst Alltag sind.
Bewährt hat sich eine klare Regel: Ein fehlgeschlagener Sicherheits-Neubau ist ein Ticket mit Verantwortlichem und Frist, kein Hinweis unter vielen. Halten Sie außerdem für jedes ausgerollte Image Datum, Digest und geprüfte PHP-Version fest. Diese Liste beantwortet bei der nächsten Meldung in Minuten, welche Anwendungen betroffen sind, und dient gegenüber Prüfern oder Versicherern als Nachweis. Wie sich daraus ein dauerhafter Ablauf ergibt, beschreibt Patch-Management als Prozess statt Feuerwehr.
Wie hilft PHP SOS konkret?
- Pipelines prüfen: Wir sehen uns Ihre Build- und Rollout-Ketten an und zeigen, wo ein Patch hängen bleiben kann.
- Neubau automatisieren: Wir richten zeitgesteuerte Builds, Versionsprüfung und Rollout per Digest ein.
- Alle Images erfassen: Wir ordnen jedem laufenden Container seine Pipeline zu, auch Neben- und Altimages.
- Dauerhaft betreuen: Im Security-Wartungsvertrag verfolgen wir Sicherheitsmeldungen und stoßen Neubauten an.
Häufige Fragen
Wie oft sollte ein PHP-Image neu gebaut werden?
Eine feste Zahl gibt es nicht. Bewährt hat sich ein regelmäßiger zeitgesteuerter Build, etwa wöchentlich, plus ein sofortiger Build bei Sicherheitsmeldungen. Entscheidend ist, dass ein neuer Patch nicht auf die nächste Codeänderung warten muss.
Reicht ein erfolgreicher Build als Nachweis?
Nein. Ein Build beweist nur, dass ein neues Image existiert. Erst wenn die laufenden Container aus diesem Image neu erstellt sind und php -v darin die behobene Version zeigt, ist der Patch wirksam.
Warum taucht nach dem Neubau trotzdem die alte PHP-Version auf?
Häufige Ursachen sind ein Build-Cache, der das alte Basis-Image wiederverwendet, ein Registry-Spiegel mit altem Stand oder eine zweite FROM-Zeile in einem mehrstufigen Build. Bauen Sie mit --pull und --no-cache und prüfen Sie jede Stufe.
Kann Dependabot Basis-Images aktualisieren?
Laut GitHub-Dokumentation unterstützt Dependabot das Ökosystem Docker für Versions- und Sicherheitsupdates. Es schlägt Änderungen an Basis-Images als Pull Request vor. Den Neubau bei gleichbleibendem Tag ersetzt das nicht.