Cyberattaque par la chaîne d'approvisionnement : comprendre et s'en protéger

Qu'est-ce qu'une cyberattaque par la chaîne d'approvisionnement ?

Une cyberattaque par la chaîne d'approvisionnement (supply chain attack) ne cible pas directement votre système d'information. Elle passe par un intermédiaire : un éditeur logiciel dont vous utilisez la solution, un prestataire d'infogérance qui a accès à votre réseau, un sous-traitant qui héberge vos données, ou un simple fournisseur de composants qui alimente votre production. L'attaquant compromet ce maillon, puis utilise la confiance et les accès qu'il détient pour atteindre sa cible réelle — vous, ou l'ensemble des clients de ce fournisseur en même temps.

Ce mode opératoire n'est pas nouveau, mais il est devenu la voie d'attaque privilégiée des groupes offensifs les plus sophistiqués comme des cybercriminels opportunistes. La raison est simple : à mesure que les grandes organisations renforcent leur périmètre direct (EDR, MFA, segmentation réseau), l'effort d'intrusion se déplace naturellement vers les maillons les moins matures de leur écosystème — souvent des PME ou ETI fournisseurs, moins outillées, moins staffées côté sécurité, mais disposant d'accès légitimes à des dizaines de clients. Un seul fournisseur compromis peut ainsi devenir le point de bascule vers un nombre de victimes sans commune mesure avec une attaque directe.

Les vecteurs concrets sont multiples : un éditeur logiciel dont une mise à jour est piégée et distribuée automatiquement à tous ses clients, un prestataire d'infogérance dont les identifiants d'accès distant sont volés et réutilisés pour rebondir chez ses clients, un sous-traitant hébergeant des données sensibles qui subit une exfiltration, ou encore un fournisseur de composants IT dont le matériel est altéré avant livraison. Dans tous les cas, la victime finale n'a commis aucune erreur directe — elle a simplement fait confiance à un tiers dont elle ne maîtrisait pas la posture de sécurité.

Pourquoi ce risque reste-t-il un angle mort ?

La difficulté n'est pas de comprendre le risque intellectuellement — la plupart des RSSI et Risk Managers le connaissent bien. La difficulté est opérationnelle : comment surveiller en continu un écosystème de dizaines, voire de centaines de fournisseurs, sans disposer d'une équipe dédiée à plein temps ?

Dans la réalité de la plupart des organisations, la gestion du risque fournisseur repose encore sur des fichiers Excel dispersés, des questionnaires envoyés une fois par an sans réelle capacité de relance ni de suivi, et une vision en silo — les équipes achats connaissent les contrats, les équipes IT connaissent les accès techniques, les équipes sécurité connaissent les vulnérabilités, mais personne ne dispose d'une vue consolidée reliant ces trois dimensions à un instant donné.

Cette fragmentation a un coût direct au moment où un incident survient. Quand un fournisseur annonce publiquement une compromission, les questions qui remontent immédiatement au comité de direction sont simples mais souvent impossibles à répondre en quelques heures : sommes-nous concernés ? Quelles activités métier dépendent de ce fournisseur ? Quelles données lui avons-nous confiées ? A-t-il accès à notre réseau ? Sans registre centralisé reliant fournisseurs, activités et niveau de criticité, la réponse prend des jours — le temps où l'attaquant, lui, a déjà pivoté.

Le second angle mort est la concentration invisible. Beaucoup d'organisations découvrent, souvent après coup, que plusieurs activités critiques reposent sur le même fournisseur, ou que ce fournisseur dépend lui-même d'un sous-traitant commun à d'autres maillons de leur chaîne. Cette absence de cartographie de dépendances transforme un incident localisé chez un tiers en un point unique de défaillance (SPOF) pour l'ensemble de l'organisation.

Comment structurer la défense dans la durée ?

Les référentiels de gestion des risques établis — EBIOS Risk Manager (ANSSI) et ISO 27005 en tête — convergent sur un même principe : le risque fournisseur doit être traité comme une extension du système d'information de l'organisation, pas comme un sujet contractuel isolé. Cela implique un cycle continu, pas un contrôle ponctuel.

1. Identifier et cartographier. Avant d'évaluer quoi que ce soit, il faut savoir qui sont vos fournisseurs, quelles activités métier ils supportent, et quel niveau d'accès ou de dépendance existe réellement. Un registre unifié — et non une addition de tableurs — est le prérequis de toute démarche sérieuse.

2. Qualifier la criticité. Tous les fournisseurs ne présentent pas le même niveau de risque. Un prestataire ayant accès à votre réseau de production ou hébergeant des données sensibles ne peut pas être traité avec la même rigueur qu'un fournisseur de fournitures de bureau. La criticité doit être documentée et justifiée, pas estimée à l'instinct.

3. Évaluer en continu, pas une fois par an. La posture de sécurité d'un fournisseur change en permanence : nouvelles vulnérabilités publiées, changements d'infrastructure, nouveaux sous-traitants intégrés à son propre écosystème. Une évaluation annuelle donne une photo, pas un film. La bonne pratique est une combinaison d'évaluations périodiques (questionnaires, audits) et de signaux continus (surveillance de la surface d'attaque externe, alertes de compromission).

4. Se préparer à la propagation. Même avec la meilleure due diligence, un fournisseur peut être compromis. La question n'est donc pas seulement « comment l'éviter » mais « comment détecter et contenir rapidement quand cela arrive chez un tiers ». Cela suppose un registre d'incidents capable d'enregistrer un événement survenu chez un fournisseur, de le relier aux activités impactées, et de déclencher les bonnes actions (réévaluation, dérogation encadrée, mesure de traitement).

5. Documenter pour prouver. En cas d'incident majeur, la capacité à démontrer — à un régulateur, un assureur ou un client — que la chaîne fournisseur était surveillée et évaluée de manière structurée fait une différence considérable sur les conséquences réputationnelles et réglementaires. C'est également une exigence explicite de textes comme NIS2, qui impose aux entités concernées de gérer la sécurité de leur chaîne d'approvisionnement.

Comment CISAPP réduit-il concrètement ce risque ?

CISAPP a été conçu pour transformer cette théorie en pratique quotidienne, sans imposer une équipe dédiée à plein temps.

Un registre unique pour cartographier l'écosystème réel. Plutôt que de disperser l'information entre outils achats, IT et sécurité, CISAPP centralise fournisseurs, activités métier et leurs dépendances dans un registre unique, filtrable et exportable. Chaque fournisseur est relié aux activités qu'il supporte, avec une criticité documentée dès l'onboarding via un wizard guidé en six étapes (recherche, informations, criticité, contacts, droits).

Une cartographie des dépendances pour révéler les concentrations invisibles. Le module de cartographie et d'exposition (/exposition/dependency-map) construit une matrice activités × fournisseurs, avec des filtres dédiés aux points uniques de défaillance et aux concentrations excessives sur un même tiers. La vue « concentration » répond directement à la question : quels fournisseurs, s'ils tombaient, feraient tomber le plus d'activités critiques en même temps ?

Des évaluations et campagnes pour sortir du contrôle ponctuel. La bibliothèque de questionnaires préconfigurés (ISO 27001, NIS2, DORA…), les campagnes d'évaluation groupées avec suivi de complétion, et le score SecOps calculé en continu (DNS, TLS, exposition, breach, en-têtes de sécurité) donnent une vue de posture qui ne repose pas sur un audit annuel isolé, mais sur un flux d'information régulier.

Un registre d'incidents qui capture la propagation cross-organisation. Quand un incident survient chez un fournisseur, CISAPP permet de le déclarer, de suivre son impact via des KPIs (time-to-detect, time-to-contain, time-to-close), et de le relier directement aux risques et dérogations concernés. La fonctionnalité d'incidents reçus permet même de recevoir la notification d'un incident déclaré par un tiers ayant lui-même subi une compromission — la propagation devient traçable au lieu de rester informelle.

Un registre des risques qui transforme les écarts en actions suivies. Chaque vulnérabilité identifiée chez un fournisseur peut être convertie en risque documenté (wizard inspiré d'EBIOS RM), avec mesures de traitement, propriétaire et échéance, jusqu'à sa clôture — puis suivie dans le temps via un cycle de réévaluation.

La chaîne d'approvisionnement restera toujours un vecteur d'attaque — aucun outil ne l'élimine. Mais la différence entre une organisation exposée et une organisation résiliente se joue sur un point précis : la vitesse à laquelle elle sait qui est concerné, ce qui est impacté, et quelle action engager. C'est exactement ce que CISAPP structure au quotidien.