CI/CD: PHP-images automatisch opnieuw bouwen

Kort gezegd: Een Docker-image bevat PHP in de stand van haar bouwmoment en veroudert ook zonder codewijziging. Wie images automatisch opnieuw bouwt, tijdgestuurd en bij beveiligingsmeldingen, de PHP-versie in de pipeline controleert en via digest uitrolt, brengt patches zoals die tegen PHP2Shell plannbaar in productie. Een groene build alleen is daarbij geen bewijs; wat telt is de versie in de draaiende container.

Waarom images zonder codewijziging verouderen

In veel teams start de buildpipeline alleen als iemand code wijzigt. Voor de applicatie is dat logisch. Voor de beveiliging is het een probleem, want de PHP in de image komt uit de basisimage van de tag op het moment van de laatste build.

PHP2Shell heeft dat zichtbaar gemaakt. De verholpen versies 8.5.12, 8.4.27, 8.3.36 en 8.2.35 verschenen op 21 oktober 2026. Een project waaraan in die dagen niemand werkte, kreeg geen nieuwe build en bleef met de oude PHP draaien, hoewel de basisimage allang was bijgewerkt. De handmatige weg uit die situatie beschrijft PHP in Docker-containers patchen. Dit artikel toont hoe u die automatiseert.

Docker-images automatisch opnieuw bouwen: drie triggers

Een robuust proces combineert meerdere triggers, zodat er niet één alles hoeft te dragen.

Bij GitHub Actions neemt de gebeurtenis schedule het tijdschema voor haar rekening. Volgens de GitHub-documentatie gebruikt ze de cron-syntaxis met vijf velden, draait in UTC en alleen op de standaardbranch. Geplande runs kunnen bij hoge belasting vertraagd starten, en in openbare repositories schakelt GitHub ze na 60 dagen zonder activiteit uit. Juist dat laatste treft rustige projecten, dus precies degene die de automatische herbouw het hardst nodig hebben.

Voor de tweede trigger ondersteunt Dependabot volgens de GitHub-documentatie het ecosysteem docker en stelt nieuwe standen van basisimages voor als pull request. Twee beperkingen moet u kennen. Ten eerste moet iemand de pull request beoordelen en samenvoegen, anders blijft hij liggen. Ten tweede verandert er bij een tak-tag zoals php:8.3-fpm niets in het Dockerfile wanneer de basisimage opnieuw wordt gebouwd. Een hulpmiddel dat tekstwijzigingen voorstelt, heeft dan niets voor te stellen. Juist daarom is aanvullend de tijdgestuurde herbouw nodig.

De derde trigger klinkt banaal, maar strandt in de praktijk vaak op de vraag wie hem activeert. Leg vast wie beveiligingsmeldingen over PHP volgt en wie de pipeline mag starten, ook in het weekend. Bij PHP2Shell lag tussen de voorafgaande aankondiging en de patch maar één dag.

Een pipeline die verouderde PHP onderschept

Het volgende voorbeeld voor GitHub Actions bouwt de image wekelijks en op knopdruk, controleert de PHP-versie en breekt af als die onder de verholpen stand ligt. Registry, namen en minimumversie past u aan.

name: php-image-rebuild
on:
  schedule:
    - cron: "0 3 * * 1"      # maandag 03:00 UTC
  workflow_dispatch: {}      # handmatige start bij beveiligingsmeldingen

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);'

De versiecontrole werkt bij officiële PHP-images, waarvan het versienummer de werkelijke stand aangeeft. Gebruikt uw image PHP-pakketten van een distributie, dan blijft het nummer na een backport vaak gelijk. Controleer dan in plaats van het nummer de pakket-changelog op de CVE-nummers, zoals beschreven in het artikel CVE-nummers aantonen in de pakket-changelog.

Na de controle volgen in de praktijk drie verdere stappen: de image scannen op bekende kwetsbaarheden, haar met datum en digest naar de registry pushen en de digest doorgeven aan de uitrol. Welke tags en varianten zich als basis lenen, legt Officiële PHP Docker-images uit.

Van build naar draaiende container

De meest voorkomende denkfout: de pipeline is groen, dus alles is gepatcht. In werkelijkheid staat de nieuwe image alleen in de registry. De patch wordt pas werkzaam wanneer elke container uit de nieuwe image opnieuw is aangemaakt.

1. Via digest uitrollen: De uitrol verwijst naar de digest van de nieuwe image, niet naar een schuivende tag.
2. Eerst staging, dan productie: Automatische tests op een kopie vangen breuken door nieuwe basisimages op.
3. In bedrijf controleren: Na de uitrol php -v in de draaiende container uitvoeren en de digest met die van de build vergelijken.
4. Terugweg beperken: De oude image blijft kort beschikbaar voor een terugweg, maar bevat de kwetsbare PHP.

In Kubernetes gelden daarvoor eigen regels, bijvoorbeeld over het pull-beleid; ze staan onder PHP in Kubernetes patchen.

Typische hiaten in de keten

• Buildcache op de runner: Zonder --pull en --no-cache wordt de oude basisimage hergebruikt.
• Registry-mirror: Een interne tussenopslag levert nog de oude stand van de basisimage.
• Meertrapsbuilds: De PHP-versie van de laatste trap telt, maar vaak wordt alleen de eerste gecontroleerd.
• Nevenimages: Queue-workers, cron-containers en interne hulpmiddelen hebben eigen pipelines of helemaal geen.
• Vastgezette digests: Een eenmaal vastgelegde digest van de basisimage wordt nooit bijgewerkt als geen hulpmiddel hem bewaakt.

Wie reageert als de herbouw mislukt?

Een automatische herbouw is maar zo goed als de reactie op zijn falen. Slaat de versiecontrole aan of breekt de build af door een gewijzigde basisimage, dan moet iemand dat merken. In veel teams belanden dergelijke meldingen in een postvak dat niemand leest, of in een kanaal waar rode builds allang gewoon zijn.

Een duidelijke regel heeft zich bewezen: een mislukte beveiligingsherbouw is een ticket met een verantwoordelijke en een termijn, geen melding tussen vele andere. Leg bovendien voor elke uitgerolde image datum, digest en gecontroleerde PHP-versie vast. Deze lijst beantwoordt bij de volgende melding in minuten welke applicaties zijn getroffen, en dient tegenover auditors of verzekeraars als bewijs. Hoe daaruit een duurzaam proces ontstaat, beschrijft Patchmanagement als proces in plaats van brandweeractie.

Hoe helpt PHP SOS concreet?

• Pipelines controleren: Wij bekijken uw build- en uitrolketens en tonen waar een patch kan blijven hangen.
• Herbouw automatiseren: Wij richten tijdgestuurde builds, versiecontrole en uitrol via digest in.
• Alle images vastleggen: Wij koppelen elke draaiende container aan zijn pipeline, ook neven- en oude images.
• Duurzaam begeleiden: In het beveiligingsonderhoudscontract volgen wij beveiligingsmeldingen en zetten wij herbouwen in gang.

Veelgestelde vragen

Bronnen

• GitHub Docs: gebeurtenissen die workflows starten (schedule)
• GitHub Docs: door Dependabot ondersteunde ecosystemen
• Docker Hub: officiële PHP-image
• PHP: ondersteunde versies