17 agences de cybersécurité s'unissent pour renforcer la sécurité logicielle

Le Software Bill of Materials (SBOM) est en passe de devenir un instrument de politique publique en matière de sécurité informatique. Dans un document conjoint, publié le 3 septembre 2025, 17 agences nationales de cybersécurité proposent une vision partagée du rôle du SBOM – la liste des ingrédients d'un logiciel – dans la sécurisation de l'écosystème logiciel.

CISA, BSI...

Parmi les signataires figurent l'Agence nationale de la sécurité des systèmes d'information (Anssi) en France, la Cybersecurity and Infrastructure Security Agency (CISA) aux Etats-Unis, le Bundesamt für Sicherheit in der Informationstechnik (BSI) en Allemagne, le Centre canadien pour la cybersécurité ainsi que les autorités japonaises et sud-coréennes. La Commission européenne a également contribué à ces travaux.

Le SBOM se présente comme un registre formalisé recensant les composants - open source ou propriétaires - qui composent un logiciel. A l'image d'une liste d'ingrédients, il permet de tracer les dépendances directes et transitives, de corréler ces données avec des bases de vulnérabilités et d'automatiser leur suivi.

Renforcer la sécurité by design

Cette traçabilité "doit nous permettre de renforcer la sécurité par design, mais aussi de gérer plus efficacement les effets boule de neige des vulnérabilités dans des briques logicielles largement réutilisées", explique Vincent Strubel, à la tête de l'agence française, se félicitant de cette initiative collective.

Les attaques sur la supply chain, telles que SolarWinds en 2020 et MOVEit en 2023, ont été le principal catalyseur faisant passer le SBOM d'une préoccupation des équipes DevSecOps à une priorité en matière de cybersécurité. En 2021, les Etats-Unis avaient adopté un décret exigeant des SBOM pour les logiciels achetés par le gouvernement fédéral.

Le CRA rend indispensable l'utilisation des SBOM

L'élan s'est poursuivi à l'échelle internationale. En Europe, c'est le Cyber Resilience Act (CRA), entré en vigueur en décembre 2024, qui rend l'utilisation des SBOM indispensable pour la conformité en imposant aux fabricants de produits numériques de mieux gérer la sécurité de leurs composants logiciels. La majorité des obligations de ce texte s'appliqueront à partir de 2027.

Dans leur déclaration, les agences soulignent que l'intérêt premier du SBOM est de réduire les temps de réaction face aux vulnérabilités critiques. L'épisode du Log4Shell en décembre 2021 illustre ce besoin : les entités dotées d'un SBOM ont pu identifier rapidement si elles utilisaient la librairie Log4j, contrairement à celles contraintes d'auditer manuellement leur code.

Plusieurs acteurs sont concernés par cette initiative : les développeurs de logiciels, les acheteurs pour qui la fourniture d'un SBOM devient un critère de sélection d'un logiciel, les opérateurs qui peuvent hiérarchiser les patchs ainsi que les autorités nationales qui intègrent ces données dans leurs politiques de certification, de surveillance de marché ou de divulgation coordonnée des vulnérabilités.

Vers un socle commun minimal

Mais pour que cette vision commune produise ses effets, encore faut-il éviter que chacun n'impose sa propre méthodologie. C'est pour cette raison que les agences signataires insistent sur la nécessité d'une harmonisation technique pour éviter de freiner l'adoption du SBOM. Aujourd'hui, plusieurs formats coexistent, tels que le Software Package Data Exchange (SPDE) développé par la Linux Foundation ou le CycloneDX créé par la fondation OWASP (Open Worldwide Application Security Project), qui ne sont pas toujours interopérables.

D'où la nécessité de définir un socle commun de données minimal (version, licence, provenance des composants, statut de support...). Il reste à savoir si les fabricants de logiciels joueront le jeu. Au-delà du coût engendré, certains redoutent que la transparence sur les composants n'expose trop leur stratégie technologique ou ne révèle des dépendances jugées sensibles.