Attaque de la chaîne d’approvisionnement : définition et défense

Les attaques sur la chaîne d’approvisionnement exploitent la relation de confiance avec les fournisseurs, les composants logiciels, les environnements de build ou les prestataires disposant d’un accès. Une source compromise atteint simultanément de nombreux destinataires et fait de la sécurité de la chaîne logistique une obligation de preuve au regard de la directive NIS2 ainsi que du règlement sur la résilience cyber (Cyber Resilience Act).

À consulter également : Qu’est-ce qu’une SBOM ? La nomenclature logicielle  ·  Qu’est-ce que la NIS2 ? Définition, obligations et responsabilité

Ce qui caractérise une attaque par la chaîne d’approvisionnement

Dans une attaque par la chaîne d’approvisionnement, c’est la relation entre la cible et son fournisseur qui est au cœur de la menace. La victime examine souvent avec soin le chemin d’attaque direct. Pourtant, elle ouvre simultanément des canaux pour les mises à jour, les bibliothèques, les accès de maintenance et les builds automatisés. Ce sont précisément ces canaux qui bénéficient déjà d’une relation de confiance. L’attaquant recherche donc un point où cette confiance est déjà établie, puis y place du code malveillant, des artefacts manipulés ou des identités détournées.

L’impact se mesure à l’échelle. Une dépendance publique compromise, une mise à jour signée du fabricant ou un résultat de build empoisonné peut toucher simultanément de nombreuses organisations. Chaque utilisateur final intègre ainsi le risque sous l’étiquette d’une source habituelle. Les protections de périmètre et les solutions de sécurité des terminaux interviennent trop tard, voire pas du tout, si le contenu malveillant arrive via le canal d’approvisionnement attendu.

La confiance constitue ici la véritable surface d’attaque. Les signatures, les noms de dépôts, les pipelines CI et les comptes partenaires sont considérés comme des preuves d’origine et d’intégrité. Qui contrôle ou imite ces preuves contourne la méfiance qu’un inconnu susciterait normalement. Les exemples connus vont du ver npm Mini Shai-Hulud (Mini Shai-Hulud : un ver npm dévore la chaîne d’approvisionnement) à un chargeur de botnet publié via une pipeline CI (CI/CD : publication d’un chargeur de botnet AsyncAPI), en passant par un paquet npm conçu pour voler des clés privées (Un paquet npm qui vole les clés privées). Cet article définit le concept et la chaîne logicielle d’approvisionnement. La dimension physique des fournisseurs critiques d’équipements industriels relève d’un contexte stratégique distinct et n’est pas abordée ici.

Les quatre vecteurs d’attaque dans la chaîne d’approvisionnement

Paquet en amont compromis. Une dépendance publique dans un gestionnaire de paquets est reprise ou modifiée avec du code malveillant, puis distribuée via les canaux d’installation habituels. Les développeurs et les systèmes de build intègrent la composante, car le nom, la version et le registre semblent fiables. La propagation emprunte la même infrastructure que les mises à jour légitimes. L’attaque est souvent lancée bien avant la cible finale et exploite l’automatisation des projets logiciels modernes.

Mise à jour substituée. Le canal de livraison d’un éditeur légitime est détourné. La mise à jour porte une signature valide et apparaît dans la source de mise à jour habituelle. Les clients et serveurs acceptent le fichier, car la vérification cryptographique et le canal de l’éditeur correspondent. La charge malveillante voyage sous les traits d’une version autorisée et atteint des systèmes qui refuseraient les téléchargements manuels ou les sources inconnues.

Serveur de build compromis. Le code source dans le dépôt peut rester intact. Ce n’est pas le cas de l’artefact généré. Qui contrôle la chaîne CI influence les compilateurs, les dépendances et les étapes de signature. Chaque résultat de build ultérieur peut être manipulé, sans que les revues de code dans le dépôt ne détectent la manipulation. L’attaque cible la transition entre le code source et le produit livrable.

Accès via un prestataire. La télémaintenance, les services gérés et les accès administratifs des partenaires ouvrent des identités plutôt que des chemins de code. L’attaquant compromet le prestataire ou ses identifiants et se déplace avec des droits autorisés dans le réseau du client. C’est ici que naît le caractère de chaîne d’approvisionnement, issu de la relation contractuelle et de confiance. Le chemin est à la fois organisationnel et technique, exigeant une gestion stricte des privilèges, une surveillance des sessions et une délimitation claire des accès partenaires.

Ce que le NIS2 et le Règlement sur la cybersécurité exigent

La sécurité des chaînes d’approvisionnement est expressément ancrée dans la réglementation européenne et allemande. La directive NIS2 intègre les risques de sécurité dans la chaîne d’approvisionnement comme partie intégrante des mesures de gestion des risques. L’article 21 de la directive NIS2 est déterminant. En Allemagne, c’est le paragraphe 30 du BSIG qui s’applique. Les entités concernées doivent traiter et documenter ces risques. L’obligation ne se limite pas au périmètre propre. Elle s’étend aux dépendances pertinentes pour le fonctionnement et la sécurité des services proposés.

Le Règlement sur la cybersécurité (UE) 2024/2847 complète le cadre applicable aux produits dotés d’éléments numériques. À compter du 11 septembre 2026, l’obligation de signalement s’appliquera aux failles activement exploitées et aux incidents de sécurité graves. Le premier signalement doit intervenir dans un délai de 24 heures. Le rapport complet doit être transmis sous 72 heures. Cette obligation concerne les acteurs de la chaîne d’approvisionnement, y compris les importateurs et les distributeurs. À partir du 11 décembre 2027, les obligations complètes des fabricants entreront en vigueur, incluant le marquage CE, l’évaluation de conformité et la SBOM.

Pour le lecteur, cela implique une conséquence pratique claire. La sécurité des chaînes d’approvisionnement est devenue un objet contractuel et une obligation de preuve. Les questions d’audit, les évaluations des fournisseurs et les listes techniques de composants font désormais partie du quotidien des organisations concernées. La SBOM sert d’outil pour rendre les dépendances visibles et vérifiables (Qu’est-ce qu’une SBOM ? La liste de pièces pour les logiciels). Les bonnes pratiques ne suffisent plus là où les autorités de surveillance et la responsabilité juridique exigent des preuves tangibles.

Différenciation avec des notions apparentées

Une attaque par la chaîne d’approvisionnement n’est pas une attaque directe contre le système cible. L’attaquant ne contourne pas les défenses de la victime en exploitant une faille directe au niveau du périmètre. Il utilise une source déjà acceptée. De même, le phishing ciblant les collaborateurs relève d’une autre catégorie, même si l’intrusion ultérieure mène vers les systèmes. Un attaquant interne agit depuis l’intérieur de l’organisation. Dans le cas d’une attaque par la chaîne d’approvisionnement, l’origine se situe en dehors, au niveau de la chaîne des fournisseurs et des intégrations.

Il convient également de distinguer le risque lié à la chaîne d’approvisionnement au sens de la gestion opérationnelle. Dans ce cas, il s’agit de la disponibilité, des ruptures d’approvisionnement et des dépendances opérationnelles envers les fournisseurs. L’attaque par la chaîne d’approvisionnement désigne quant à elle la compromission intentionnelle de chemins numériques ou basés sur la confiance. Ces deux sujets touchent les services achats et la gestion des fournisseurs. Les objectifs de sécurité et les contrôles techniques diffèrent.

Le Risk Management des tiers (Third-Party Risk Management) est proche sur le plan conceptuel. Celui-ci évalue, surveille et lie contractuellement les partenaires, les services cloud et les éditeurs de logiciels. La SBOM (Software Bill of Materials) complète cette approche en offrant une visibilité lisible par machine sur les composants et les versions. Ensemble, la gestion des risques, les preuves et la transparence technique forment la réponse à une classe d’attaques qui exploite systématiquement la confiance.

Foire aux questions

Chaque question est verrouillée. Un clic déverrouille la réponse.

Comment reconnaître une attaque par la chaîne d’approvisionnement ?

Le code malveillant ou l’abus provient généralement d’une source en apparence fiable : un gestionnaire de paquets, une mise à jour du fabricant, un artefact CI ou un accès partenaire. Les comportements inattendus après des mises à jour de routine, des événements inhabituels dans le registre (registry) ou dans le processus de build, ainsi que des activités sous des comptes de prestataires, sont des signes révélateurs. L’origine semble légitime, mais le contenu ou l’utilisation ne l’est pas.

Cet incident diffère-t-il d’une attaque par zero-day ciblant vos propres logiciels ?

Oui. Une faille zero-day exploite une vulnérabilité inconnue dans le produit cible lui-même. Dans le cas d’une attaque par la chaîne d’approvisionnement, la compromission intervient au niveau de la livraison ou du processus de fabrication. La cible reçoit quelque chose de familier. La vulnérabilité peut ne pas se situer dans son propre code. Cette séparation facilite l’analyse des causes et l’attribution des responsabilités le long de la chaîne.

Quel rôle joue la SBOM dans la défense ?

Une SBOM (Software Bill of Materials) recense les composants et leurs versions, rendant ainsi les dépendances traçables. Les organisations peuvent identifier et prioriser plus rapidement les paquets concernés lorsqu’une composante en amont est compromise. Le Cyber Resilience Act impose la SBOM dès l’entrée en vigueur des obligations complètes pour les fabricants. Elle ne remplace ni la vérification des signatures ni le contrôle d’accès, mais fournit le socle nécessaire à une réponse ciblée.

Que demandent concrètement la directive NIS2 et le BSIG concernant la chaîne d’approvisionnement ?

L’article 21 de la directive NIS2 et le paragraphe 30 de la loi allemande sur la sécurité des infrastructures critiques (BSIG) obligent les entités concernées à intégrer la gestion des risques liés à la chaîne d’approvisionnement dans leur processus de gestion des risques, ainsi qu’à les documenter. Cela inclut l’évaluation des dépendances, la mise en place de mesures adaptées et l’existence de processus vérifiables. La mise en œuvre exacte dépend du rôle et du niveau de criticité de l’entité. Le message clé reste le même : les risques liés aux chaînes d’approvisionnement doivent s’inscrire dans un processus de sécurité réglementé.

Quelles sont les premières vérifications à effectuer pour les organisations ?

Les canaux prioritaires sont ceux qui offrent le plus haut niveau de confiance et la plus grande portée : les mises à jour automatiques, les dépôts de paquets, les processus CI (intégration continue) et de signature, ainsi que les accès partenaires privilégiés. Les contrats et justificatifs doivent être alignés sur ces canaux. Une transparence totale sur les dépendances et des responsabilités clairement définies entre les services achats, développement et sécurité permettent de réduire significativement la surface d’attaque.

Les choix de la rédaction

À lireMini Shai-Hulud : le ver npm dévore la chaîne d’approvisionnementÀ lireLe plus faible des fournisseurs ouvre l’installation critiqueÀ lire622 CVE : prioriser plutôt que paniquer et corriger

Plus du réseau MBF Media

cloudmagazinFaille NGINX : Ingress et Gateway sous contrainte de correctifDigital ChiefsAccès orphelins : la faille cyber silencieuse