Kort sagt: En Docker-image innehåller PHP i den nivå som gällde vid byggtillfället och åldras även utan kodändring. Den som bygger om images automatiskt, tidsstyrt och vid säkerhetsmeddelanden, kontrollerar PHP-versionen i pipelinen och rullar ut via digest får planerbart in patchar som den mot PHP2Shell i produktion. Ett grönt bygge ensamt är inget bevis; det som räknas är versionen i den körande containern.
Varför images åldras utan kodändring
I många team startar byggpipelinen bara när någon ändrar kod. För applikationen är det logiskt. För säkerheten är det ett problem, eftersom PHP i imagen kommer från basimagen vid taggen för det senaste bygget.
PHP2Shell har gjort det synligt. De rättade versionerna 8.5.12, 8.4.27, 8.3.36 och 8.2.35 kom den 21 oktober 2026. Ett projekt som ingen arbetade med under de dagarna fick inget nytt bygge och fortsatte köra med det gamla PHP, fast basimagen sedan länge var uppdaterad. Den manuella vägen ur det läget beskrivs i Patcha PHP i Docker-containrar. Det här inlägget visar hur ni automatiserar den.
Bygga om Docker-images automatiskt: tre utlösare
En robust process kombinerar flera utlösare, så att ingen enskild behöver bära allt.
| Utlösare | Genomförande | Att tänka på |
|---|---|---|
| Tidsplan | tidsstyrt workflow, t.ex. varje vecka | hämtar patchar även utan kodändring |
| Ny basimage | verktyg som bevakar basimages och föreslår ändringar | verkar framför allt vid fasta versionstaggar |
| Säkerhetsmeddelande | manuell start av pipelinen av driftteamet | kräver en tydlig ansvarig |
Hos GitHub Actions står händelsen schedule för tidsplanen. Enligt GitHub-dokumentationen använder den cron-syntax med fem fält, körs i UTC och bara på standardgrenen. Schemalagda körningar kan starta försenat vid hög belastning, och i offentliga repositorier stänger GitHub av dem efter 60 dagar utan aktivitet. Just det sista drabbar lugna projekt, alltså precis de som mest behöver den automatiska ombyggnaden.
För den andra utlösaren stöder Dependabot enligt GitHub-dokumentationen ekosystemet docker och föreslår nya nivåer av basimages som pull request. Två begränsningar bör ni känna till. För det första måste någon granska och sammanfoga pull requesten, annars blir den liggande. För det andra ändras ingenting i Dockerfilen vid en grentagg som php:8.3-fpm när basimagen byggs om. Ett verktyg som föreslår textändringar har då inget att föreslå. Just därför behövs den tidsstyrda ombyggnaden dessutom.
Den tredje utlösaren låter banal, men i praktiken strandar den ofta på frågan vem som utlöser den. Bestäm vem som följer säkerhetsmeddelanden om PHP och vem som får starta pipelinen, även på helgen. Vid PHP2Shell låg det bara en dag mellan förhandsmeddelandet och patchen.
En pipeline som fångar upp föråldrat PHP
Exemplet nedan för GitHub Actions bygger imagen varje vecka och på knapptryckning, kontrollerar PHP-versionen och avbryter om den ligger under den rättade nivån. Register, namn och lägsta version anpassar ni.
name: php-image-rebuild
on:
schedule:
- cron: "0 3 * * 1" # måndagar 03:00 UTC
workflow_dispatch: {} # manuell start vid säkerhetsmeddelanden
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);'
Versionskontrollen fungerar för officiella PHP-images, vars versionsnummer anger den faktiska nivån. Använder er image PHP-paket från en distribution förblir numret efter en backport ofta detsamma. Då kontrollerar ni i stället för numret paketets changelog efter CVE-numren, som beskrivs i inlägget Styrk CVE-nummer i paketets changelog.
Efter kontrollen följer i praktiken tre steg till: skanna imagen efter kända svagheter, skicka den till registret med datum och digest och lämna över digesten till utrullningen. Vilka taggar och varianter som lämpar sig som bas förklaras i Officiella PHP Docker-images.
Från bygge till körande container
Det vanligaste tankefelet: pipelinen är grön, alltså är allt patchat. I själva verket ligger den nya imagen bara i registret. Patchen blir verksam först när varje container har skapats på nytt från den nya imagen.
- Rulla ut via digest: Utrullningen refererar till den nya imagens digest, inte till en vandrande tagg.
- Först staging, sedan produktion: Automatiska tester på en kopia fångar upp brott orsakade av nya basimages.
- Kontrollera i drift: Kör efter utrullningen
php -vi den körande containern och jämför digesten med bygget. - Begränsa återvägen: Den gamla imagen finns kvar för en kort återväg, men innehåller det sårbara PHP.
För Kubernetes gäller egna regler, till exempel om pull-policy; de står under Patcha PHP i Kubernetes.
Typiska luckor i kedjan
- Build-cache på runnern: Utan
--pulloch--no-cacheåteranvänds den gamla basimagen. - Registerspegel: Ett internt mellanlager levererar fortfarande den gamla nivån av basimagen.
- Flerstegsbyggen: PHP-versionen i det sista steget räknas, men ofta kontrolleras bara det första.
- Sidoimages: Queue-workers, cron-containrar och interna verktyg har egna pipelines eller inga alls.
- Fastskrivna digests: En digest för basimagen som en gång lagts fast uppdateras aldrig om inget verktyg bevakar den.
En ombyggnad ersätter PHP, inte data. Skadlig kod som före patchen har kommit in i volymer, uppladdningsmappar eller databasen finns kvar och måste granskas separat.
Vem reagerar när ombyggnaden misslyckas?
En automatisk ombyggnad är bara så bra som reaktionen på att den misslyckas. Slår versionskontrollen larm eller avbryts bygget på grund av en ändrad basimage måste någon märka det. I många team hamnar sådana meddelanden i en brevlåda som ingen läser, eller i en kanal där röda byggen sedan länge är vardag.
En tydlig regel har visat sig fungera: ett misslyckat säkerhetsbygge är ett ärende med ansvarig och tidsfrist, inte en notis bland många. Notera dessutom för varje utrullad image datum, digest och kontrollerad PHP-version. Den listan svarar vid nästa meddelande på några minuter på vilka applikationer som berörs, och fungerar som bevis gentemot revisorer eller försäkringsbolag. Hur detta blir ett varaktigt förlopp beskrivs i Patchhantering som process i stället för brandkår.
Hur hjälper PHP SOS konkret?
- Granska pipelines: Vi tittar på era bygg- och utrullningskedjor och visar var en patch kan fastna.
- Automatisera ombyggnaden: Vi sätter upp tidsstyrda builds, versionskontroll och utrullning via digest.
- Fånga alla images: Vi kopplar varje körande container till sin pipeline, även sido- och äldre images.
- Sköta löpande: I säkerhetsunderhållsavtalet följer vi säkerhetsmeddelanden och sätter igång ombyggnader.
Vanliga frågor
Hur ofta bör en PHP-image byggas om?
Någon fast siffra finns inte. Ett regelbundet tidsstyrt bygge har visat sig fungera, till exempel varje vecka, plus ett omedelbart bygge vid säkerhetsmeddelanden. Avgörande är att en ny patch inte behöver vänta på nästa kodändring.
Räcker ett lyckat bygge som bevis?
Nej. Ett bygge bevisar bara att en ny image finns. Först när de körande containrarna har skapats på nytt från den imagen och php -v i dem visar den rättade versionen är patchen verksam.
Varför dyker den gamla PHP-versionen upp trots ombyggnaden?
Vanliga orsaker är en build-cache som återanvänder den gamla basimagen, en registerspegel med gammal nivå eller en andra FROM-rad i ett flerstegsbygge. Bygg med --pull och --no-cache och kontrollera varje steg.
Kan Dependabot uppdatera basimages?
Enligt GitHub-dokumentationen stöder Dependabot ekosystemet Docker för versions- och säkerhetsuppdateringar. Det föreslår ändringar av basimages som pull request. Ombyggnad vid oförändrad tagg ersätter det inte.