La compromission d’un fournisseur logiciel ne touche jamais une seule victime. Elle se propage à tous ceux qui ont installé, compilé ou déployé le composant affecté. C’est la logique de l’attaque par la chaîne d’approvisionnement : au lieu de viser une cible durcie, l’attaquant remonte en amont, vers un maillon de confiance dont le produit sera ensuite distribué à des milliers d’organisations.
Les incidents marquants des dernières années ont installé cette menace au premier rang des préoccupations des RSSI. La porte dérobée insérée dans la bibliothèque de compression XZ Utils en 2024, découverte par hasard avant son exploitation massive, a montré qu’un projet open source maintenu par une seule personne pouvait devenir un point d’entrée vers une part considérable de l’infrastructure Linux mondiale. Avant elle, l’affaire SolarWinds avait démontré le même principe à l’échelle d’un éditeur commercial.
Cet article propose une lecture opérationnelle de la sécurité de la chaîne d’approvisionnement logicielle. Il définit le périmètre, présente le SBOM comme instrument central, situe les obligations réglementaires européennes, et décrit une méthode de mise en oeuvre qui ne se réduit pas à cocher une case de conformité.
Qu’est-ce que la chaîne d’approvisionnement logicielle
La chaîne d’approvisionnement logicielle est l’ensemble des composants, outils et acteurs qui contribuent à la fabrication, à la distribution et à l’exploitation d’un logiciel. Elle dépasse de loin le code écrit en interne.
Un logiciel moderne est assemblé bien plus qu’il n’est écrit. Selon les analyses récurrentes de l’écosystème, la part de code tiers dans une application typique dépasse souvent 80 pour cent du volume total. Le rapport annuel de Sonatype sur l’état de la chaîne d’approvisionnement logicielle [4] documente année après année la croissance du nombre de téléchargements de composants open source et, en parallèle, celle des paquets malveillants publiés intentionnellement dans les dépôts publics.
Le périmètre à considérer comprend plusieurs couches :
- Les dépendances directes : les bibliothèques que le développeur choisit explicitement d’utiliser.
- Les dépendances transitives : celles tirées indirectement par les dépendances directes, souvent invisibles sans outillage.
- Les images de conteneurs : systèmes de base, paquets système, couches applicatives empilées.
- La chaîne de construction : outils de compilation, gestionnaires de paquets, runners d’intégration continue, qui peuvent eux-mêmes être compromis.
- Les services externes : API, dépôts d’artefacts, registres de paquets dont dépend le fonctionnement ou le déploiement.
Chaque couche est une surface d’attaque. Une dépendance transitive vulnérable est aussi dangereuse qu’une dépendance directe, et plus difficile à repérer parce qu’elle n’a fait l’objet d’aucune décision consciente.
Pourquoi la chaîne d’approvisionnement est devenue la cible
L’attaquant rationnel cherche le meilleur rapport entre effort et impact. La chaîne d’approvisionnement offre exactement cela : un seul point compromis en amont contamine un grand nombre de victimes en aval.
L’ENISA, dans son analyse du paysage des menaces sur la chaîne d’approvisionnement [3], souligne que ces attaques visent en priorité le code et les processus du fournisseur plutôt que ses clients directement, précisément pour exploiter la relation de confiance entre les deux. Le client installe une mise à jour signée, légitime en apparence, et hérite de la compromission sans aucune action malveillante de sa part.
Plusieurs facteurs expliquent la montée du phénomène :
- La densité des dépendances. Un projet qui déclare une vingtaine de dépendances directes en résout fréquemment plusieurs centaines en transitif. La surface réelle est sans commune mesure avec ce que perçoit l’équipe de développement.
- La maintenance fragile de composants critiques. De nombreuses bibliothèques largement utilisées reposent sur un ou deux contributeurs bénévoles, sans financement ni relève organisée.
- L’automatisation des chaînes de déploiement. Les pipelines d’intégration et de livraison continue tirent et exécutent du code à chaque build. Une compromission du pipeline ou d’un paquet tiré au build s’exécute avec les privilèges de la chaîne.
- La confusion de dépendances et le typosquatting. Publier un paquet malveillant au nom proche d’un paquet légitime, ou au même nom dans un registre public mal priorisé, reste une technique efficace.
Ce constat rejoint directement la logique de la chaîne CI/CD sécurisée : tant que l’on raisonne uniquement sur le code écrit en interne, on ignore la majorité du risque réellement embarqué.
Le SBOM : inventaire central de la chaîne logicielle
Le SBOM, ou Software Bill of Materials, est un inventaire formel et lisible par machine de tous les composants qui entrent dans un logiciel. C’est l’équivalent, pour le logiciel, de la nomenclature qu’un industriel tient pour un produit manufacturé.
Sans inventaire, aucune des questions essentielles n’a de réponse fiable. Quand une vulnérabilité critique frappe une bibliothèque très répandue, la première question d’un RSSI est simple : est-ce que je l’utilise, et où ? Lors de l’affaire Log4Shell fin 2021, les organisations dotées d’un inventaire à jour ont répondu en heures. Les autres ont passé des semaines à fouiller manuellement leurs systèmes. Le SBOM transforme cette question d’une enquête longue en une requête immédiate.
Ce que contient un SBOM
Un SBOM décrit, pour chaque composant, un ensemble minimal d’attributs : le nom, la version exacte, l’identifiant unique du composant, son éditeur ou sa provenance, et ses relations de dépendance avec les autres composants. La NTIA américaine a établi très tôt le socle des éléments minimaux attendus d’un SBOM exploitable [5], qui sert aujourd’hui de référence commune.
La granularité importe. Un SBOM qui ne liste que les dépendances directes manque l’essentiel du risque. Un SBOM utile résout l’arbre complet, transitif inclus, et précise les versions au niveau le plus fin possible, car une vulnérabilité s’attache à une version précise et non à un nom de paquet en général.
Les formats normalisés
Deux formats dominent et sont l’un comme l’autre acceptables :
- SPDX, porté par la Linux Foundation, devenu la norme ISO/IEC 5962 [7]. Il excelle dans la description des licences et de la provenance, ce qui en fait un bon choix quand la conformité juridique compte autant que la sécurité.
- CycloneDX, porté par l’OWASP [6]. Orienté sécurité applicative, il intègre nativement les vulnérabilités connues, les services externes et désormais les modèles d’IA, ce qui le rend pratique pour relier inventaire et veille.
Le choix entre les deux relève davantage de l’outillage déjà en place que d’un débat de principe. La plupart des chaînes savent générer et convertir les deux. Ce qui ne se négocie pas, c’est l’usage d’un format normalisé plutôt qu’un tableur maison, car seul un format machine permet l’automatisation de la corrélation avec les vulnérabilités.
Le cadre réglementaire européen
La sécurité de la chaîne d’approvisionnement logicielle n’est plus une bonne pratique facultative. Deux textes européens majeurs la rendent exigible, par des voies différentes.
Le Cyber Resilience Act
Le Cyber Resilience Act, Règlement (UE) 2024/2847 [1], encadre les produits comportant des éléments numériques mis sur le marché européen. Il impose aux fabricants des obligations de sécurité par conception, de gestion des vulnérabilités tout au long du cycle de vie, et de transparence sur les composants intégrés.
Le texte ne prononce pas le mot SBOM comme une formalité isolée, mais il exige que le fabricant identifie et documente les composants du produit, y compris les composants tiers, et gère leurs vulnérabilités. En pratique, le SBOM est le seul instrument capable de satisfaire cette exigence de manière vérifiable et automatisable. Les échéances du CRA s’échelonnent jusqu’à sa pleine application en 2027, ce qui laisse aux fabricants une fenêtre courte pour se doter de la chaîne de génération et de suivi.
Pour une lecture détaillée des obligations qui pèsent sur les fabricants, voir notre analyse du Cyber Resilience Act.
NIS2 et la sécurité des fournisseurs
La directive NIS2, Directive (UE) 2022/2555 [2], aborde la chaîne d’approvisionnement sous l’angle de la gestion des risques. Elle impose aux entités concernées de prendre en compte, dans leurs mesures techniques et organisationnelles, les risques liés à leurs fournisseurs et prestataires directs, y compris la sécurité de leurs produits et de leurs pratiques de développement.
Concrètement, une entité soumise à NIS2 ne peut plus se contenter de sécuriser son propre périmètre. Elle doit évaluer la posture de ses fournisseurs logiciels, exiger des garanties contractuelles, et intégrer les composants tiers dans sa propre analyse de risque. Le SBOM fourni par un éditeur devient alors un élément d’évaluation tangible plutôt qu’une déclaration de confiance. Pour comprendre l’ensemble du dispositif NIS2, consultez notre guide complet de la directive.
Le cadre de référence NIST
Au-delà des textes contraignants, le NIST publie avec la SP 800-161 [8] un cadre détaillé de gestion des risques de la chaîne d’approvisionnement en cybersécurité. Sans valeur réglementaire en Europe, il fournit une grille méthodologique solide pour structurer une démarche : identification des risques fournisseurs, exigences contractuelles, contrôle continu et réponse aux incidents survenant en amont.
Mettre en oeuvre une démarche de maîtrise
Disposer d’un SBOM ne protège de rien en soi. La valeur naît de l’intégration de l’inventaire dans un cycle vivant. Voici les étapes d’une démarche réaliste.
Étape 1 : cartographier l’existant
La première action consiste à générer un SBOM pour les applications et les produits déjà en production. Un outil d’analyse de composition logicielle, dit SCA, scanne les artefacts et résout l’arbre complet des dépendances. Cette première cartographie révèle presque toujours des surprises : composants oubliés, versions obsolètes, doublons de bibliothèques. Elle établit la base de référence.
Étape 2 : générer automatiquement à chaque build
Un SBOM produit une seule fois devient faux dès la mise à jour suivante. La génération doit être automatisée et déclenchée à chaque construction, intégrée dans la chaîne CI/CD. Chaque version d’un produit dispose ainsi de son propre SBOM, daté et archivé. Cette automatisation rejoint les pratiques DevSecOps et s’appuie sur les mêmes outils que la gestion des vulnérabilités dans le pipeline.
Étape 3 : corréler avec les vulnérabilités
C’est l’étape qui transforme l’inventaire en protection. Le SBOM est confronté en continu aux bases de vulnérabilités connues. Quand une faille est publiée pour un composant inventorié, l’alerte est immédiate et précise : on sait quel produit, quelle version et quel environnement sont touchés. Cette logique prolonge directement la gestion des vulnérabilités du CVE au patch, en lui donnant la couche d’inventaire qui lui manque souvent.
Étape 4 : définir une politique de dépendances
L’inventaire et la corrélation ne suffisent pas sans règles d’action. Une politique de dépendances fixe ce qui est autorisé et ce qui ne l’est pas : versions minimales, licences acceptables, interdiction des composants non maintenus, blocage des paquets dont la provenance n’est pas vérifiée. Cette politique s’applique idéalement dès la phase de développement, en faisant échouer un build qui introduit une dépendance non conforme. Prévenir l’entrée d’un composant douteux coûte infiniment moins cher que de le retirer une fois déployé partout.
Étape 5 : exiger des SBOM de ses fournisseurs
La maîtrise ne s’arrête pas au code interne. Pour les logiciels achetés, l’entité doit exiger contractuellement un SBOM de ses éditeurs, au format normalisé, mis à jour à chaque version. Cela permet d’étendre la corrélation des vulnérabilités aux produits tiers et de répondre à l’exigence NIS2 de maîtrise des risques fournisseurs. Un éditeur incapable de fournir un SBOM en 2026 signale une maturité de sécurité limitée.
Pièges fréquents
Plusieurs erreurs récurrentes vident la démarche de sa substance.
Le SBOM-tiroir est le plus courant : on génère un inventaire pour cocher une case de conformité, puis on l’archive sans jamais l’exploiter. Un inventaire non surveillé ne détecte aucune vulnérabilité nouvelle.
La granularité insuffisante ruine la corrélation : un SBOM qui ne descend pas au niveau des versions exactes ou qui ignore le transitif laisse passer la majorité des failles réelles.
La confusion entre licence et sécurité conduit certaines équipes à n’utiliser le SBOM que pour la conformité juridique des licences open source, en négligeant son rôle de sécurité, ou l’inverse. Les deux usages sont légitimes et complémentaires.
Enfin, l’oubli de la chaîne de construction est fréquent : on inventorie le produit livré mais pas les outils qui l’ont fabriqué. Or un runner d’intégration continue compromis ou un gestionnaire de paquets détourné injecte du code malveillant qui n’apparaîtra dans aucun SBOM applicatif. La sécurité de la chaîne d’approvisionnement englobe la chaîne de production elle-même.
Articulation avec la posture globale
La maîtrise de la chaîne d’approvisionnement n’est pas un chantier isolé. Elle s’inscrit dans une architecture de défense où chaque brique renforce les autres. L’inventaire SBOM alimente la gestion des vulnérabilités. La politique de dépendances s’applique dans la chaîne CI/CD. Les exigences fournisseurs nourrissent l’analyse de risque NIS2. Le tout converge vers la conformité CRA pour les organisations qui mettent des produits numériques sur le marché.
Cette intégration distingue une démarche mature d’une simple génération d’inventaires. Le SBOM est le fil conducteur, mais il ne vaut que par les processus qui le consomment.
Questions fréquentes
Le SBOM est-il obligatoire en France en 2026 ?
Il n’existe pas d’obligation française autonome nommant le SBOM. En revanche, le Cyber Resilience Act impose aux fabricants de produits comportant des éléments numériques de documenter et de gérer les composants intégrés, ce qui rend le SBOM l’outil de conformité naturel. NIS2 impose par ailleurs la maîtrise des risques liés aux fournisseurs. Le SBOM devient donc incontournable en pratique, même sans mention nominative dans la loi.
Quelle différence entre SPDX et CycloneDX ?
Ce sont deux formats normalisés de SBOM. SPDX, porté par la Linux Foundation, est devenu une norme ISO/IEC 5962 et excelle dans la description des licences et de la provenance. CycloneDX, porté par l’OWASP, est orienté sécurité applicative et intègre nativement les vulnérabilités, les services et les modèles d’IA. Les deux sont valides : le choix dépend de l’écosystème d’outillage déjà en place.
Un SBOM suffit-il à sécuriser la chaîne d’approvisionnement ?
Non. Un SBOM est un inventaire statique. Sa valeur vient de son exploitation : corrélation continue avec les bases de vulnérabilités, alerte quand un composant inventorié devient vulnérable, et politique de dépendances appliquée dès la phase de développement. Un SBOM produit puis archivé sans surveillance n’apporte aucune protection réelle.
Comment gérer les dépendances transitives ?
Les dépendances transitives sont les composants tirés indirectement par vos dépendances directes. Elles représentent souvent la majorité du volume et la plus grande part du risque, car elles échappent à la décision consciente du développeur. Un outil d’analyse de composition logicielle résout l’arbre complet des dépendances et les fait figurer dans le SBOM. La politique de dépendances doit s’appliquer à cet arbre entier, pas seulement à la première couche.
Le CRA s’applique-t-il aux logiciels libres ?
Le CRA prévoit un régime allégé pour l’open source développé hors activité commerciale. Les développeurs bénévoles ne sont pas traités comme des fabricants. En revanche, dès qu’un éditeur intègre un composant libre dans un produit commercialisé, c’est lui qui porte la responsabilité de conformité sur l’ensemble du produit, composants libres inclus. La responsabilité suit la mise sur le marché, pas l’origine du code.
À retenir
La chaîne d’approvisionnement logicielle est devenue le terrain où se joue une part décisive de la sécurité des organisations. Le code écrit en interne ne représente qu’une fraction de ce qui s’exécute réellement en production. Ignorer les composants tiers revient à sécuriser sa porte d’entrée en laissant les fenêtres ouvertes.
Le SBOM est l’instrument qui rend cette réalité visible et actionnable. Couplé à une corrélation continue avec les vulnérabilités, à une politique de dépendances appliquée au build et à des exigences fermes envers les fournisseurs, il transforme un angle mort en surface maîtrisée. Le cadre européen, avec le CRA et NIS2, ne fait qu’acter ce que la pratique imposait déjà : on ne peut pas défendre ce qu’on n’a pas inventorié.