Les dépendances techniques qui fragilisent la sécurité globale

Les dépendances techniques envers prestataires, logiciels tiers et services cloud sont des vecteurs d'exposition dont la gestion rigoureuse — cartographie, SBOM, TPRM — conditionne la sécurité globale des systèmes d'information.

M
Mehdi SARIAK
24 mai 2026 7 min de lecture 25 lectures

Points clés

  • Les dépendances techniques — envers des prestataires, des logiciels tiers, des services cloud — sont des vecteurs d'exposition souvent sous-évalués
  • SolarWinds (2020) : la chaîne de distribution logicielle d'un fournisseur de confiance comme vecteur d'attaque contre 18 000 organisations
  • Kaseya VSA (2021) : un outil de gestion IT utilisé par des MSP comme point d'entrée pour compromettre leurs clients finaux
  • La cartographie des dépendances tierces est une exigence du NIST CSF et de NIS2

La sécurité globale d'un système d'information ne dépend pas uniquement des mesures déployées en interne. Elle dépend aussi de la sécurité de chacune de ses dépendances : les logiciels utilisés, les services cloud auxquels il est connecté, les prestataires qui y ont accès, les APIs tierces qu'il appelle. Chaque dépendance est un vecteur d'exposition potentiel dont la sécurité est partiellement hors du contrôle de l'organisation.

La multiplication des dépendances techniques est une tendance structurelle de la transformation numérique. Les architectures microservices, les intégrations SaaS, les ecosystèmes de partenaires connectés ont démultiplié le nombre de dépendances de la plupart des organisations. Cette multiplication est souvent nécessaire sur le plan fonctionnel — mais elle implique une gestion rigoureuse des risques tiers.

Les types de dépendances et leurs risques spécifiques

Les dépendances logicielles (bibliothèques open source, composants tiers intégrés dans les développements) exposent aux vulnérabilités dans ces composants. La publication du CVE (Common Vulnerabilities and Exposures) de Log4Shell en décembre 2021 a révélé que des centaines de millions d'applications intégraient une bibliothèque Java vulnérable — souvent à plusieurs niveaux d'indirection, dans des composants qui eux-mêmes dépendaient de Log4j.

Les dépendances de services (SaaS, IaaS, PaaS) exposent aux incidents chez le fournisseur, aux modifications unilatérales de configuration, et aux compromissions de comptes dans l'infrastructure du fournisseur. Les dépendances de prestataires (MSP, intégrateurs, sous-traitants avec accès aux systèmes) créent des vecteurs d'entrée dans l'infrastructure interne via des accès légitimes.

La gestion des risques tiers comme discipline

La gestion des risques tiers (Third-Party Risk Management - TPRM) est une discipline à part entière qui comprend : l'inventaire des tiers avec accès aux systèmes, l'évaluation de leur posture de sécurité (questionnaires, certifications, audits), la contractualisation des exigences de sécurité, et la surveillance continue de leur niveau d'exposition.

Les exigences réglementaires sur la gestion des risques tiers se sont significativement renforcées : DORA impose aux institutions financières de cartographier toutes leurs dépendances ICT critiques et de gérer les risques de concentration (dépendance excessive à un seul fournisseur). NIS2 impose des obligations de sécurité de la chaîne d'approvisionnement pour les secteurs couverts.

Le Software Bill of Materials (SBOM) comme outil de gestion

Le Software Bill of Materials (SBOM) — inventaire structuré de tous les composants logiciels d'une application — est devenu un outil standard de gestion des dépendances logicielles. L'Executive Order américain sur la cybersécurité (2021) a imposé les SBOM pour tous les logiciels vendus au gouvernement fédéral. L'ENISA recommande leur adoption progressive dans les secteurs critiques européens dans le cadre du Cyber Resilience Act.

Le SBOM permet de répondre rapidement à la question critique lors de la publication d'une nouvelle vulnérabilité : "sommes-nous exposés ?" — en identifiant instantanément les applications utilisant le composant vulnérable, plutôt que de devoir effectuer un inventaire d'urgence sous pression.

Dépendances techniques et propagation des incidents
Kaseya VSA — États-Unis, juillet 2021
Kaseya VSA est un outil de gestion et de supervision IT utilisé par des Managed Service Providers (MSP) pour gérer l'infrastructure de leurs clients. Une vulnérabilité zero-day dans Kaseya VSA a été exploitée par le groupe REvil pour déployer un ransomware via la chaîne des MSP vers leurs clients finaux. Environ 1 500 entreprises dans 17 pays ont été touchées en moins de 48 heures via cette unique dépendance. Kaseya a négocié l'obtention d'un outil de déchiffrement auprès des attaquants. L'incident illustre la multiplication des impacts via les dépendances de prestataires.
3CX — international, mars 2023
3CX est un éditeur de logiciels de communication d'entreprise (VoIP) utilisé par plus de 600 000 organisations dans le monde. Sa chaîne de développement a été compromise, permettant aux attaquants (attribués au groupe Lazarus, lié à la Corée du Nord) d'introduire un code malveillant dans une mise à jour légitime signée. Les clients qui ont installé la mise à jour compromise ont vu leurs systèmes infectés. L'incident a été découvert par des chercheurs en sécurité, pas par les équipes de sécurité internes de 3CX. La propagation via une mise à jour légitime illustre la fragilité des dépendances logicielles.
ASUS Live Update — Asie, 2019
Le mécanisme de mise à jour automatique des ordinateurs ASUS a été compromis pendant plusieurs mois. Les attaquants (opération ShadowHammer) ont distribué un logiciel malveillant signé avec le certificat légitime d'ASUS à environ 1 million d'utilisateurs, ciblant spécifiquement un sous-ensemble de machines identifiées par leur adresse MAC. Kaspersky Lab a découvert l'incident. L'opération illustre que même les mécanismes de sécurité (signatures numériques, mises à jour automatiques) peuvent être retournés via des dépendances compromises dans la chaîne de distribution.
WhatsApp