Les SBOM en 2026 : tout le monde les génère, personne ne les utilise

L'ENISA vient de publier son rapport sur l'état d'avancement de l'adoption des SBOM en 2026, basé sur une enquête menée auprès de 334 organisations (65 % basées dans l'UE, 80 % directement impactées par le Cyber Resilience Act (CRA)). C'est l'aperçu le plus clair à ce jour de la position de l'industrie en matière de transparence de la chaîne d'approvisionnement logicielle, et le tableau est plus nuancé que « tout le monde est à bord ».

Voici ce qui en ressort.

Le CRA fait le gros du travail

Sans surprise, le CRA est le principal moteur de l'adoption des SBOM. 43 % des organisations affirment que le CRA a considérablement accéléré leur investissement dans les SBOM, et 29 % signalent une influence modérée. 78 % ont entamé leur parcours SBOM, et 79 % s'attendent à atteindre le niveau de maturité requis d'ici à ce que le CRA devienne pleinement applicable en décembre 2027.

Cela signifie qu'environ une organisation sur cinq s'attend à manquer la date limite, et 12 % ne peuvent même pas estimer de calendrier.

Générer des SBOM et les utiliser sont deux choses différentes

La plupart des organisations produisent désormais des SBOM. 39 % les génèrent au moment de la construction (build time), et 74 % ont au moins partiellement automatisé la génération par version. Mais la consommation est à la traîne :

• 44 % signalent un écart modéré entre la génération des SBOM et leur utilisation réelle, et 23 % signalent un écart significatif. Seuls 7 % l'ont comblé.
• 20 % des répondants ne savent pas si ou comment les SBOM sont consommés au sein de leur organisation.
• La propre conclusion de l'ENISA est que les SBOM sont utilisés « principalement à des fins de conformité » plutôt que pour une sécurité active.

Une SBOM inutilisée dans un registre d’artefacts n’est qu’une simple formalité administrative. Les SBOM n’apportent de la valeur qu’ lorsqu’elles alimentent la gestion des vulnérabilités et des licences. C’est là que les équipes rencontrent des difficultés. 58 % considèrent la mise en correspondance des vulnérabilités (alignement CPE/PURL, faux positifs) comme un défi majeur, et 60 % signalent des problèmes de qualité des données, tels que des composants et des identifiants incomplets. Lisez notre article « Comprendre les risques liés aux licences open source » pour en savoir plus sur la manière dont nous évaluons les risques et pourquoi cette évaluation est fiable.

Les fournisseurs n'envoient pas de SBOM

La plupart des organisations ne reçoivent pas de SBOM de leurs fournisseurs parce que la plupart des fournisseurs ne les envoient pas.

• 39 % des organisations ne reçoivent jamais de SBOM pour les logiciels commerciaux qu'elles achètent. 39 % n'en reçoivent que rarement. Seuls 2 % les reçoivent toujours.
• Seuls 10 % ont des clauses SBOM obligatoires dans les contrats fournisseurs (bien que 55 % y travaillent).
• 45 % déclarent que moins d'un quart de leurs fournisseurs répondent à leurs exigences en matière de SBOM.
• L'exhaustivité (27 %), la précision des identifiants (17 %) et les références de vulnérabilités (12 %) sont les principales lacunes en matière de qualité.

La profondeur aggrave le problème de qualité. 36 % des organisations ont besoin de SBOM couvrant tous les composants primaires et les dépendances directes, mais seulement 29 % les reçoivent. Pour les SBOM à profondeur complète, l'écart est de 24 % nécessaires contre 14 % reçus. Et 45 % ne savent même pas quelle profondeur ils obtiennent. 

Étant donné que la plupart des vulnérabilités réelles se cachent dans les dépendances transitives, cela limite directement la valeur de sécurité de tout programme SBOM.

Ce que les données révèlent également

Le rapport met en lumière d'autres conclusions qui révèlent une industrie consciente du problème, mais qui peine à passer à l'action.

Quels sont les freins ?

• L'inquiétude dépasse l'investissement. Plus de 90 % des organisations s'inquiètent de la sécurité de la chaîne d'approvisionnement, mais seulement 34 % y allouent des ressources significatives. Un manque de compétences aggrave le problème, 57 % citant le manque de compétences ou de personnel comme un obstacle.
• La complétude est le principal obstacle. 62 % estiment qu'atteindre un haut degré de complétude des SBOM est assez difficile, voire extrêmement difficile.
• La guerre des formats n'est pas terminée. CycloneDX domine (44 %) face à SPDX (29 %), mais 28 % utilisent encore des formats propriétaires ou non standards. Cela représente un risque direct de non-conformité, car le CRA exige un format couramment utilisé et lisible par machine, et la directive BSI allemande attend explicitement CycloneDX 1.6+ ou SPDX 3.0.1+.

Qui est en tête et quelles sont les prochaines étapes ?

• Les petites entreprises sont discrètement en avance. 23 à 25 % des micro et petites entreprises déclarent une implémentation de SBOM mature et automatisée, contre seulement 4 à 6 % des moyennes et grandes entreprises. Pendant ce temps, 36 % des grandes entreprises considèrent les SBOM comme une « charge obligatoire ».
• Le marché souhaite  une implémentation de référence avec des pipelines prêts à l'emploi (26 %), des benchmarks d'outils et un guide d'achat (22 %), des tests de conformité (18 %), et un profil définissant ce qu'est un SBOM « suffisamment bon » (31 %).

Ce que cela signifie en pratique

Les données de l'ENISA indiquent que l'utilisation sera le défi majeur de 2026. Cela implique une génération automatisée à chaque build, des mises à jour continues tout au long de la période de support produit, des workflows de gestion des vulnérabilités réellement liés aux données SBOM, et une visibilité sur ce que vos fournisseurs vous livrent. C'est là que l'enquête révèle les plus grandes lacunes, et c'est là que le CRA exercera la plus forte pression.

Comment Aikido vous aide à y parvenir

C'est là qu'Aikido Security intervient, en poussant la transparence de la chaîne d'approvisionnement au-delà de la simple conformité, pour l'intégrer à vos workflows de gestion des vulnérabilités et des licences.

Comment Aikido des SBOM que vous pouvez réellement utiliser

SBOM automatisé de la SBOM

Aikido Syft pour générer des SBOM précises et les enrichit automatiquement d'informations détaillées sur les licences et les droits d'auteur afin d'en améliorer la qualité globale.

Dépendances directes et dépendances transitives

‍L'exportation CycloneDXAikidosépare automatiquement vos dépendances directes des dépendances transitives. Cela correspond parfaitement à l'exigence Cyber Resilience Act européenne Cyber Resilience Act(EU Cyber Resilience Act) de tenir un inventaire des dépendances de premier niveau. Vous disposez ainsi d'une SBOM précise, sans avoir à retracer manuellement l'arborescence des dépendances.

Génération de SBOM en un clic, au bon format 

En un clic, Aikido génère des SBOM pour vos dépôts aux formats CycloneDX et SPDX, les deux formats privilégiés par le CRA et les directives du BSI. Cela couvre les 28 % d'organisations encore bloquées sur des formats propriétaires et l'obligation de « contenu minimal en format lisible par machine », et les exportations sont prêtes à être intégrées à votre documentation technique lorsqu'une autorité de surveillance du marché le demandera.

Consommation des SBOM, y compris les SBOM auto-déclarés

Générer votre propre SBOM ne couvre que le code que vous écrivez. Aikido vous permet également d'importer les SBOM que vous recevez de vos fournisseurs (SBOM auto-déclarés), afin que les composants tiers soient intégrés à la même surveillance des vulnérabilités que vos propres dépendances. Étant donné que 39 % des organisations ne reçoivent jamais de SBOM de leurs fournisseurs et que la plupart de celles qui en reçoivent ne peuvent pas les exploiter, disposer d'un endroit où les SBOM des fournisseurs deviennent un inventaire surveillé, continuellement mis en correspondance avec les vulnérabilités connues, comble le fossé de consommation décrit par l'ENISA.

Aikido Device Protection : une visibilité au-delà des SBOM

Les SBOM décrivent le contenu de vos produits. Mais votre surface d'attaque inclut également les machines qui construisent et écrivent ce logiciel. Le déploiement d'Aikido Device Protection sur les serveurs de build et les machines de développement étend cette même approche d'inventaire et de vulnérabilité à votre environnement de développement, couvrant les outils, runtimes et packages installés, ceux qui sont obsolètes ou vulnérables, et si l'environnement produisant vos builds « de confiance » est lui-même digne de confiance. Avec les attaques de la chaîne d’approvisionnement ciblant les pipelines CI et les postes de travail des développeurs plutôt que le code lui-même, cela comble un angle mort qu'aucun SBOM ne vous montrera jamais.

Ensemble, ces trois capacités vous permettent de savoir ce que vous livrez, ce que vous consommez et l'environnement dans lequel tout est construit. Elles fonctionnent en continu, sans ajouter un tableau de bord supplémentaire que votre équipe ignorerait. C'est une sécurité de la chaîne d'approvisionnement qui va au-delà de la simple conformité.

‍