En 2026, 68 % des organisations soumises à NIS2 ont produit une politique de gestion des risques documentée. Parmi elles, moins de 30 % disposent d'un inventaire exhaustif de leurs composants logiciels tiers — c'est-à-dire d'un Software Bill of Materials (SBOM) fonctionnel. Ce décalage n'est pas anodin : il représente l'une des principales zones d'opacité dans les programmes de conformité actuels, et la première surface d'attaque non adressée dans les audits NIS2/DORA de 2025-2026 (ENISA Threat Landscape 2026).
Dans cet article, vous découvrirez ce que NIS2 et DORA exigent réellement en matière d'inventaire logiciel, pourquoi la majorité des organisations confondent inventaire applicatif et SBOM réglementaire, et comment réduire cet écart sans refondre votre architecture de gouvernance.
Le contexte réglementaire : deux directives, une exigence convergente
L'Article 21 de NIS2 impose aux entités essentielles et importantes de mettre en place « des politiques et procédures relatives à l'analyse des risques et à la sécurité des systèmes d'information ». Cette formulation couvre explicitement, dans les lignes directrices ENISA publiées en 2025, la traçabilité des composants logiciels utilisés dans les systèmes d'information critiques.
DORA va plus loin dans le secteur financier : le règlement impose une cartographie des dépendances ICT (Article 28) incluant les prestataires tiers, mais aussi — et c'est moins souvent cité — les composants logiciels open source intégrés dans les chaînes de traitement. Un composant non documenté est, du point de vue de l'auditeur DORA, un risque de concentration non déclaré.
Ces deux cadres convergent vers une obligation commune : savoir précisément ce qui tourne dans vos systèmes, d'où ça vient, qui le maintient, et quelle est la surface de vulnérabilité associée. C'est la définition fonctionnelle d'un SBOM.
Ce que les organisations produisent — et ce que la réglementation exige
La confusion la plus répandue oppose deux types d'inventaires.
L'inventaire fonctionnel — c'est ce que la majorité des organisations ont déjà. Il liste les applications déployées, les licences, les versions majeures. Il répond à la question : « Quels logiciels utilisons-nous ? » Il est produit par les équipes IT pour les besoins de gestion des actifs et des budgets.
Le SBOM réglementaire — c'est ce que NIS2/DORA exige implicitement. Il liste les composants de chaque application : bibliothèques open source, dépendances transitives, frameworks, containers, modules tiers. Il répond à la question : « De quoi sont construits les logiciels que nous utilisons, et qui est responsable de leur maintenance ? »
La différence opérationnelle est majeure. Prenons un exemple concret : votre ERP est dans votre inventaire fonctionnel. Mais les 847 dépendances npm du frontend de cet ERP, dont 12 sont maintenues par des projets open source en dormance depuis 18 mois ? Elles n'y figurent pas — et elles représentent pourtant votre surface d'exposition réelle aux vulnérabilités de type Log4Shell ou XZ Utils.
En 2026, 43 % des incidents cyber déclarés sous NIS2 impliquent une vulnérabilité dans un composant tiers non inventorié (ENISA CSIRT Network, Q1 2026). Ce n'est pas un problème de détection — c'est un problème de connaissance.
Trois erreurs communes dans la construction d'un SBOM conforme
Première erreur : traiter le SBOM comme un projet ponctuel. La plupart des organisations, quand elles produisent un SBOM, le font dans le cadre d'une mission d'audit ou de certification. Le résultat est un document statique qui reflète l'état du système à J. Six mois après, la moitié des dépendances ont évolué, de nouvelles ont été ajoutées, certaines ont été abandonnées par leurs mainteneurs. Un SBOM non mis à jour en continu n'est pas un actif de conformité — c'est une dette documentaire.
La bonne pratique : intégrer la génération de SBOM dans vos pipelines CI/CD. Des outils comme Syft, SPDX, ou CycloneDX permettent de produire un SBOM à chaque build et de le versionner avec votre code. Le SBOM devient alors un artefact vivant, pas un rapport annuel.
Deuxième erreur : se limiter aux dépendances directes. Les dépendances transitives — les dépendances de vos dépendances — représentent en moyenne 73 % de la surface logicielle totale d'une application moderne (GitHub Advisory Database, 2025). Inventorier uniquement les bibliothèques que vous importez explicitement, c'est ignorer les trois quarts de votre exposition.
L'incident XZ Utils en 2024 a été précisément de cette nature : une backdoor introduite dans une dépendance transitive de niveau 2, invisible dans les inventaires de premier niveau de la quasi-totalité des organisations affectées.
Troisième erreur : dissocier SBOM et gestion des vulnérabilités. Un SBOM sans feed de vulnérabilités associé est un catalogue, pas un outil de gestion des risques. La valeur réelle d'un SBOM réglementaire, au sens NIS2/DORA, réside dans sa capacité à répondre à la question : « Si une CVE critique est publiée demain sur cette bibliothèque, combien de systèmes dans mon périmètre sont affectés, et lesquels sont critiques ? »
Cette capacité de réponse rapide est explicitement attendue dans le cadre DORA (gestion des incidents ICT, Article 17) et implicitement dans NIS2 (notification dans les 24h, Article 23). Sans SBOM connecté à un feed CVE automatisé, la réponse à cette question prend en général plusieurs jours — bien au-delà des délais réglementaires.
Comment évaluer votre maturité SBOM en 30 minutes
Quatre questions permettent de positionner votre organisation.
Avez-vous un SBOM pour vos 10 systèmes d'information les plus critiques (au sens NIS2/DORA) — incluant les dépendances transitives ? Si non, vous avez un inventaire fonctionnel, pas un SBOM.
Ce SBOM est-il régénéré automatiquement à chaque déploiement ? Si non, sa fraîcheur ne peut pas être garantie à l'auditeur.
Votre SBOM est-il connecté à un feed de vulnérabilités (NVD, OSV, GitHub Advisory) avec alertes automatiques ? Si non, il n'est pas opérationnel en contexte de réponse à incident.
Pouvez-vous produire, en moins d'une heure, la liste des systèmes affectés par une CVE donnée sur n'importe quel composant de votre inventaire ? Si non, votre temps de réponse réglementaire est à risque.
Presidio intègre un module de cartographie des dépendances logicielles connecté aux feeds CVE majeurs, permettant de centraliser le suivi SBOM dans votre tableau de bord de conformité NIS2/DORA. Demander un accès anticipé →
Conclusion
Trois insights à retenir. L'inventaire fonctionnel ne couvre pas les dépendances transitives — qui représentent 73 % de votre surface logicielle réelle. Un SBOM statique produit pour l'audit n'est pas un actif de conformité — c'est un instantané périmé. Et la capacité à répondre rapidement à une CVE critique est une obligation opérationnelle sous NIS2 et DORA, pas une bonne pratique optionnelle.
Les organisations qui traitent le SBOM comme un livrable d'audit seront systématiquement hors délai sur la notification d'incident le jour où une vulnérabilité critique touche leur parc. Celles qui l'intègrent dans leur pipeline de développement réduisent ce délai de plusieurs jours à quelques heures.
Et dans votre contexte : combien de temps vous faudrait-il, aujourd'hui, pour lister tous les systèmes affectés par la prochaine Log4Shell ?
Lire aussi : Gouvernance des tiers sous NIS2/DORA — Shadow IT et inventaire des actifs NIS2.