Attaques contre la chaîne d'approvisionnement logicielle : risques et défense

Les attaques ciblant la chaîne d'approvisionnement logicielle sont devenues l'un des problèmes les plus graves pour les entreprises de toutes tailles. Protéger son propre périmètre ne suffit plus : si l'un de vos fournisseurs de logiciels, de matériel ou de services cloud tombe en panne, vous pouvez être affecté même si vous n'étiez pas la cible principale.

Le problème, c'est que ces incidents sont souvent complexes, silencieux et d'une ampleur considérable : une simple faille de sécurité chez un fournisseur largement utilisé peut compromettre simultanément des milliers d'organisations. C'est pourquoi il est essentiel de comprendre le fonctionnement de ces attaques, les exemples concrets observés et les mesures pratiques à prendre pour limiter les risques.

Qu’est-ce qu’une chaîne d’approvisionnement logicielle et pourquoi est-elle si vulnérable ?

En matière de cybersécurité, la chaîne d'approvisionnement englobe tous les fournisseurs et tiers impliqués dans la fourniture de services numériques à une entreprise : des fabricants de matériel et des développeurs de logiciels aux fournisseurs d'accès Internet, aux services cloud, aux outils de surveillance et aux plateformes de messagerie et de collaboration.

Le développement et l'exploitation des produits logiciels et matériels dépendent rarement d'un seul acteur. Il est courant que plusieurs fabricants, intégrateurs, revendeurs et fournisseurs de services gérés interviennent. Le client final ne voit presque jamais tous ces intervenants, mais sa sécurité dépend d'eux autant que de ses propres systèmes.

Les cybercriminels exploitent cette situation pour identifier le maillon faible : un fournisseur aux pratiques de sécurité laxistes, une chaîne de compilation mal sécurisée ou un composant logiciel présentant une vulnérabilité. S’ils parviennent à injecter un fragment malveillant dans cette chaîne, ils peuvent infiltrer des environnements hautement sensibles avec une relative facilité.

C’est pourquoi les attaques contre la chaîne d’approvisionnement ont explosé : une seule compromission peut donner accès à des milliers de victimes , faciliter le vol de données confidentielles, l’espionnage prolongé, voire le contrôle à distance d’infrastructures critiques.

Types d'attaques contre la chaîne d'approvisionnement logicielle

Les attaques contre la chaîne d'approvisionnement ne constituent pas un type d'incident unique, mais une famille de tactiques qui partagent le même objectif : exploiter les vulnérabilités des solutions ou des processus qui sont ensuite réutilisées dans de nombreuses organisations.

Parmi les modalités les plus courantes, on retrouve plusieurs catégories, souvent combinées dans des campagnes sophistiquées :

Logiciel compromis

Dans ce cas précis, l'attaque cible le code applicatif, les bibliothèques ou les outils de développement . L'attaquant peut modifier directement un composant, manipuler les scripts de compilation ou empoisonner les dépôts afin que, sans que le fournisseur ne s'en aperçoive, les produits distribués contiennent des fonctionnalités malveillantes.

Le vecteur privilégié est généralement la mise à jour logicielle : le cybercriminel introduit une porte dérobée dans le processus de compilation ou le serveur de distribution des correctifs, de sorte que chaque utilisateur effectuant une mise à jour installe également le logiciel malveillant. Pour lui donner une apparence légitime, des certificats volés sont souvent utilisés pour signer le code.

Matériel et micrologiciel altérés

Dans le domaine physique, les attaquants ciblent des dispositifs largement distribués , allant des équipements réseau aux postes de travail et aux composants embarqués. Leur objectif est d'introduire des modifications dans le micrologiciel, voire dans la conception matérielle, comme des logiciels espions ou des modules comportant des portes dérobées.

Ces modifications s'effectuant à des niveaux très faibles, leur détection est complexe et leur portée potentielle énorme : un appareil compromis dès sa sortie d'usine peut permettre un accès direct aux réseaux internes ou la capture persistante d'informations sensibles.

logiciels malveillants préinstallés et certificats volés

Une autre variante concerne les images système ou le matériel contenant des logiciels malveillants provenant de la source . Cela peut se produire en production, lors de processus de personnalisation pour un client spécifique ou lors de la préparation d'images de machines virtuelles ou de conteneurs.

Les certificats numériques volés aux fabricants ou aux développeurs sont également très dangereux . Grâce à eux, les attaquants peuvent signer des fichiers binaires modifiés pour leur donner une apparence légitime, contourner les contrôles d'intégrité et réduire considérablement les risques de détection lors des mises à jour ou des installations.

Risques spécifiques liés aux logiciels libres et aux « secrets »

L'utilisation intensive des logiciels libres (OSS) accélère et dynamise le développement, mais elle multiplie aussi la surface d'attaque. De nombreux projets reposent sur la maintenance bénévole de développeurs qui n'ont pas toujours les ressources nécessaires pour examiner chaque contribution ou réagir rapidement aux nouvelles failles de sécurité.

En revanche, les « secrets » mal gérés — clés API, jetons, mots de passe ou certificats intégrés par inadvertance dans le code source — prolifèrent dans les dépôts de code . Les groupes de ransomware et autres acteurs sophistiqués analysent massivement ces dépôts à la recherche d'identifiants exposés qui leur permettraient d'accéder à d'autres systèmes.

Attaques réelles contre la chaîne d'approvisionnement : les cas les plus pertinents

Ces dernières années ont été marquées par de nombreux exemples d' attaques contre la chaîne d'approvisionnement ayant des répercussions mondiales , dont beaucoup sont liées à de grands fournisseurs de logiciels ou de services. Voici quelques-uns des cas les plus révélateurs.

SolarWinds et la campagne Solorigate

L'un des incidents les plus médiatisés s'est produit fin 2020, lorsque des attaquants très sophistiqués ont réussi à compromettre l'environnement de développement de SolarWinds , un fournisseur de logiciels de surveillance réseau utilisés par des entreprises et des organismes publics du monde entier.

Les attaquants ont injecté un composant malveillant dans les mises à jour d'Orion, leur plateforme de gestion d'infrastructures. Chaque client ayant installé la mise à jour a reçu, à son insu, un cheval de Troie permettant un accès distant clandestin . On estime que plus de 18 000 organisations pourraient avoir été touchées, parmi lesquelles de grandes entreprises technologiques, des agences gouvernementales et des entités gérant des infrastructures critiques.

Kaseya et le ransomware massif

Un autre exemple frappant est l'attaque contre Kaseya , fournisseur de logiciels de gestion à distance (RMM) pour les fournisseurs de services gérés (MSP). Le groupe de ransomware REvil a exploité une vulnérabilité zero-day du produit VSA, déployant un code malveillant chez les clients MSP utilisant la plateforme.

En quelques heures, entre 800 et 1 500 entreprises ont été touchées par le chiffrement de leurs systèmes. Les attaquants ont exigé une rançon de plusieurs millions de dollars (70 millions de dollars) en échange de la clé de déchiffrement principale, démontrant ainsi l’énorme pouvoir de nuisance que représentent ces types d’attaques contre les fournisseurs.

Mimecast, Codecov, Atlassian et autres incidents

Dans le cas de Mimecast , l'incident était lié à un certificat numérique compromis que certains clients utilisaient pour connecter de manière sécurisée leurs services Microsoft 365 Exchange. En contrôlant ce certificat, les attaquants ont pu intercepter et manipuler les communications.

L'attaque contre Codecov , une société d'analyse de couverture de code, reposait sur la modification d'un script de chargement Bash. Cette modification a permis aux cybercriminels de rediriger des informations sensibles (telles que le code source et des secrets) des environnements clients de Codecov vers des serveurs qu'ils contrôlaient.

En 2020, Check Point Research a découvert une série de vulnérabilités chez Atlassian qui, combinées, permettaient à des attaquants de prendre le contrôle des comptes et des applications liés par authentification unique (SSO). Bien que la divulgation ait été responsable et la vulnérabilité corrigée rapidement, cet incident a illustré comment une faille chez un fournisseur clé peut devenir un vecteur d'attaque majeur au sein de la chaîne d'approvisionnement.

NotPetya et l'affaire British Airways

Le logiciel malveillant NotPetya s'est initialement présenté comme un pseudo-rançongiciel diffusé via une mise à jour malveillante d'un logiciel de comptabilité utilisé en Ukraine. En réalité, il ne stockait aucune clé de déchiffrement et agissait comme un « effaceur » de données, détruisant irrémédiablement les données et se propageant rapidement, avec de graves conséquences économiques.

Dans le secteur du commerce électronique, British Airways a été victime en 2018 d'une attaque du groupe Magecart , qui a injecté un code malveillant dans les systèmes de l'un de ses fournisseurs. Ce code a affecté son site web et son application, interceptant les données de paiement de plus de 380 000 transactions clients.

La tentative de porte dérobée dans Linux XZ

En 2024, une tentative sophistiquée d' injection d'une porte dérobée dans XZ Utils , un outil de compression largement utilisé sous Linux, a été découverte. L'attaque, développée sur plusieurs années, avait bénéficié de la confiance de la communauté open source avant d'introduire progressivement des modifications malveillantes dans le code.

Cette fonctionnalité cachée permettait l'exécution de code à distance pour les attaquants possédant une clé spécifique. Bien que la version compromise n'ait pas été largement déployée en production, elle était présente dans les versions de développement, et les experts ont averti que, si elle était passée inaperçue, des millions de systèmes Linux auraient été exposés.

Comment fonctionnent ces attaques et pourquoi elles sont si dangereuses

Les attaques ciblant la chaîne d'approvisionnement exploitent les relations de confiance implicites entre les organisations. Lorsque vous installez le logiciel d'un fournisseur, intégrez une bibliothèque tierce ou connectez votre messagerie à un service externe, vous partez du principe que cette entreprise assure une sécurité adéquate.

Les cybercriminels ciblent les fournisseurs les plus vulnérables, sachant que s'ils parviennent à les compromettre, ils pourront ensuite s'attaquer à des clients mieux protégés en exploitant leur confiance. Les fournisseurs de services gérés (MSP) constituent des cibles particulièrement attrayantes, car ils disposent d'un accès étendu aux réseaux de nombreux clients.

Dans des scénarios comme celui de SolarWinds, l'attaque est orchestrée en obtenant l'accès aux serveurs de compilation ou de mise à jour . Une porte dérobée est alors injectée dans le code qui sera distribué à des milliers d'organisations. Dans d'autres cas, le vecteur d'attaque se situe au niveau des scripts, des chaînes CI/CD, des dépôts compromis ou des dépendances open source manipulées.

Le danger de ces attaques réside dans le fait qu'elles ne visent pas à franchir le mur le plus haut, mais plutôt à forcer la porte latérale la moins bien gardée . Même avec un programme de sécurité robuste, si vous ne maîtrisez pas les risques liés aux tiers, vous restez vulnérable.

Impacts et tendances des attaques contre la chaîne d'approvisionnement

Des données récentes font état d'une croissance explosive : entre 2021 et 2023, les attaques de ce type ont augmenté de plus de 400 % , et des études ultérieures indiquent que les chaînes d'approvisionnement en matériel et en logiciels ont enregistré l'une des plus fortes augmentations d'incidents en 2024.

Les secteurs les plus durement touchés sont la technologie, les services financiers, les cabinets d'avocats, les cabinets de conseil et les marques de luxe , qui possèdent tous des écosystèmes de fournisseurs solides et une grande valeur pour les informations qu'ils traitent.

Les motivations vont du gain financier (rançongiciels, vol de données à des fins commerciales) à l'espionnage et à la perturbation des services critiques . La demande mondiale de matériel informatique et l'essor de l'IA ont fait de cette chaîne technologique une cible de choix pour les groupes de cybercriminels.

De plus, de nombreux incidents ne sont même pas classés comme attaques de la chaîne d'approvisionnement, car les enquêtes menées en réponse aux incidents privilégient la restauration des opérations de la victime directe plutôt que la recherche de la source exacte de l'intrusion. Il en résulte une sous-estimation du problème dans les statistiques officielles.

Meilleures pratiques clés contre les attaques de la chaîne d'approvisionnement

Pour atténuer ces risques, il est nécessaire de combiner la gestion par des tiers, les contrôles techniques et les changements culturels au sein des services informatiques et de développement. Il ne s'agit pas d'un outil unique, mais d'une approche continue et structurée.

1. Inventaire et contrôle des actifs et du Shadow IT

La première étape consiste à identifier vos ressources et vos fournisseurs. Tenir à jour un inventaire précis de vos logiciels , services et fournisseurs est essentiel pour bien comprendre votre niveau d'exposition. Cela inclut les applications SaaS, les outils de productivité, les solutions de sécurité et les composants de développement.

Il est crucial de détecter et de réduire l'informatique parallèle : applications, services ou intégrations que les employés adoptent de leur propre initiative, sans passer par les procédures officielles. Chaque outil non autorisé constitue un nouveau maillon de la chaîne d'approvisionnement qui risque d'échapper à tout contrôle.

2. Évaluer et classer le risque des fournisseurs

Tous les prestataires tiers ne présentent pas le même niveau de risque. Il est conseillé de mettre en place une procédure formelle d' évaluation de la sécurité de chaque fournisseur , en examinant notamment ses certifications, ses politiques de développement sécurisé, sa gestion des vulnérabilités et son recours au chiffrement.

Ensuite, il est possible de les regrouper selon leur impact potentiel sur votre activité (accès aux données sensibles, criticité du service, position dans votre architecture). Les fournisseurs à haut risque doivent faire l'objet de contrôles et d'une surveillance renforcés , incluant des évaluations régulières et des exigences contractuelles claires.

3. Validation continue des risques et « cyber-altruisme »

La gestion par un tiers ne peut se limiter à un examen ponctuel en début de relation. Elle doit être envisagée comme un processus de surveillance continue , impliquant un examen régulier des incidents publics, des modifications de l'infrastructure du fournisseur et de l'apparition de nouvelles vulnérabilités.

Certaines grandes organisations adoptent une stratégie de « cyberaltruisme » , partageant leurs outils de sécurité, leurs formations et leurs compétences avec des fournisseurs plus petits. Le principe est simple : l’ensemble de l’écosystème est exposé aux mêmes risques, et la sécurité d’un système dépend de son maillon le plus faible.

4. Principe du moindre privilège et segmentation du réseau

La réduction des autorisations est l'une des défenses les plus efficaces. Appliquer le principe du moindre privilège signifie n'accorder aux employés, aux applications et aux partenaires externes que l'accès strictement nécessaire à leur fonction.

Cette approche est complétée par la segmentation du réseau : la division de l’infrastructure en zones logiques dotées de contrôles d’accès bien définis. Ainsi, si un fournisseur ou un logiciel tiers est compromis, il sera plus difficile pour l’attaquant de se déplacer latéralement et d’étendre les dommages à d’autres systèmes.

5. DevSecOps et sécurité du cycle de vie des logiciels

L'intégration de la sécurité au cycle de vie du développement (DevSecOps) est essentielle pour détecter les altérations de code, les erreurs de compilation et les pipelines CI/CD avant leur mise en production. Cela inclut l'analyse statique (SAST), les vérifications de dépendances (SCA), les analyses de conteneurs et la vérification de l'intégrité des artefacts.

L'adoption de normes telles que SLSA (Supply-chain Levels for Software Artifacts) contribue à renforcer le processus de compilation , garantissant que seules les versions signées, reproductibles et vérifiées peuvent être distribuées aux clients internes ou externes.

6. Détection et réponse avancées des points de terminaison

Au niveau des postes de travail et des serveurs, il est important de disposer d'outils de détection et de réponse aux points de terminaison (EDR/XDR) capables d'identifier les comportements anormaux liés aux attaques de la chaîne d'approvisionnement : charges utiles de code inhabituelles, communications sortantes suspectes ou exécution de binaires signés mais malveillants.

Les solutions modernes intègrent l'automatisation pour bloquer les menaces en temps réel , isoler les équipes compromises et aider les analystes du centre des opérations de sécurité (SOC) à enquêter sur les incidents qui traversent plusieurs vecteurs (réseau, cloud, email, mobile).

7. Outils côté client et contrôles du navigateur

Dans des scénarios tels que les attaques Magecart, le problème se manifeste au niveau du navigateur de l'utilisateur final. Dans ces cas, les outils de protection côté client deviennent essentiels , car ils surveillent le code exécuté sur la page, détectent les injections et vérifient l'intégrité des scripts et des iframes.

Ces contrôles permettent d'identifier les tentatives de vol de données dans les formulaires de paiement ou de connexion, même lorsque la source est un fournisseur de contenu externe ou une intégration tierce compromise.

8. Politiques strictes en matière d'intégrité du code et d'applications autorisées

Un autre niveau de défense consiste à utiliser des listes blanches et des politiques d'intégrité du code qui n'autorisent que l'exécution de fichiers binaires signés et vérifiés. Cela réduit les risques que des composants introduits frauduleusement s'exécutent sans contrôle.

Combiné à la validation de signature, à la vérification du hachage et à l'examen des certificats, cela garantit que seuls les logiciels autorisés peuvent s'exécuter sur les systèmes , minimisant ainsi l'impact des compromissions potentielles dans la chaîne de mise à jour.

9. Infrastructures de compilation et de mise à jour sécurisées

Les serveurs et les pipelines de compilation et de mise à jour doivent être considérés comme des actifs stratégiques de grande valeur . Il est essentiel de renforcer leur sécurité par des contrôles d'accès stricts, une séparation des tâches, une surveillance continue et une authentification robuste.

De plus, il est conseillé de mettre en œuvre des signatures cryptographiques sans clé exposée (par exemple, via du matériel sécurisé ou des services de signature centralisés), afin qu'un attaquant qui compromet un serveur de compilation ne puisse pas signer librement des artefacts sans laisser de trace.

10. Processus de réponse aux incidents adaptés à la chaîne d'approvisionnement

Tout plan moderne de réponse aux incidents doit prendre en compte les scénarios de violation de données chez les fournisseurs ou les composants tiers . Cela inclut la définition des procédures d'isolement des systèmes affectés, de communication avec les fournisseurs concernés, de révocation des certificats et de déploiement des correctifs d'urgence.

Il est également utile de s'entraîner à des exercices de simulation spécifiques aux attaques contre la chaîne d'approvisionnement , car le contexte, le moment et la coordination avec les tiers diffèrent souvent d'un incident purement interne.

Plateformes et technologies contribuant à protéger la chaîne d'approvisionnement

Ces dernières années, des solutions spécialisées ont vu le jour, visant à assurer une couverture complète du cycle de vie des applications contre ces types d'attaques, réduisant ainsi la nécessité de gérer plusieurs outils non connectés.

Protection du code source et des secrets commerciaux

Les plateformes AppSec modernes intègrent l'analyse en temps réel des dépôts, avec des fonctionnalités permettant de détecter les vulnérabilités du code (SAST) et les secrets exposés (clés, jetons, identifiants). Elles peuvent bloquer les commits contenant du code dangereux grâce aux garde-fous CI/CD, empêchant ainsi les erreurs ou les injections malveillantes de quitter le dépôt.

De plus, nombre d'entre eux intègrent des fonctionnalités permettant de valider et de révoquer automatiquement les secrets divulgués , en s'intégrant aux gestionnaires d'identifiants et aux systèmes d'identité, réduisant ainsi la durée pendant laquelle un identifiant exposé reste utile à un attaquant.

Sécurité de la phase de compilation, de l'empaquetage et des dépendances

Durant la phase de compilation, ces plateformes appliquent des contrôles de conformité basés sur des frameworks tels que SLSA, vérifiant l'intégrité des artefacts et surveillant les tâches CI/CD afin de détecter tout comportement anormal . En cas de suspicion, elles signalent et bloquent les compilations avant leur mise en production.

Lors de la phase de packaging, la détection de logiciels malveillants et l'analyse des licences sont appliquées à chaque élément, garantissant ainsi la conformité des bibliothèques utilisées aux exigences légales et de sécurité. Parallèlement, l'analyse de la composition logicielle (ACL) ne se limite pas au simple recensement des CVE ; elle évalue également si les vulnérabilités sont réellement exploitables dans ce contexte.

De nombreux fabricants intègrent des moteurs de correction qui proposent des chemins de mise à niveau sûrs et des correctifs spécifiques , en privilégiant les versions qui réduisent les risques sans introduire de régressions connues. Cela accélère la résolution des problèmes sans ralentir le développement.

Visibilité unifiée et réponse intelligente

L'un des principaux avantages de ces solutions est qu'elles offrent une vision unifiée des risques tout au long du cycle de vie du développement logiciel , du code à la production. Au lieu de gérer plusieurs outils isolés, les équipes de développement et de sécurité accèdent à une source unique de données consolidées.

Certains moteurs avancés génèrent automatiquement des correctifs, des demandes de fusion ou des guides pas à pas pour résoudre chaque problème, en les priorisant selon leur impact et leur facilité d'exploitation. Cela allège la charge de travail des équipes et leur permet de réagir plus rapidement aux nouvelles vulnérabilités et menaces.

Réduire l'impact d'une rupture de la chaîne d'approvisionnement

Même avec toutes les mesures préventives en place, il est nécessaire de partir du principe qu'un fournisseur ou un composant tiers pourrait être compromis à un moment donné. Par conséquent, il est essentiel de concevoir l'architecture de manière à minimiser l'impact d'une telle faille.

Les modèles Zero Trust reposent sur le principe du moindre privilège et une vérification d'identité continue des utilisateurs et des applications. Ainsi, même si un système est compromis, il sera très difficile pour un attaquant de se propager latéralement à d'autres ressources plus critiques.

Les techniques d'accès réseau Zero Trust (ZTNA), combinées à la segmentation, au sandboxing du nouveau code et à l'analyse comportementale, contribuent à empêcher qu'une simple violation ne se transforme en un incident catastrophique affectant l'ensemble de l'organisation.

En outre, il est conseillé de disposer de plans de continuité et de reprise clairs, ainsi que d'accords avec les principaux fournisseurs précisant comment les notifications, les correctifs et la collaboration seront gérés en cas d'incidents affectant la chaîne d'approvisionnement.

Les attaques ciblant la chaîne d'approvisionnement logicielle, autrefois considérées comme une curiosité technique, sont devenues une menace majeure pour toute entreprise connectée. L'expansion constante des écosystèmes numériques, le recours massif à l'open source, la dépendance aux tiers et les outils d'IA ont créé un terreau fertile pour leur développement. Seule une vision globale de vos fournisseurs, des contrôles de privilèges minimaux, des pratiques DevSecOps robustes et des plateformes de sécurité capables de surveiller l'intégralité du cycle de vie de vos applications vous permettront de réduire efficacement la surface d'attaque et de contrer les adversaires qui, plus que jamais, cherchent à s'infiltrer via vos partenaires plutôt que de s'attaquer directement à votre système.