Aller au contenu
Le journal

Notes & retours d’expérience

Vérifier ce qu'on installe : la chaîne d'approvisionnement logicielle d'une PME

11 min de lecture

En octobre, OVHcloud, Rank Math et 345 dépôts GitHub ont distribué du code malveillant sans que leur code source soit touché, pendant qu'un logiciel espion visait les sessions des assistants de code. Ce que ces cas ont en commun, et le plan d'action d'une PME, maillon par maillon.

En dix jours, trois éditeurs ont distribué du code malveillant sans que leur propre code source soit touché. Le 8 octobre, deux comptes de mainteneurs piratés ont glissé un faux workflow « Security Audit » dans 345 dépôts GitHub, dont un dépôt d'Uber. Entre le 15 et le 16 octobre, l'extension WordPress Rank Math PRO a livré une porte dérobée par son propre canal de mise à jour. Le 19 octobre, l'outil en ligne de commande d'OVHcloud a été remplacé sur GitHub par une version qui vole les secrets du disque. Pendant ce temps, Symantec documentait un logiciel espion qui cible désormais les fichiers de session de Claude, Codex et Cursor.

Pris un par un, ce sont des incidents. Mis bout à bout, ils disent la même chose à une PME : le fichier que vous installez n'est pas forcément celui que l'éditeur a publié, et la mise à jour automatique, que l'on recommande à juste titre, est aussi le chemin le plus court vers vos serveurs. Voici ce que montrent ces quatre cas, et ce que je mettrais en place quand on n'a pas d'équipe sécurité.

Quatre maillons, quatre incidents

Le compte du développeur : OVHcloud

Le 19 octobre, entre 14 h 47 et 16 h 21 (heure de Paris), les binaires des versions 0.11.0 à 0.15.0 de ovhcloud-cli ont été remplacés sur GitHub par un programme chargé de récupérer les secrets présents sur le disque. Selon l'avis publié par OVHcloud, ni le code source ni la chaîne de compilation n'ont été touchés : l'attaquant a utilisé le compte GitHub d'un développeur pour déposer de nouveaux fichiers sur des versions déjà publiées. Sur la version 0.15.0, il a aussi remplacé le fichier checksums.txt, si bien que les empreintes publiées correspondaient aux faux binaires, d'après The Hacker News.

Deux détails comptent. D'abord la cause racine, telle qu'OVHcloud la décrit : une extension, color-picker-universal, installée en octobre 2025 sur le MacBook personnel du développeur, liée par OVHcloud à la campagne Glassworm. Les clés volées ont servi un an plus tard. Ensuite, la correction : l'option GitHub qui rend une version immuable n'était pas activée. Octave Klaba l'a dit publiquement, une personne disposant des bons droits pouvait modifier une version existante sans passer par la CI. Et c'est un client qui a donné l'alerte, parce que son pipeline vérifiait l'empreinte SHA-256 du fichier téléchargé et a cassé.

Le canal de mise à jour de l'éditeur : Rank Math PRO

Rank Math PRO est la version payante d'une extension SEO dont la version gratuite compte plus de 4 millions d'installations actives. Selon l'éditeur, les copies de la version 3.0.123 téléchargées ou installées par mise à jour entre le 15 octobre à 22 h 02 et le 16 octobre à 9 h 12 (heure de Paris) contenaient un logiciel malveillant capable de recréer sa porte dérobée à chaque visite du site. Wordfence a enregistré l'incident sous le CVE-2026-111862, noté 9,8 sur 10.

Le piège est dans le numéro de version. La 3.0.123 existait depuis le 7 octobre ; seules les copies récupérées pendant la fenêtre sont touchées. Mettre à jour vers la 3.0.124 ne nettoie rien : l'éditeur recommande de restaurer une sauvegarde antérieure à l'incident et de changer tous les secrets que le site pouvait lire. The Hacker News relève que c'est au moins la troisième fois cette année qu'une extension WordPress premium livre une porte dérobée par le canal de son éditeur, après Smart Slider 3 Pro en avril et ShapedPlugin en juin. Rank Math n'a pas dit comment les fichiers ont été modifiés.

Le pipeline : GhostAction

Le 8 octobre, selon StepSecurity, les comptes de deux mainteneurs open source ont été utilisés pour pousser un fichier security-audit.yml dans 345 dépôts, en deux vagues de quelques minutes. Le workflow n'a rien d'un audit : il envoie en clair, vers une adresse IP, les secrets GitHub Actions du dépôt et toutes les clés qu'il trouve dans le code et dans l'historique Git complet. Une clé commitée puis supprimée il y a trois ans est donc récupérée. Le dépôt uber/athenadriver a été touché parce que son auteur d'origine y avait gardé un droit d'écriture : le commit est arrivé directement sur la branche principale, sans pull request ni relecture.

Le poste du développeur : Aoki

Le 15 octobre, Symantec a décrit les nouvelles versions du logiciel espion Aoki. En plus des navigateurs et des portefeuilles, elles récupèrent .claude.json, la configuration et le fichier .env de Codex, les jetons de Cursor, GitHub Copilot, Gemini, JetBrains AI Assistant et Kiro, ainsi que les identifiants AWS. Check Point décrit le même type de collecte. Un poste de développeur concentre aujourd'hui des jetons qui ouvrent les dépôts, le cloud et la CI, souvent avec des droits larges, et les assistants de code en ajoutent de nouveaux.

Schéma : la chaîne qui va de l'éditeur à votre serveur, avec quatre maillons compromis en octobre 2026 (poste du développeur, compte de publication, canal de mise à jour, pipeline CI) et le contrôle à mettre en face de chacun

Les quatre maillons touchés en octobre 2026, et le contrôle qu'une PME peut mettre en face de chacun.

Ce que ces cas ont en commun

Le code source était propre. Dans les cas OVHcloud et GhostAction, l'attaquant n'a pas modifié le code relu par l'équipe. Il est passé à côté : un fichier déposé sur une version existante, un workflow poussé directement. Relire le code ne protège pas de ce qui est ajouté après.

L'identité volée était légitime. Tous les commits et dépôts de fichiers ont été faits avec de vrais comptes, ayant de vrais droits. Rien dans un journal d'accès ne paraît anormal tant qu'on ne regarde pas le contenu. Le vol peut aussi être ancien : chez OVHcloud, un an sépare l'installation de l'extension et l'attaque.

La fenêtre est courte, et ce n'est pas rassurant. 94 minutes pour OVHcloud, environ onze heures pour Rank Math. Une mise à jour automatique ou une CI qui télécharge la dernière version sans vérification tombe dedans. Une installation manuelle faite le lendemain y échappe.

Le numéro de version ne prouve rien. Une même version peut être saine ou piégée selon l'heure du téléchargement. Seule l'empreinte du fichier fait foi, à condition de l'avoir notée avant.

La cible, ce sont les secrets. Les quatre cas visent la même chose : clés cloud, jetons d'API, mots de passe de base de données, accès aux dépôts. Ce que vous installez sert de transport ; ce qui intéresse l'attaquant, c'est ce que la machine peut lire.

Il faut garder la nuance. Mettre à jour vite reste indispensable, comme je l'écrivais dans l'article sur le patch des runtimes. Et les correctifs eux-mêmes ne sont pas toujours définitifs : Terra Security a mesuré qu'en 2026, 2,3 % des correctifs de sécurité publiés sur GitHub ont fait l'objet, dans les 90 jours, d'un nouvel avis signalant qu'ils avaient été contournés, contre environ 0,2 % entre 2019 et 2025. Il ne s'agit pas de ralentir les mises à jour, mais de savoir ce qui arrive par elles.

Le plan d'action pour une PME

Je l'ai découpé selon les quatre maillons. Rien n'exige d'outil payant ; la plupart des mesures prennent une heure.

1. Ce que vous téléchargez

  • Épingler les empreintes dans la CI. Pour chaque binaire téléchargé dans un pipeline ou un Dockerfile (CLI d'un fournisseur cloud, outil de build), noter l'empreinte SHA-256 dans votre dépôt et faire échouer le job si elle change. C'est exactement ce qui a détecté l'incident OVHcloud. Le fichier checksums.txt de l'éditeur ne suffit pas s'il est hébergé au même endroit que le binaire.
  • Épingler les versions des actions GitHub par leur hash de commit plutôt que par un tag, et figer les dépendances avec un fichier de verrouillage.
  • Pour les extensions WordPress premium, désactiver la mise à jour automatique sur les sites critiques, appliquer d'abord sur une préproduction et attendre quelques heures, sauf correctif de sécurité urgent. Pour les correctifs urgents, l'inverse s'applique : vite, mais avec une sauvegarde récente vérifiée juste avant.

2. Ce que vous publiez

  • Activer les versions immuables sur GitHub pour tous les dépôts qui publient des binaires. Une fois activée, l'option interdit de modifier les fichiers et le tag d'une version publiée, et GitHub génère une attestation vérifiable. Attention : elle ne s'applique qu'aux nouvelles versions.
  • Protéger la branche principale de chaque dépôt : pull request obligatoire, au moins une relecture, aucun push direct, y compris pour les administrateurs.
  • Faire le ménage dans les droits d'écriture. Anciens prestataires, auteurs d'origine, comptes de stagiaires : le cas Uber montre qu'un droit oublié suffit.

3. Votre pipeline

  • Inventorier les secrets de la CI et réduire leur portée : un jeton par usage, en lecture seule quand c'est possible, et une fédération OIDC vers le cloud plutôt qu'une clé longue durée.
  • Scanner l'historique Git, pas seulement le code actuel, avec un outil comme gitleaks ou trufflehog. Toute clé trouvée dans l'historique doit être considérée comme exposée et changée.
  • Surveiller les nouveaux fichiers de workflow. Un fichier .github/workflows/ qui apparaît sans pull request mérite une alerte. Si security-audit.yml ou github_actions_security.yml est apparu dans un de vos dépôts depuis fin août, StepSecurity recommande de traiter l'incident comme une fuite avérée.

4. Les postes des développeurs

  • Faire l'inventaire des extensions des éditeurs de code (VS Code, Cursor, JetBrains) et limiter les installations à une liste approuvée sur les postes qui ont accès à la production.
  • Traiter les sessions des assistants IA comme des identifiants. Les fichiers de configuration de Claude Code, Codex ou Cursor et les .env qui traînent dans les projets donnent accès à des comptes payants, parfois à du code et à des données. En cas de poste compromis, ils se révoquent comme un mot de passe.
  • Séparer le personnel et le professionnel. Chez OVHcloud, l'extension était sur un ordinateur personnel ; les clés, elles, ouvraient un dépôt de l'entreprise. Des clés SSH et des jetons distincts par machine, avec une durée de vie courte, limitent les dégâts.
  • Prévoir la procédure de rotation avant d'en avoir besoin : la liste des secrets, qui peut les changer, depuis quelle machine saine. Les avis d'OVHcloud et de Rank Math demandent tous deux de tout changer depuis un poste propre ; sans liste, cela prend des jours.

Si vous éditez un logiciel

Depuis le 11 septembre 2026, le Cyber Resilience Act oblige les fabricants de produits comportant des éléments numériques à signaler les vulnérabilités activement exploitées et les incidents graves, avec une première alerte sous 24 heures, via la plateforme unique de l'ENISA. Si votre PME publie un logiciel ou un objet connecté vendu dans l'Union, un incident comme celui d'OVHcloud ou de Rank Math entre dans ce cadre. Mieux vaut savoir qui déclare, et comment, avant d'en avoir un.

Ce qu'il faut retenir

La chaîne d'approvisionnement logicielle d'une PME n'est pas un sujet de grand groupe. C'est la CLI de votre hébergeur, l'extension SEO de votre site vitrine, le workflow de votre dépôt et l'assistant de code de votre développeur. Les attaques d'octobre n'ont rien de sophistiqué : elles exploitent des comptes légitimes, des options non activées et des secrets trop larges. La bonne nouvelle, c'est que les contrôles correspondants sont simples et pour la plupart gratuits.

Si vous voulez faire le point sur ces quatre maillons dans votre organisation, ou si un site WordPress de votre périmètre a reçu une mise à jour douteuse, c'est le genre de revue que je mène en tant que CTO indépendant, et vous pouvez me contacter.

Sources

Retour au journalEn parler ensemble
Tout le journal