Les mandats de Software Bill of Materials transforment la manière dont les fournisseurs sont sélectionnés.

La violation subie par Ernst & Young cette semaine, revendiquée par le gang d'extorsion ShinyHunters, suit un schéma devenu le mode de défaillance par défaut en 2026 : les attaquants n'ont pas forcé les défenses d'EY, ils ont compromis des identifiants via un fournisseur de la chaîne logistique et sont entrés par la porte d'entrée. Ce schéma est précisément ce que les obligations de nomenclature logicielle (SBOM) sont conçues pour détecter avant qu'il ne se produise — et la plupart des entreprises sont encore incapables d'agir sur les SBOM qu'elles sont déjà tenues de collecter.

Une SBOM est un inventaire structuré de tous les composants d'un logiciel : chaque bibliothèque, chaque dépendance, chaque version, jusqu'au plus petit module, y compris le firmware. L'idée est simple — si vous savez exactement ce qui se trouve dans le produit d'un fournisseur, vous pouvez le vérifier par rapport aux vulnérabilités connues dès la publication d'un nouveau CVE, au lieu de le découvrir lors d'un appel d'intervention suite à un incident.

La Vague Réglementaire qui Débarque en 2026

Le Cyber Resilience Act (CRA) de l'UE, en vigueur depuis décembre 2024, entre dans sa phase de mise en application cette année. Les obligations de signalement des vulnérabilités et incidents prennent effet en septembre 2026, et les exigences de production complète de SBOM suivent en décembre 2027 — offrant aux fournisseurs une période d'adaptation, mais non indéfinie. Le CRA exige un inventaire complet des composants pour tout fournisseur de produits numériques vendus sur le marché européen, ce qui en pratique concerne la plupart des fournisseurs de logiciels mondiaux.

Les services financiers font face à une exigence parallèle. Selon le Digital Operational Resilience Act (DORA) de l'UE, les articles 28 à 30 imposent aux entités financières régulées de comprendre et gérer l'ensemble de la chaîne de fournisseurs derrière toute fonction critique — pas seulement leur fournisseur direct, mais aussi les fournisseurs de ce fournisseur. Une banque ne peut plus traiter son fournisseur cloud comme une boîte noire ; elle doit pouvoir répondre à ce qui s'exécute réellement en dessous.

Aux États-Unis, le Executive Order 14028 exige déjà des SBOM conformes aux normes NIST pour les achats de logiciels fédéraux, traduit par la CISA en exigences contractuelles concrètes. Ce seul levier politique a fait plus pour normaliser la production de SBOM chez les fournisseurs commerciaux que n'importe quelle norme volontaire — les entreprises qui veulent des contrats fédéraux doivent en produire une, que leurs autres clients le demandent ou non.

Pourquoi Avoir une SBOM n'est Pas la Même Chose que l'Utiliser

Le mode de défaillance qui apparaît dans les déploiements de 2026 est constant : les organisations traitent la collecte de SBOM comme une case à cocher pour la conformité plutôt que comme un apport opérationnel. Elles demandent des SBOM aux fournisseurs, les classent, et s'arrêtent là. Peu construisent le pipeline qui convertit une liste statique de composants en une décision en temps réel — signalant automatiquement quand un nouveau CVE touche une bibliothèque déployée par trois fournisseurs et poussant cette alerte vers le responsable de la relation avec le fournisseur.

Ce fossé est exactement là où réside le schéma d'attaque de type EY. Une compromission de la chaîne logistique ne s'annonce pas comme une vulnérabilité dans votre propre pile ; elle se manifeste par des identifiants compromis chez un fournisseur dont la composition logicielle interne n'a peut-être jamais été inventoriée, encore moins surveillée face aux nouvelles divulgations.

Ce qu'Exige Réellement un Pipeline Opérationnel de SBOM

• Ingestion lisible par machine, pas de PDF. Les SBOM doivent arriver dans des formats standard (SPDX ou CycloneDX) qui peuvent être analysés automatiquement, et non comme un document archivé par l'équipe conformité.
• Appariement continu des CVE. L'inventaire n'est utile que s'il est vérifié en continu face aux nouvelles vulnérabilités divulguées, et non pas une seule fois lors de l'intégration du fournisseur.
• Cartographie des responsabilités. Chaque composant signalé doit avoir un propriétaire interne nommé, responsable du suivi avec le fournisseur — sans cela, les alertes s'accumulent sans action.
• Profondeur au-delà du premier niveau. Les exigences de type DORA existent précisément parce que l'évaluation des risques au premier niveau manque la compromission qui se produit deux ou trois niveaux plus bas dans la chaîne, ce qui est l'origine des récentes violations très médiatisées.

Mesures Pratiques

Si votre organisation collecte des SBOM uniquement pour satisfaire une clause contractuelle ou un auditeur, vous supportez le coût de la conformité sans bénéfice sécuritaire — et le calendrier de mise en œuvre de l'UE (septembre 2026 pour le signalement des incidents, décembre 2027 pour la production complète de SBOM) signifie que l'exigence ne fera que se renforcer. Commencez par choisir une catégorie de fournisseurs à haut risque — ceux qui ont un accès profond aux systèmes internes, comme les plateformes de gestion de services IT impliquées dans la violation d'EY cette semaine — et construisez d'abord le pipeline d'ingestion à alerte pour cette catégorie, plutôt que d'essayer d'opérationnaliser toutes les relations fournisseurs à la fois. Un pipeline partiel qui déclenche réellement des alertes vaut mieux qu'une archive complète de SBOM que personne ne consulte.