PrestaShop GitHub : dépôts officiels, vérification et sécurité anti-forks

Table des matières :

1. Dépôts officiels PrestaShop sur GitHub : ce qui est « source de vérité » et ce qui ne l’est pas
2. Menaces réelles : forks malveillants, « lookalikes », et attaques supply chain sur modules
3. Vérification d’un dépôt PrestaShop : identité, historique Git, signatures, tags
4. Chaîne de build anti-forks : pinning, SBOM, provenance, et CI reproductible
5. Procédure opérationnelle en prod : revue, détection de divergence, et durcissement côté boutique

Dépôts officiels PrestaShop sur GitHub : ce qui est « source de vérité » et ce qui ne l’est pas

Sur GitHub, « PrestaShop » ne veut rien dire en soi : ce qui compte, c’est l’organisation (owner), l’historique, les signatures, et la manière dont vous consommez le code (tag, commit SHA, artefact de build). Le point de départ reste l’organisation GitHub PrestaShop : https://github.com/PrestaShop. Le dépôt du cœur est historiquement PrestaShop/PrestaShop : https://github.com/PrestaShop/PrestaShop. Pour un intégrateur ou un dev module, c’est typiquement la seule référence acceptable quand il s’agit de diagnostiquer un bug du core, de vérifier un patch de sécurité, ou de recouper un diff.

Ce qui « fait foi » en pratique (et ce qui ne fait pas foi) :

• Fait foi
• un commit SHA précis (référence immuable) ;
• un tag (idéalement signé) qui pointe vers un commit précis ;
• un artefact construit en CI et rattaché à un commit (quand votre chaîne de build est contrôlée).
• Ne fait pas foi (seul)
• le nom du repo (ex. PrestaShop-x.y.z, prestashop-core, prestashop-official) ;
• un ZIP « pris sur GitHub » sans traçabilité ;
• un fork qui « a l’air actif » mais dont vous ne maîtrisez ni la gouvernance ni les releases.

Point souvent mal compris côté équipes e-commerce : les “Source code (zip/tar.gz)” affichés par GitHub dans une page de release sont des archives de sources générées à partir d’un tag, pas forcément un paquet « prêt prod ». Selon les projets, ces archives peuvent ne pas inclure des dépendances installées (ex. vendor/), des assets compilés, ou des étapes de build. Pour PrestaShop, ça compte : la différence entre sources et distribution peut conditionner la présence des dépendances PHP, des assets, ou des fichiers attendus en production (et donc vos risques de dérive si quelqu’un « complète » le paquet à la main).

Le reste de l’écosystème officiel est éclaté : modules « natifs » extraits du core, modules maintenus séparément, tooling CI, docs. Cette dispersion est une source classique d’erreurs en prod : on voit des équipes « patcher » un module depuis un fork GitHub parce que « ça marche », puis oublier qu’en PrestaShop 9 l’architecture (services, contrôleurs Symfony, Twig) change la surface de compatibilité. Si vous êtes en train d’adapter vos développements à PrestaShop 9, recoupez systématiquement vos choix de branches/tags avec les changements d’architecture documentés et vos propres contraintes de stack (PHP, Symfony, dépendances). À ce sujet, vous avez déjà un bon cadrage côté code et compatibilité ici : PrestaShop 9 : adapter modules et thèmes aux contrôleurs services et Twig.

Contexte d’exécution pour les exemples ci-dessous : PrestaShop 8.2.x / 9.x, PHP 8.2 (CLI), Git ≥ 2.40, GnuPG (ou signatures SSH Git). Tout ce qui touche à la vérification cryptographique (tags/commits) et au chaînage CI (provenance/SBOM) est applicable quelle que soit votre version, mais les procédures de déploiement diffèrent selon que vous utilisez un zip « release », un checkout Git, ou une image Docker.

Menaces réelles : forks malveillants, « lookalikes », et attaques supply chain sur modules

Un fork GitHub n’est pas automatiquement malveillant ; c’est même le workflow standard de contribution. Le problème commence quand un fork devient une source de distribution (zip téléchargé, module installé depuis une URL, dépendance Composer pointée sur un repo GitHub), sans garde-fous. Une attaque typique : un fork copie le README, garde le nom du module, ajoute une release « stable », et injecte une charge utile discrète (exfiltration de cookies, webshell PHP, backdoor dans un override). Dans PrestaShop, les zones « idéales » pour une injection durable sont connues : override/, des hooks d’affichage, des contrôleurs back-office, ou des endpoints AJAX.

À côté des forks « directs », il faut aussi compter avec les lookalikes (typosquatting et homographes) :

• un repo dont le nom diffère d’un caractère (ps_checkout vs ps-checkout, prestashop vs prestasһop avec un caractère unicode) ;
• une organisation au nom proche (PrestaShopTeam, Prestashop-Official, etc.) ;
• un module « ré-uploadé » avec un changelog rassurant, mais sans lien clair vers l’upstream.

Le vecteur « module » est particulièrement rentable : vous donnez à du code non vérifié un accès direct au contexte boutique, aux sessions, parfois aux webservices et à la DB. Sur une boutique exposée, un module malveillant peut : (1) siphonner des PII (clients, adresses), (2) modifier le checkout (injection de JS), (3) créer un compte admin et persister, (4) poser une charge additionnelle (miner, proxy). C’est exactement le type de risque couvert par OWASP Top 10 2021 A08: Software and Data Integrity Failures (intégrité des mises à jour, dépendances, pipelines) : https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/. Et contrairement à une CVE classique, c’est souvent silencieux : pas de crash, pas de 500, juste une fuite.

Mini-scénario (vu et revu en agence / TMA) : un prestataire propose « un correctif rapide » pour un bug de checkout. Il fournit un ZIP GitHub « prêt à installer ». En réalité, le ZIP vient d’un fork : le correctif est réel mais un fichier JS a été ajouté dans un hook d’affichage du tunnel, injectant un script de skimming (exfiltration de données de formulaire). La boutique continue de vendre ; la fuite n’est détectée qu’après des rétrofacturations. En France/UE, cela peut rapidement devenir un sujet conformité : le RGPD impose notamment une notification à l’autorité de contrôle dans les 72 heures en cas de violation de données personnelles (RGPD, art. 33), selon la gravité et le contexte.

Deux conséquences très concrètes pour PrestaShop :

1. votre surface d’attaque dépend autant du core que des modules et de leur provenance ;
2. « télécharger un zip sur GitHub » doit être traité comme un acte de déploiement à risque (même si le code « ressemble » à l’officiel).

Pour mettre des contrôles côté infra (WAF, règles spécifiques, réduction des faux positifs) sans casser le checkout, vous pouvez croiser avec : WAF PrestaShop : réduire les faux positifs et sécuriser le checkout.

Vérification d’un dépôt PrestaShop : identité, historique Git, signatures, tags

Le premier filtre est bête mais efficace : l’owner. Un dépôt john-doe/PrestaShop ou prestashop-core/PrestaShop n’est pas « le core » ; c’est un miroir/fork. Même dans l’organisation officielle, vérifiez la cohérence : ancienneté du repo, activité des mainteneurs, issues/PR, présence de SECURITY.md, et surtout correspondance entre tags et releases.

Ajoutez aussi quelques vérifications « d’hygiène » rapides, très utiles en audit :

• URL de remote (éviter le “j’ai cloné depuis un Gist / un mirror”) ;
• absence de redirections ou de remotes multiples non justifiées ;
• présence de tags annotés (souvent plus sérieux que des tags légers, même si ce n’est pas une garantie de sécurité).

Ne vous contentez pas d’un nom : utilisez la recherche de code GitHub pour tracer une fonction, un hook ou une constante (typiquement là où les backdoors aiment se cacher), et comparez avec le dépôt officiel. Guide utile côté méthode : Recherche de code GitHub : filtres, qualificateurs et recherches enregistrées.

Le second filtre : signature des commits/tags. GitHub explique le fonctionnement du badge Verified (et ses prérequis) ici : https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification. En CLI, ne restez pas au niveau UI. Préférez un checkout sur tag, et vérifiez localement :

# 1) Cloner depuis l'URL officielle (ou la vérifier)
git clone https://github.com/PrestaShop/PrestaShop.git
cd PrestaShop

# 2) Lister et vérifier un tag (si signé)
git fetch --tags
git tag -v 9.0.0  # exemple

# 3) Vérifier une signature de commit
git log --show-signature -n 5
git verify-commit <sha1>

Pour les équipes qui veulent industrialiser : documentez quelle clé (ou quel ensemble de clés) vous acceptez pour signer, et où vous stockez cette « liste d’autorités » (ex. coffre-fort de secrets interne, repo infra). Sans cette étape, « vérifier une signature » peut se réduire à valider n’importe quelle clé inconnue, donc à se rassurer à tort.

Troisième filtre : cohérence de l’historique. Un fork malveillant peut conserver des tags identiques en noms, mais pas en SHAs ; ou rebaser l’historique. Comparez rapidement :

# Vérifier la remote et l'upstream
git remote -v

# Comparer un tag officiel vs un tag d’un fork (après ajout d’une remote)
git remote add fork https://github.com/<owner>/<repo>.git
git fetch fork --tags

git rev-parse 9.0.0
git rev-parse fork/9.0.0

git diff 9.0.0 fork/9.0.0 --stat

Deux signaux d’alerte fréquents quand un fork sert à « distribuer » :

• des tags qui existent en nom mais pointent vers des commits différents (SHAs divergents) ;
• des commits « massifs » juste avant un tag (beaucoup de fichiers changés, peu d’explications), souvent au moment où quelqu’un veut glisser une modification difficile à repérer.

Limite importante : un badge Verified ne vaut que si vous faites confiance à l’identité associée à la clé (GPG/SSH) et à la gouvernance du repo. Autrement dit, la signature garantit l’intégrité par rapport à une clé, pas la légitimité du code. En contexte équipe/CTO, c’est là qu’on bascule vers des exigences de gouvernance (règles de branches, revues obligatoires, clés mainteneurs) et des contrôles automatisés.

Chaîne de build anti-forks : pinning, SBOM, provenance, et CI reproductible

La manière la plus courante d’« avaler » un fork, ce n’est pas git clone, c’est l’automatisation : un composer.json pointé sur un repository VCS GitHub, un pipeline qui télécharge un zip, ou un script d’intégration qui met à jour un module sans review. La règle de base : pinner ce qui doit l’être.

Recommandations pragmatiques qui évitent 80% des incidents « on a installé sans vouloir » :

• Git : pin sur un commit SHA (le plus strict) ou un tag signé (le plus lisible) ; évitez les branches flottantes.
• Composer : verrouillez avec composer.lock, interdisez les mises à jour transverses en prod (mise à jour = changement contrôlé), et exécutez composer audit en CI.
• Téléchargements : évitez les curl | bash et les ZIP non tracés ; si vous devez passer par une archive, stockez-la en interne (artefact repository) avec un checksum, un auteur et une date.

Évitez les dépendances « flottantes » (dev-master, branches non taguées) : c’est une porte ouverte aux substitutions. Dans des environnements multi-prestataires (agence + freelance + TMA), c’est aussi un garde-fou organisationnel : vous réduisez la capacité d’un acteur (même de bonne foi) à « hotfixer » en contournant la revue.

Ensuite, ajoutez de la visibilité machine : SBOM + provenance. La SBOM (Software Bill of Materials) est l’inventaire des composants livrés ; la provenance décrit comment l’artefact a été construit (qui, quoi, quand, avec quel workflow). Sur ce sujet, SLSA (Supply-chain Levels for Software Artifacts) est une bonne base de cadrage et de vocabulaire : https://slsa.dev/. Dans un contexte PrestaShop, l’intérêt est très concret :

• si vous construisez un zip de module, vous pouvez associer l’artefact à un commit + workflow ;
• si vous construisez une image Docker pour PrestaShop, vous pouvez rattacher l’image à une SBOM (dépendances OS + PHP + composer) et à un historique de build ;
• en cas d’incident, vous répondez plus vite à « qu’est-ce qui a été déployé exactement ? » (et pas seulement « on pense que c’était la v1.2.3 »).

Côté outillage, vous n’êtes pas obligé de tout réinventer : OpenSSF Scorecard donne une grille d’évaluation automatisable des pratiques supply chain (signatures, protections de branches, dépendances, etc.) : https://github.com/ossf/scorecard. Ce n’est pas « spécifique PrestaShop », mais les checks pertinents le sont : branch protection, signatures, token permissions, CI durcie, revue obligatoire.

Pour une mise en œuvre PrestaShop ciblée (SBOM, provenance, validation en CI), vous pouvez chaîner avec : CI PrestaShop : provenance, SBOM et validation automatique des modules et Intégration continue PrestaShop : BuildKit, GitHub Actions et build reproductible.

Procédure opérationnelle en prod : revue, détection de divergence, et durcissement côté boutique

Même avec des signatures et une CI propre, le dernier kilomètre reste votre boutique. Une règle simple : aucun code tiers ne passe en production sans revue minimale et traçabilité (commit/tag, source, diff). Pour un module récupéré sur GitHub, faites une revue ciblée sur les zones à haut risque : override/, contrôleurs BO, scripts JS injectés dans le front, hooks checkout, et toute fonction qui touche au réseau (curl, file_get_contents vers HTTP), à l’écriture disque, ou à la création d’admins. Si vous manquez de bande passante, automatisez une partie (grep de patterns, scan SAST), mais ne remplacez pas la revue par « ça compile ».

Une revue « minimale mais efficace » (15–30 minutes) ressemble souvent à ça :

• regarder la liste des fichiers ajoutés (un backdoor est fréquemment un nouveau fichier, pas une modification) ;
• repérer les accès réseau sortants (URL hardcodées, domaines opaques) ;
• repérer l’écriture de fichiers PHP/JS (upload “d’assets”, génération de cache suspecte) ;
• repérer l’accès à des secrets (tokens, clés API) ou à Configuration::updateValue() sur des clés non documentées.

La détection de forks déguisés en « patch » passe bien via des diffs reproductibles. Exemple concret : vous avez un module installé manuellement, et quelqu’un vous dit « c’est juste une correction ». Mettez le repo officiel en remote, comparez et listez les fichiers ajoutés. Si vous voyez des ajouts dans controllers/admin/ sans raison, ou des fichiers PHP au nom « utilitaire » (helper.php, cache.php), stoppez le déploiement. Dans PrestaShop, un seul fichier mal placé peut suffire à ouvrir une porte persistante (webshell accessible via une URL).

Un réflexe simple qui évite beaucoup d’ambiguïtés : exigez que tout correctif « urgent » soit livré sous forme de diff (PR, patch, ou liste de commits) plutôt que sous forme d’archive. Une archive écrase le contexte (d’où ça vient ? qu’est-ce qui a changé ?), alors qu’un diff se discute et se relit.

Sur les pratiques d’hygiène module (désinstallation propre, réduction de surface d’attaque, performances), recoupez avec : Modules PrestaShop : désinstallation propre, performances et sécurité en production.

Enfin, durcissez l’exploitation pour que l’impact d’un module compromis soit borné : permissions strictes, monitoring, et rollback. Un module malveillant aime écrire ; si votre hébergement permet à PHP d’écrire partout, vous facilitez la persistance. Quelques pratiques généralement compatibles avec des hébergements FR/EU (mutualisé, VPS, cloud) :

• Séparer “déploiement” et “exécution” : idéalement, PHP-FPM ne doit pas pouvoir modifier le code applicatif en permanence ; on déploie via un utilisateur/deploy, pas via le runtime.
• Réduire l’écriture : autorisez l’écriture uniquement là où c’est nécessaire (cache, uploads). Plus vous laissez modules/ et override/ modifiables en continu, plus un malware peut se maintenir.
• Surveiller l’intégrité : à défaut d’un outil dédié, un checksum quotidien (ou à chaque déploiement) sur modules/ et override/ + alerte sur divergence donne déjà un excellent rapport effort/gain.
• Surveiller les événements sensibles : création/modification d’employés (admins), changements de configuration critiques, nouveaux endpoints exposés.

Pour outiller cette partie, vous avez deux points d’ancrage internes : Maintenance PrestaShop : managed services, sécurité serveur, sauvegardes chiffrées et PrestaShop monitoring d’erreurs : logs PHP, MySQL, JavaScript et alertes e-mail.

Checklist « anti-forks » (consommation GitHub) à appliquer avant toute mise en prod :

• Source : owner = organisation attendue (ex. PrestaShop/*), URL remote contrôlée (git remote -v).
• Versionning : utilisation d’un tag (idéalement signé) ou d’un commit SHA pin.
• Signatures : vérification locale git tag -v / git verify-commit ; pas seulement le badge UI.
• Diff : comparaison avec l’upstream officiel (git diff upstream/tag..votre/tag), avec focus sur nouveaux fichiers et code réseau/écriture disque.
• CI : build reproductible, artefacts liés au commit, SBOM/provenance si possible.
• Prod : permissions d’écriture minimales, monitoring + alerte, plan de rollback testé (cf. vos checklists de migration si vous touchez au core : Migration PrestaShop 9 : sécurité, tests et plan de rollback).

Si vous appliquez ces contrôles de manière systématique, les forks redeviennent ce qu’ils devraient être : un outil de contribution et d’expérimentation, pas un canal de distribution implicite vers votre production.