Fournisseurs compromis : ce que ChipSoft et le ver npm Shai-Hulud apprennent aux PME sur leur chaîne d'approvisionnement

Le 7 avril 2026, un rançongiciel frappe ChipSoft, l'éditeur néerlandais du dossier patient électronique HiX. En quelques heures, l'incident déborde les frontières : des hôpitaux belges, clients du même éditeur, voient leurs services numériques aux patients tomber, sans avoir été visés ni compromis. Trois semaines plus tard, l'éditeur annonce que des données médicales volées ont été « détruites », sans dire s'il a payé.

En parallèle, dans un tout autre univers, un ver informatique nommé Shai-Hulud contamine l'écosystème npm en trois vagues entre septembre 2025 et mai 2026, en s'attaquant non pas aux entreprises mais aux outils avec lesquels elles construisent leurs logiciels.

Ces deux histoires racontent la même chose : votre niveau de sécurité n'est plus déterminé uniquement par ce que vous faites, mais aussi par ce que font les organisations dont vous dépendez. Chronologies vérifiées, mécanismes, et contre-mesures hiérarchisées pour une PME.

ChipSoft : chronologie d'un incident qui a débordé deux pays

Mardi 7 avril 2026. ChipSoft est frappé par un rançongiciel et son site web tombe. L'entreprise fournit le dossier patient électronique HiX à plus de 70 % des hôpitaux néerlandais — certaines sources avancent 76 % — ainsi qu'à des cabinets de médecine générale, des centres de rééducation et des cliniques. Le centre d'expertise néerlandais Z-CERT se coordonne dès ce jour avec l'éditeur et les établissements de soins, et recommande aux organisations de santé de couper leur connexion VPN vers ChipSoft (Skipr).

Dans les heures qui suivent. Les accès aux services Zorgportaal, HiX Mobile et Zorgplatform sont désactivés par précaution. Z-CERT indique qu'aucun soin critique n'a été interrompu ; selon un relevé de la NOS, onze hôpitaux néerlandais ferment leur portail patient. Côté belge, plusieurs établissements utilisant les solutions ChipSoft voient leurs services numériques aux patients perturbés : le réseau ZAS (Ziekenhuis aan de Stroom, Anvers), l'hôpital Oost-Limburg (ZOL) et AZ Delta (Roulers) (Security Affairs). Aucun n'a été attaqué directement.

Jeudi 16 avril 2026. Après avoir d'abord parlé d'un « incident de données », ChipSoft confirme que des données médicales de patients ont bien été volées, notamment des informations de traitement. Sont concernés des cabinets de généralistes, des cliniques de rééducation, l'Oogziekenhuis de Rotterdam et les utilisateurs de la plateforme HiX 365. Le directeur de l'entreprise déclare que cette appropriation de données est irréversible (Skipr).

Semaine du 20 avril 2026. Le groupe Embargo publie sur son site du dark web deux comptes à rebours et revendique le vol de 100 Go de données. ChipSoft confirme à la NOS être en négociation, sans plus de commentaire. La menace est ensuite retirée du site (NOS).

Mardi 28 avril 2026. ChipSoft annonce que les données volées ont été détruites et que ses experts en cybersécurité ont confirmé que « cette destruction a eu lieu de manière techniquement correcte ». L'entreprise refuse de dire si une rançon a été payée, et n'explique ni comment cette destruction a été vérifiée, ni comment elle peut garantir qu'aucune copie n'a été conservée (NOS).

Suites. L'inspection néerlandaise des infrastructures numériques (RDI) a ouvert une enquête sur les mesures de sécurité de ChipSoft, l'entreprise relevant de la loi néerlandaise Wbni comme fournisseur de services numériques essentiels. Plusieurs hôpitaux ont notifié une violation de données à l'autorité néerlandaise de protection des données ; ChipSoft indique être en contact avec elle, avec Z-CERT et avec le Centre pour la Cybersécurité Belgique (ICT&health).

Ce que l'affaire ChipSoft dit du rapport de force

Trois observations, qui valent bien au-delà de la santé.

Vous héritez de l'incident de votre fournisseur sans avoir voix au chapitre. Les trois hôpitaux belges cités n'ont commis aucune erreur de sécurité connue. Leur exposition venait d'un choix d'éditeur, parfaitement raisonnable, fait des années plus tôt.

Vous apprenez les faits en décalé, et par la presse. ChipSoft a parlé d'« incident de données » le 7 avril, et de vol confirmé de données médicales le 16. Neuf jours pendant lesquels ses clients devaient décider s'ils notifiaient une violation de données à leur autorité de protection. Ce décalage est structurel : l'investigation forensique prend du temps, et une entreprise en négociation communique sous contrainte juridique.

Le sort de vos données peut se jouer dans une négociation à laquelle vous n'êtes pas partie. « Les données ont été détruites » repose entièrement sur la parole d'un groupe criminel : c'est une information, pas une garantie. Un dirigeant dont les données clients transitent chez un prestataire devrait pouvoir répondre à une question simple : si mon fournisseur se fait voler mes données, qui décide de ce qui se passe ensuite ?

L'angle mort belge : le prestataire d'enregistrement partagé

Un exemple belge, moins médiatisé, illustre le même mécanisme à une autre échelle. En janvier 2026, dans le sillage de la cyberattaque contre l'hôpital AZ Monica, l'expert en sécurité Geert Baudewijns (Secutec) révèle que le prestataire chargé de l'enregistrement des patients chez AZ Monica sert aussi trois autres hôpitaux flamands. Une faille permettait d'obtenir les mots de passe des plateformes de ces établissements, ouvrant potentiellement l'accès à environ 71 000 dossiers patients : noms, adresses et numéros de registre national. Les failles ont été corrigées et rien n'indique qu'elles aient été exploitées par des criminels (VRT NWS).

Un fournisseur secondaire, invisible dans l'organigramme, exposant les données de quatre établissements à la fois. C'est le scénario que la plupart des cartographies de risques ne couvrent pas, parce qu'elles s'arrêtent aux fournisseurs stratégiques.

Shai-Hulud : trois vagues sur l'écosystème npm

Changement complet de décor. npm est le gestionnaire de paquets de l'écosystème JavaScript et Node.js : c'est par lui que transitent les briques logicielles réutilisées par la quasi-totalité des projets web modernes — y compris, très probablement, le site ou l'application de votre entreprise.

Vague 1 — septembre 2025. Entre le 14 et le 18 septembre 2025, un ver baptisé Shai-Hulud contamine plusieurs centaines de paquets, dont des bibliothèques très téléchargées comme @ctrl/tinycolor. L'accès initial vient d'une campagne d'hameçonnage visant les mainteneurs : de faux messages imitant npm invitent à « mettre à jour » leurs options d'authentification à plusieurs facteurs. Une fois un compte compromis, le code malveillant recherche les identifiants présents sur la machine ou dans l'environnement d'intégration continue — configuration npm, variables d'environnement, jetons GitHub, clés cloud —, les publie dans des dépôts GitHub publics, puis republie des versions piégées des autres paquets de la victime. C'est ce dernier point qui en fait un ver : il se propage seul, de mainteneur en mainteneur (Unit 42, Palo Alto Networks).

Vague 2 — « Shai-Hulud 2.0 », novembre 2025. Détectée le 24 novembre 2025 sous le nom « The Second Coming » : des centaines de paquets à nouveau touchés, et plus de 25 000 dépôts GitHub malveillants créés par environ 350 comptes pour y déverser les secrets collectés (Unit 42). Parmi les comptes de mainteneurs compromis, ceux de Zapier, PostHog et Postman. Changement technique majeur : l'exécution passe de la phase postinstall à la phase preinstall, donc avant les tests et les contrôles de sécurité du pipeline (Microsoft Security).

Vague 3 — « Mini Shai-Hulud », 11 mai 2026. Attribuée à un acteur nommé TeamPCP. Selon Microsoft, plus de 170 paquets npm et 2 paquets PyPI, sur 404 versions malveillantes (Microsoft Security), dont les espaces de noms @tanstack — avec @tanstack/react-router, l'une des bibliothèques de routage React les plus utilisées —, @uipath, @mistralai et @opensearch-project.

Cette troisième vague change la nature du problème : aucun identifiant de mainteneur n'a été volé. L'attaquant a créé une copie d'un dépôt public, soumis une proposition de modification qui déclenchait un enchaînement automatisé mal cloisonné, empoisonné le cache de la chaîne de construction, puis récupéré les jetons d'identité éphémères de la machine de compilation pour publier les paquets. Résultat : les paquets malveillants portaient des attestations de provenance valides — la signature disait vrai, elle attestait que le paquet venait bien du pipeline officiel du projet (Wiz).

Le code déposé collectait jetons d'intégration continue, identifiants cloud, comptes de service Kubernetes et jetons de registres, et installait sur les postes de développeurs un service de surveillance persistant doté d'une fonction destructrice si les jetons volés étaient révoqués. D'où une recommandation contre-intuitive de Wiz : retirer d'abord le composant de persistance, révoquer les jetons ensuite.

Comment un ver de dépendances se propage, étape par étape

Le schéma général, décrit au niveau qui sert à se défendre.

1. Prise de contrôle d'un point de publication : compte de mainteneur obtenu par hameçonnage (vagues 1 et 2), ou détournement de la chaîne de construction automatisée (vague 3).
2. Publication d'une version piégée d'un paquet légitime, avec un numéro de version plausible.
3. Exécution automatique à l'installation : les gestionnaires de paquets exécutent des scripts à l'installation. Une simple commande suffit à déclencher le code, sans que personne n'ait rien « ouvert ».
4. Collecte de secrets sur la machine ou dans le pipeline : jetons, clés d'API, identifiants cloud, variables d'environnement.
5. Exfiltration, historiquement vers des dépôts publics, plus récemment via plusieurs canaux redondants pour résister aux fermetures.
6. Réutilisation des jetons volés pour publier de nouvelles versions piégées — la boucle de propagation.
7. Persistance et destruction : maintien d'un accès, avec parfois une charge destructrice déclenchée par les tentatives de nettoyage.

Le point crucial pour un non-développeur : le serveur de construction est une cible de premier ordre, souvent bien plus permissive que la production. Il détient les clés de publication, il a accès au cloud, et il exécute par conception du code venu de l'extérieur.

Le cas Salesloft Drift : quand c'est l'intégration qui trahit

Troisième variante, celle qui touche les PME sans un seul développeur en interne.

Entre le 8 et le 18 août 2025, un acteur suivi par Google sous la référence UNC6395 a utilisé des jetons OAuth compromis de l'application Salesloft Drift, intégrée à Salesforce, pour extraire de grands volumes de données depuis des instances Salesforce d'entreprises. La cible n'était pas les données commerciales elles-mêmes, mais les secrets qui s'y trouvent parfois en clair : clés d'accès AWS, mots de passe, jetons Snowflake. Google a révoqué les jetons le 20 août, publié un avis le 26, et recommandé le 28 août de considérer tous les jetons Drift comme compromis (Google Cloud Threat Intelligence).

Note de rigueur : on lit souvent que « plus de 700 organisations » ont été touchées. Ce chiffre ne figure pas dans l'avis de Google, qui parle de « nombreuses instances Salesforce d'entreprises » sans publier de décompte. Je ne le reprends donc pas.

La leçon : chaque intégration tierce connectée à votre CRM, votre messagerie ou votre outil comptable est une porte permanente, souvent créée en trois clics par un utilisateur métier, et jamais réexaminée ensuite.

Pourquoi la chaîne d'approvisionnement est devenue la cible

Le calcul de l'attaquant est purement économique : compromettre un fournisseur, un paquet ou une intégration donne accès à des dizaines, des centaines, parfois des milliers d'organisations d'un coup. Trois facteurs structurels renforcent ce déséquilibre :

• La concentration. Un éditeur qui équipe plus de 70 % des hôpitaux d'un pays devient une infrastructure critique de fait, sans en avoir la gouvernance.
• La confiance implicite. Une dépendance logicielle, une mise à jour signée, une intégration approuvée sur une place de marché : tout cela entre dans les systèmes sans contrôle humain, par conception.
• La dilution de la responsabilité. Quand un incident survient chez un fournisseur de votre fournisseur, personne ne se sent propriétaire du risque.

L'ENISA note d'ailleurs que les attaquants ne visent plus seulement les paquets isolés mais l'ensemble du cycle de livraison : dépôts de code, automatisations, pipelines de construction (ENISA Threat Landscape 2025).

Signaux d'alerte, et questions à poser à un fournisseur

Signaux d'alerte côté technique :

• une mise à jour de dépendance qui modifie soudainement des scripts exécutés à l'installation ;
• des connexions sortantes inhabituelles depuis un serveur de construction ;
• des jetons ou clés utilisés depuis une adresse ou un pays inattendus ;
• un dépôt public récemment créé sous le nom de votre organisation, que personne ne revendique ;
• une publication de paquet à une heure où personne n'a publié.

Cinq questions à poser par écrit à un fournisseur critique, avant signature ou au renouvellement :

1. Dans quel délai me prévenez-vous en cas d'incident chez vous, et par quel canal ? Une réponse vague est déjà une réponse.
2. Que se passe-t-il pour mes données si vous êtes victime d'un rançongiciel ? Qui décide de négocier, et suis-je informé ?
3. Où sont mes données, et sous quelle forme puis-je les récupérer si je pars demain ? Un export exploitable et testé, pas une promesse contractuelle.
4. Qui sont vos propres sous-traitants critiques ? La question qui a manqué dans le cas du prestataire d'enregistrement partagé.
5. Quelle certification ou vérification détenez-vous, et pouvez-vous m'en montrer l'attestation ? CyFun, ISO 27001, ou rien — mais dites-le.

Contre-mesures, classées par rapport coût/efficacité

Niveau 1 — effet élevé, coût faible.

1. Une liste écrite de vos fournisseurs critiques : ce que chacun fait, à quelles données il accède, ce qui s'arrête s'il s'arrête, et un contact d'urgence nominatif. Une feuille de calcul suffit, et c'est le prérequis de tout le reste.
2. Un inventaire des intégrations tierces connectées à vos outils (messagerie, CRM, comptabilité, stockage) et la suppression de celles que personne n'utilise plus : les intégrations dormantes gardent leurs autorisations. C'est la mesure la plus rentable de la liste.
3. L'authentification multifacteur sur tous les comptes de publication et d'administration : registres de paquets, dépôts de code, consoles cloud, comptes fournisseurs.
4. Un plan B écrit pour vos deux ou trois dépendances les plus critiques : que fait-on si l'outil est indisponible trois jours ?

Niveau 2 — effet élevé, coût modéré.

1. Verrouiller les versions de dépendances et interdire les mises à jour automatiques non revues en production.
2. Réduire la durée de vie et la portée des jetons : éphémères plutôt que permanents, portée limitée, rotation planifiée.
3. Cloisonner la chaîne de construction : ne pas exposer les secrets de publication aux enchaînements automatisés déclenchés par des contributions externes — exactement la faille exploitée en mai 2026.
4. Un inventaire des composants logiciels (SBOM), même sommaire, pour répondre en une heure à « suis-je concerné par cette alerte ? ». Sans lui, chaque alerte publique coûte deux jours d'enquête.
5. Des clauses contractuelles de notification d'incident avec un délai chiffré.

Niveau 3 — pour les organisations plus mûres.

1. Analyse automatisée des dépendances dans le pipeline, avec des seuils de blocage définis.
2. Surveillance des publications sur vos propres paquets et dépôts, avec alerte sur toute publication non planifiée.
3. Un exercice « notre fournisseur principal est hors service 72 heures », une fois par an, avec les équipes métier et pas seulement l'informatique.

Ce que NIS2 exige sur la chaîne d'approvisionnement

L'article 21(2) de la directive NIS2 impose explicitement, au point (d), la sécurité de la chaîne d'approvisionnement, y compris les aspects de sécurité des relations entre chaque entité et ses fournisseurs ou prestataires directs. S'y ajoutent la sécurité de l'acquisition, du développement et de la maintenance des systèmes, ainsi que la gestion des vulnérabilités.

Pour une PME, cela se traduit de deux manières. Si vous êtes dans le champ de la loi, vous devez pouvoir démontrer que vous évaluez vos fournisseurs, que vous savez de qui vous dépendez, et que vous avez prévu ce qui se passe quand l'un d'eux tombe. Si vous n'y êtes pas, vos clients qui y sont répercuteront l'exigence par contrat : le reportage de la VRT sur les hôpitaux flamands rappelait explicitement que la législation oblige les organisations des secteurs essentiels à vérifier que leurs prestataires atteignent un niveau de sécurité comparable. Une PME informatique, un bureau d'études ou un cabinet comptable travaillant pour un hôpital, une banque ou un opérateur d'énergie recevra ces questions — questionnaire de sécurité, clause de notification, parfois demande d'attestation CyFun.

Les premières heures quand c'est votre fournisseur qui est touché

Le réflexe naturel est d'attendre des informations. C'est le mauvais réflexe : vous perdez les heures les plus utiles.

Heure 0 à 2.

1. Coupez ou restreignez les connexions permanentes vers le fournisseur : VPN, tunnels, accès distants, synchronisations automatiques. C'est exactement ce que Z-CERT a recommandé le 7 avril pour ChipSoft.
2. Révoquez les jetons, clés d'API et autorisations OAuth liés à ce fournisseur, et considérez-les comme compromis jusqu'à preuve du contraire — la consigne appliquée par Google dans l'affaire Drift.
3. Vérifiez si le fournisseur dispose d'un accès distant chez vous (télémaintenance, compte d'administration, agent installé). C'est le chemin de propagation le plus direct.

Heure 2 à 24. 4. Basculez sur votre plan B et prévenez les équipes métier de ce qui ne fonctionne plus. 5. Cherchez ce qui a pu sortir de chez vous : journaux d'accès, connexions inhabituelles, transferts sortants. Si la rétention de vos journaux est insuffisante, notez-le : c'est un point à corriger après la crise. 6. Demandez au fournisseur, par écrit, quelles données sont concernées, quel est le vecteur et quelles preuves il peut fournir. Gardez la trace de ses réponses et de ses délais. 7. Évaluez vos propres obligations : entité essentielle ou importante, l'article 23(4) de NIS2 impose une alerte précoce sous 24 heures, une notification sous 72 heures et un rapport final dans le mois ; le RGPD impose 72 heures pour une violation de données personnelles. Ces délais courent dès que vous prenez connaissance de l'incident, pas quand votre fournisseur termine son enquête.

Jours suivants. 8. Prévenez vos propres clients si leurs données peuvent être concernées : le silence coûte plus cher que le message imparfait. 9. Ne rétablissez la connexion qu'après confirmation écrite que le vecteur est refermé. 10. Documentez la chronologie pendant qu'elle est fraîche : elle servira pour l'assurance, le régulateur et la renégociation du contrat.

Ce que je retiens

En mettant côte à côte un éditeur de dossiers médicaux, un ver npm et une intégration marketing, le point commun n'est pas technique. C'est un transfert de confiance non documenté.

Trois hôpitaux belges faisaient confiance à un éditeur néerlandais. Des milliers de projets faisaient confiance à une bibliothèque de routage. Des entreprises faisaient confiance à une intégration installée un jour par une équipe commerciale. Aucun de ces liens n'était écrit quelque part avec la mention : si ceci tombe, voici ce qui nous arrive.

C'est pour cela que la première contre-mesure de la liste est une feuille de calcul, pas un outil. La cartographie des dépendances ne stoppe aucune attaque, mais elle transforme une nouvelle inquiétante en question à laquelle vous répondez en une heure : sommes-nous concernés, et par quoi ? La plupart des organisations touchées en avril et en mai 2026 ont passé leurs premières journées à chercher cette réponse.

Si vous relevez une erreur ou une imprécision dans cet article, signalez-la-moi : je le corrigerai.

---

Sources

• ChipSoft getroffen door cyberaanval | Skipr
• ChipSoft bevestigt: medische patiëntgegevens gestolen bij ransomware-aanval | Skipr
• Hackersgroep dreigde patiëntgegevens van ChipSoft te publiceren | NOS
• ChipSoft: alle gestolen data van ransomware-aanval vernietigd | NOS
• RDI onderzoekt maatregelen ChipSoft na ransomware-aanval | ICT&health
• Ransomware attack on ChipSoft knocks EHR services offline across hospitals in the Netherlands and Belgium | Security Affairs
• Ook bij 3 andere Vlaamse ziekenhuizen lag toegang tot patiëntengegevens open | VRT NWS
• "Shai-Hulud" Worm Compromises npm Ecosystem in Supply Chain Attack | Unit 42
• Shai-Hulud 2.0: Guidance for detecting, investigating, and defending against the supply chain attack | Microsoft Security
• Mini Shai-Hulud Strikes Again: TanStack + more npm Packages Compromised | Wiz
• Widespread Data Theft Targets Salesforce Instances via Salesloft Drift | Google Cloud
• ENISA Threat Landscape 2025
• Directive (UE) 2022/2555 (NIS2) | EUR-Lex