Vous avez sécurisé vos mots de passe, activé la double authentification, formé vos équipes au phishing. Et pourtant, la porte d'entrée la plus discrète de votre système d'information ne dépend pas de vous : elle dépend de vos fournisseurs. Une bibliothèque open source que votre application charge sans que personne ne l'ait jamais ouverte. Une mise à jour automatique d'un logiciel de gestion. Un prestataire SaaS qui héberge vos fichiers RH. À chaque fois, vous héritez de la sécurité — ou de l'insécurité — de quelqu'un d'autre.
C'est le risque de la chaîne d'approvisionnement logicielle, la supply chain. Il ne fait pas la une comme un ransomware, mais il est devenu l'un des vecteurs préférés des attaquants, pour une raison simple : compromettre un seul fournisseur permet d'atteindre des centaines de clients d'un coup. Deux affaires ont marqué les esprits — SolarWinds, où une mise à jour piégée d'un logiciel de supervision a servi de cheval de Troie, et XZ Utils, où une porte dérobée a été insérée patiemment dans un composant open source utilisé partout. Aucune des deux ne visait une PME en particulier. Toutes deux auraient pu en emporter des milliers sans qu'elles s'en aperçoivent.
Pour un dirigeant de PME ou d'ETI, la question n'est donc pas « suis-je une cible ? » mais « de qui est-ce que je dépends, et est-ce que je le sais ? ». Cet article explique pourquoi ce risque se transmet, et surtout comment le réduire concrètement, sans équipe de sécurité dédiée.
Pourquoi une PME hérite du risque de ses fournisseurs
Votre système d'information n'est pas un bloc que vous contrôlez de bout en bout. C'est un assemblage. Votre site tourne sur un framework, qui s'appuie sur des dizaines de bibliothèques, elles-mêmes maintenues par des inconnus, parfois bénévoles. Votre comptabilité, votre CRM, votre messagerie sont souvent des services opérés ailleurs. Chaque brique ajoute une surface que vous n'avez ni écrite ni auditée. Le risque se transmet par quatre canaux principaux :
- Les dépendances open source. Une application moderne repose sur des centaines de composants tiers. Il suffit qu'un seul soit compromis — ou abandonné par son mainteneur — pour introduire une faille dans votre produit sans que vous ayez touché une ligne de code.
- Les mises à jour piégées. Vous faites confiance à vos éditeurs et vous appliquez leurs correctifs, comme il se doit. Mais si l'attaquant compromet la chaîne de fabrication de l'éditeur, la mise à jour signée que vous installez devient le vecteur de l'attaque. C'est le scénario SolarWinds.
- Les prestataires SaaS. Le service qui héberge vos données a ses propres fournisseurs et ses propres failles. Une fuite chez lui est une fuite chez vous, avec vos clients et vos obligations RGPD à la clé.
- Les accès accordés aux prestataires. L'infogérant, l'agence web ou le consultant qui dispose d'un accès VPN ou d'un compte administrateur devient une extension de votre surface d'attaque. Si son poste est compromis, votre réseau l'est aussi.
Ce que vous ne pouvez pas protéger : l'inventaire manquant
La première cause d'exposition n'est pas technique, elle est documentaire : la plupart des PME ne savent pas de quoi leur système est fait. Quels composants ? Quelles versions ? Quels prestataires ont un accès actif, et depuis quand ? Sans cet inventaire, chaque nouvelle vulnérabilité publiée devient une loterie : êtes-vous concerné ou pas ? Personne ne peut répondre, et le temps perdu à chercher est du temps offert à l'attaquant.
C'est là qu'intervient la notion de SBOM (Software Bill of Materials), la « nomenclature logicielle ». C'est la liste, tenue à jour, de tous les composants qui entrent dans vos applications et services — comme la liste des ingrédients sur un produit alimentaire. Quand une faille critique est annoncée sur une bibliothèque, un SBOM permet de répondre en minutes plutôt qu'en jours à la seule question qui compte : « est-ce que nous l'utilisons ? »
Exiger la sécurité de ses fournisseurs, par contrat
Vous ne pouvez pas auditer le code de chaque éditeur. Mais vous pouvez déplacer une partie du risque là où il doit être : chez le fournisseur. Cela passe par des clauses contractuelles simples et vérifiables, même pour une petite structure :
- Obligation de notification d'incident dans un délai défini (par exemple 48 à 72 heures).
- Engagement sur les correctifs de sécurité et leur délai d'application.
- Hébergement des données dans l'UE et conformité RGPD documentée.
- Droit d'obtenir des preuves de sécurité : certifications, résultats d'audit, ou a minima un questionnaire de sécurité rempli.
- Procédure de révocation des accès à la fin de la mission.
Ces exigences ne sont pas réservées aux grands comptes. Le règlement DORA impose déjà ce type de vigilance sur les prestataires informatiques du secteur financier, et la directive NIS2 pousse toute une chaîne de sous-traitance vers ces standards. Anticiper, c'est éviter d'y être contraint dans l'urgence.
Garder l'œil ouvert : la veille sur les vulnérabilités
Un inventaire n'a de valeur que confronté à l'actualité des failles. Chaque jour, de nouvelles vulnérabilités sont publiées ; certaines touchent des composants que vous utilisez sans le savoir. La veille consiste à croiser en continu votre inventaire — composants, versions, prestataires — avec les bulletins de sécurité (le CERT-FR de l'ANSSI, les avis éditeurs, les bases de vulnérabilités) pour être alerté quand l'une d'elles vous concerne, avant que l'attaquant ne s'en serve.
Pour une PME, l'enjeu n'est pas de tout lire, mais de recevoir la bonne alerte au bon moment. C'est une fonction que l'on peut externaliser ou automatiser, sans recruter une équipe de supervision.
Votre plan d'action
Six étapes concrètes, réalisables même sans équipe de sécurité dédiée :
- Dressez l'inventaire. Listez vos applications, leurs composants principaux et tous les prestataires disposant d'un accès. Commencez simple : un tableur vaut mieux que rien.
- Cartographiez les accès prestataires. Qui a un compte, un VPN, une clé ? Coupez les accès dormants et les comptes de missions terminées.
- Réduisez les privilèges. Un prestataire n'a besoin que du strict nécessaire, pour la durée de sa mission — pas d'un accès administrateur permanent.
- Ajoutez des clauses de sécurité à vos contrats fournisseurs : notification d'incident, correctifs, hébergement UE, révocation des accès.
- Mettez en place une veille. Reliez votre inventaire aux bulletins de vulnérabilités pour être alerté dès qu'une faille vous concerne.
- Testez ce qui est visible de l'extérieur. Beaucoup de compromissions passent par un composant ou un service exposé sur Internet et oublié. Un audit régulier de votre surface d'attaque externe révèle ces angles morts.
Comment Sedona peut aider
Réduire le risque fournisseur commence par voir ce que vous exposez. Sedona Radar cartographie votre surface d'attaque externe — services exposés, technologies détectées, vulnérabilités connues, configuration DNS et TLS — et vous donne une vue claire des composants visibles depuis Internet, y compris ceux qu'un prestataire aurait laissés en ligne. Pour aller plus loin, notre veille cyber personnalisée surveille en continu les vulnérabilités qui touchent votre stack, et un audit de surface manuel peut vous aider à construire et tenir à jour l'inventaire de vos composants (SBOM) et de vos accès prestataires. Sedona évalue et vous alerte ; elle ne certifie pas votre conformité à votre place, mais elle vous donne les éléments pour décider en connaissance de cause. Testez gratuitement votre exposition avec le plan Découverte de Sedona Radar, ou parlez-en à un expert.
