Attaque supply chain
Une attaque supply chain compromet un fournisseur, une dépendance ou un outil de build pour atteindre ses clients : un maillon piégé contamine tout l'aval.
Une attaque supply chain, ou attaque par la chaîne d'approvisionnement, ne vise pas directement sa cible finale : elle compromet un maillon amont, éditeur de logiciel, dépendance open source, outil de build, prestataire, dont la cible dépend. Le calcul de l'attaquant est simple, et redoutable : piéger un seul fournisseur, c'est atteindre d'un coup tous ses clients, avec le niveau de confiance qu'ils lui accordent.
Les précédents ont marqué l'industrie. SolarWinds en 2020, où une mise à jour signée et distribuée par l'éditeur lui-même embarquait une porte dérobée touchant des milliers d'organisations ; la porte dérobée découverte dans xz-utils en 2024, à quelques semaines d'atteindre les distributions Linux majeures ; et un flux continu de paquets npm ou PyPI compromis par typosquatting ou par vol de compte de mainteneur.
La défense se joue sur plusieurs plans : inventorier ses dépendances par la SCA et la SBOM, épingler les versions, vérifier la provenance des artefacts, et surveiller ses fournisseurs comme une extension de sa propre surface d'attaque. Notre page pilier sur les attaques supply chain fait le tour du sujet, et le module Supply Chain Security d'own2pwn surveille les dépendances réellement chargées par vos applications en production.
Ce que NIS2 et DORA imposent sur les fournisseurs
La directive NIS2 traite le sujet frontalement : son article 21.2 range la sécurité de la chaîne d'approvisionnement parmi les mesures que les entités doivent prendre, en visant explicitement les relations avec les fournisseurs directs et les prestataires de services. Concrètement, il faut évaluer le niveau de sécurité de ses fournisseurs, le refléter dans les contrats, et savoir lesquels touchent aux systèmes critiques. Le règlement DORA va plus loin pour le secteur financier, avec un registre obligatoire des accords portant sur des services informatiques et un socle de clauses contractuelles imposées.
L'erreur classique : confondre déclaratif et preuve
Le réflexe est d'envoyer un questionnaire de sécurité au fournisseur et de classer la réponse dans un dossier. Un questionnaire mesure surtout la capacité à remplir un questionnaire. Ce qui prouve quelque chose est d'un autre ordre : une certification auditée dont on a lu le périmètre exact, un rapport de test d'intrusion daté, et ce que l'on peut constater soi-même depuis l'extérieur, actifs exposés du prestataire, certificats, technologies obsolètes encore en ligne. Le module Supply Chain Security travaille sur ce terrain, en observant les dépendances réellement chargées par vos applications en production.
Questions fréquentes
Une PME est-elle une cible d'attaque supply chain ?
Elle est plus souvent le vecteur que la cible. Un prestataire modeste disposant d'un accès de maintenance chez un grand compte devient intéressant pour ce seul accès, ce qui explique la pression contractuelle croissante exercée par les donneurs d'ordre.
Comment limiter le risque sur les dépendances open source ?
Épingler les versions, vérifier les signatures et la provenance des artefacts, passer par un miroir interne plutôt que par le registre public, et tenir une SBOM pour savoir en une requête quels produits embarquent un composant compromis.
Que faire quand un fournisseur est compromis ?
Le traiter comme un incident interne : identifier les accès qu'il détenait, les révoquer, chercher les traces de leur utilisation dans vos journaux sur la période concernée, et notifier si des données personnelles sont en jeu. L'appartenance de l'infrastructure ne change rien à votre responsabilité.