# CI/CD : reconstruire automatiquement les images PHP

> Reconstruire automatiquement des images Docker : builds planifiés, contrôle de version dans le pipeline et déploiement par digest pour que les correctifs PHP arrivent.

Source : https://phpsos.de/fr/blog/php-images-in-ci-neu-bauen/  
État : 25/10/2026  
Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6

**En bref :** une image Docker contient PHP dans l'état de son moment de construction et vieillit même sans modification de code. Qui reconstruit automatiquement les images, de façon planifiée et lors d'avis de sécurité, vérifie la version de PHP dans le pipeline et déploie par digest, amène en production, de façon planifiable, des correctifs comme celui contre PHP2Shell. Un build vert seul n'est pas une preuve ; ce qui compte, c'est la version dans le conteneur en cours.

## Pourquoi les images vieillissent sans modification de code

Dans de nombreuses équipes, le pipeline de build ne démarre que lorsque quelqu'un modifie du code. Pour l'application, c'est logique. Pour la sécurité, c'est un problème, car le PHP de l'image provient de l'image de base au moment du dernier build.

PHP2Shell l'a rendu visible. Les versions corrigées 8.5.12, 8.4.27, 8.3.36 et 8.2.35 sont parues le 21 octobre 2026. Un projet sur lequel personne n'a travaillé ces jours-là n'a pas reçu de nouveau build et a continué de tourner avec l'ancien PHP, alors que l'image de base était depuis longtemps à jour. La voie manuelle pour sortir de cette situation est décrite dans [Corriger PHP dans les conteneurs Docker](https://phpsos.de/fr/php2shell/docker-container-patchen/). Cet article montre comment l'automatiser.

## Reconstruire automatiquement des images Docker : trois déclencheurs

Un processus robuste combine plusieurs déclencheurs, afin qu'aucun ne doive tout porter seul.

| Déclencheur | Mise en œuvre | À noter |
|---|---|---|
| Planning | workflow planifié, par ex. chaque semaine | récupère les correctifs même sans modification de code |
| Nouvelle image de base | outil qui surveille les images de base et propose des modifications | agit surtout avec des tags de version fixes |
| Avis de sécurité | démarrage manuel du pipeline par l'équipe d'exploitation | exige un responsable clairement désigné |

Avec GitHub Actions, l'événement `schedule` assure le planning. Selon la documentation de GitHub, il utilise la syntaxe cron à cinq champs, s'exécute en UTC et seulement sur la branche par défaut. Les exécutions planifiées peuvent démarrer avec retard en cas de forte charge, et dans les dépôts publics, GitHub les désactive après 60 jours sans activité. Ce dernier point touche précisément les projets calmes, donc ceux qui ont le plus besoin de la reconstruction automatique.

Pour le deuxième déclencheur, Dependabot prend en charge, selon la documentation de GitHub, l'écosystème `docker` et propose sous forme de pull request les nouveaux états des images de base. Deux restrictions sont à connaître. Premièrement, quelqu'un doit examiner et fusionner la pull request, sinon elle reste en plan. Deuxièmement, avec un tag de branche comme `php:8.3-fpm`, rien ne change dans le Dockerfile quand l'image de base est reconstruite. Un outil qui propose des modifications de texte n'a alors rien à proposer. C'est précisément pourquoi la reconstruction planifiée est en plus nécessaire.

Le troisième déclencheur paraît banal, mais échoue souvent en pratique sur la question de savoir qui le déclenche. Déterminez qui suit les avis de sécurité sur PHP et qui peut démarrer le pipeline, y compris le week-end. Avec PHP2Shell, il n'y a eu qu'un jour entre l'annonce préalable et le correctif.

## Un pipeline qui intercepte un PHP obsolète

L'exemple suivant pour GitHub Actions construit l'image chaque semaine et sur simple clic, vérifie la version de PHP et s'interrompt si elle est inférieure à l'état corrigé. Adaptez le registre, les noms et la version minimale.

```yaml
name: php-image-rebuild
on:
  schedule:
    - cron: "0 3 * * 1"      # le lundi à 03:00 UTC
  workflow_dispatch: {}      # démarrage manuel lors d'avis de sécurité

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

Le contrôle de version fonctionne avec les images PHP officielles, dont le numéro de version indique l'état réel. Si votre image utilise des paquets PHP d'une distribution, le numéro reste souvent identique après un rétroportage. Vérifiez alors, au lieu du numéro, le changelog du paquet pour les numéros CVE, comme décrit dans l'article [Prouver les numéros CVE dans le changelog d'un paquet](https://phpsos.de/fr/blog/cve-im-changelog-nachweisen/).

Après le contrôle, trois autres étapes suivent en pratique : analyser l'image à la recherche de vulnérabilités connues, la pousser dans le registre avec date et digest, et transmettre le digest au déploiement. Quels tags et quelles variantes conviennent comme base, [Images Docker PHP officielles](https://phpsos.de/fr/blog/offizielle-php-docker-images/) l'explique.

## Du build au conteneur en cours

L'erreur de raisonnement la plus fréquente : le pipeline est vert, donc tout est corrigé. En réalité, la nouvelle image n'est que dans le registre. Le correctif ne devient effectif que lorsque chaque conteneur a été recréé à partir de la nouvelle image.

1. **Déployer par digest :** le déploiement référence le digest de la nouvelle image, pas un tag mouvant.
2. **D'abord la préproduction, puis la production :** des tests automatiques sur une copie détectent les ruptures causées par de nouvelles images de base.
3. **Contrôler en exploitation :** après le déploiement, exécuter `php -v` dans le conteneur en cours et comparer le digest avec celui du build.
4. **Limiter le retour arrière :** l'ancienne image reste disponible pour un bref retour arrière, mais contient le PHP vulnérable.

Dans Kubernetes, des règles propres s'appliquent, par exemple pour la politique de téléchargement (pull policy) ; elles figurent sous [Corriger PHP dans Kubernetes](https://phpsos.de/fr/server/kubernetes/).

## Lacunes typiques dans la chaîne

- **Cache de build sur le runner :** sans `--pull` et `--no-cache`, l'ancienne image de base est réutilisée.
- **Miroir de registre :** un cache interne sert encore l'ancien état de l'image de base.
- **Builds multi-étapes :** la version de PHP de la dernière étape compte, mais on ne vérifie souvent que la première.
- **Images annexes :** workers de file d'attente, conteneurs cron et outils internes ont leurs propres pipelines, ou aucun.
- **Digests figés :** un digest de l'image de base une fois figé n'est jamais mis à jour si aucun outil ne le surveille.

> **Important:**
> Une reconstruction remplace PHP, non les données. Le code malveillant entré avant le correctif dans des volumes, des répertoires de téléversement ou la base de données subsiste et doit être vérifié séparément.

## Qui réagit quand la reconstruction échoue ?

Une reconstruction automatique ne vaut que par la réaction à son échec. Si le contrôle de version se déclenche ou si le build s'interrompt à cause d'une image de base modifiée, quelqu'un doit le remarquer. Dans de nombreuses équipes, de tels messages atterrissent dans une boîte que personne ne lit, ou dans un canal où les builds rouges sont depuis longtemps monnaie courante.

Une règle claire a fait ses preuves : une reconstruction de sécurité échouée est un ticket avec un responsable et une échéance, non une remarque parmi d'autres. Consignez en outre pour chaque image déployée la date, le digest et la version de PHP vérifiée. Cette liste répond en quelques minutes, lors du prochain avis, à la question de savoir quelles applications sont concernées, et sert de preuve face aux auditeurs ou aux assureurs. La façon d'en faire un déroulement durable est décrite dans [Gestion des correctifs comme processus plutôt que pompiers](https://phpsos.de/fr/blog/patch-management-prozess/).

## Comment PHP SOS aide-t-il concrètement ?

- **Examiner les pipelines :** nous examinons vos chaînes de build et de déploiement et montrons où un correctif peut rester bloqué.
- **Automatiser la reconstruction :** nous mettons en place des builds planifiés, un contrôle de version et un déploiement par digest.
- **Recenser toutes les images :** nous rattachons à chaque conteneur en cours son pipeline, y compris les images annexes et anciennes.
- **Assurer un suivi durable :** dans le [contrat de maintenance de sécurité](https://phpsos.de/fr/leistungen/security-wartungsvertrag/), nous suivons les avis de sécurité et déclenchons les reconstructions.


## Questions fréquentes

**À quelle fréquence faut-il reconstruire une image PHP ?**  
Il n'existe pas de chiffre fixe. Un build planifié régulier, par exemple chaque semaine, plus un build immédiat lors d'avis de sécurité, a fait ses preuves. L'essentiel est qu'un nouveau correctif n'ait pas à attendre la prochaine modification de code.

**Un build réussi suffit-il comme preuve ?**  
Non. Un build prouve seulement qu'une nouvelle image existe. Le correctif n'est effectif que lorsque les conteneurs en cours ont été recréés à partir de cette image et que php -v y affiche la version corrigée.

**Pourquoi l'ancienne version de PHP apparaît-elle quand même après la reconstruction ?**  
Des causes fréquentes sont un cache de build qui réutilise l'ancienne image de base, un miroir de registre à l'ancien état ou une deuxième ligne FROM dans un build multi-étapes. Construisez avec --pull et --no-cache et vérifiez chaque étape.

**Dependabot peut-il mettre à jour les images de base ?**  
Selon la documentation de GitHub, Dependabot prend en charge l'écosystème Docker pour les mises à jour de version et de sécurité. Il propose les modifications des images de base sous forme de pull request. Cela ne remplace pas la reconstruction lorsque le tag reste identique.

## Sources

- [GitHub Docs : événements qui déclenchent des workflows (schedule)](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows)
- [GitHub Docs : écosystèmes pris en charge par Dependabot](https://docs.github.com/en/code-security/dependabot/ecosystems-supported-by-dependabot/supported-ecosystems-and-repositories)
- [Docker Hub : image PHP officielle](https://hub.docker.com/_/php)
- [PHP : versions prises en charge](https://www.php.net/supported-versions.php)