Le SBOM (Software Bill of Materials) s’impose comme un outil de référence pour comprendre ce qui compose réellement un logiciel livré, déployé et maintenu. Là où l’on raisonnait historiquement en “produit” (une application, un service SaaS, un composant embarqué), l’industrialisation du développement a déplacé l’attention vers l’assemblage : dépendances open source, bibliothèques tierces, services externes, images conteneurisées, paquets système et dépendances transitives.

Concrètement, cela signifie qu’un logiciel est exposé non seulement à travers ce que l’on développe soi-même, mais aussi à travers tout ce que l’on y ajoute. Le SBOM donne une visibilité structurée sur cet assemblage, au service de trois objectifs : cybersécurité, conformité, maîtrise des actifs immatériels. Les textes européens récents n’imposent pas toujours “le SBOM” en tant que tel, mais renforcent les exigences de traçabilité et de gestion des risques qui en font un outil de premier plan.

 

Les points clés à retenir sur le SBOM

• Le SBOM est un inventaire structuré des composants intégrés dans un logiciel.
• Il facilite l’identification des vulnérabilités (ex. CVE) et la priorisation des correctifs.
• Il soutient la gestion des risques liés à la chaîne d’approvisionnement, notamment au regard de NIS 2.
• Il contribue à la documentation technique et à la gestion des vulnérabilités attendues par le Cyber Resilience Act.
• Il sécurise les enjeux de licences open source, de due diligence et d’engagements contractuels.
• Sa valeur augmente lorsqu’il est intégré à une stratégie de preuve (dépôt, horodatage) et, le cas échéant, de continuité (entiercement).

 

Le SBOM : définition, périmètre et enjeux techniques

Le SBOM s’inscrit dans une logique de transparence et de maîtrise de la chaîne d’approvisionnement logicielle. Pour en comprendre la portée, il convient d’en préciser la définition, les standards applicables et les implications techniques concrètes.

Définition opérationnelle du SBOM

Un SBOM peut être défini comme un enregistrement formalisé des composants utilisés pour construire un logiciel et des relations de dépendance associées. Cette définition est notamment consacrée dans les travaux américains liés à l’Executive Order 14028 et dans la doctrine de référence portée par NIST et NTIA.

Concrètement, un SBOM liste des éléments identifiables : nom du paquet, éditeur/projet, version, empreintes, licences déclarées, identifiants standards et parfois informations de provenance. Il peut couvrir plusieurs couches : dépendances applicatives (ex. npm, Maven, PyPI), dépendances système (paquets OS), et composants de déploiement (images, conteneurs). Ce degré de précision ne relève pas d’un simple formalisme documentaire : elle conditionne la capacité à répondre à une alerte de sécurité, à documenter une conformité, ou à démontrer une maîtrise de sa chaîne logicielle.

Formats et standards : SPDX, CycloneDX, et ce qu’ils changent

Le SBOM n’est pas un fichier “maison” : l’intérêt est précisément de s’appuyer sur des standards interprétables par des outils et par des tiers. Les formats les plus fréquents sont SPDX et CycloneDX, auxquels s’ajoutent des variantes ou profils selon les secteurs et les outils d’analyse.

Un choix de format n’est pas neutre. Il conditionne :

• Le niveau de détail sur les dépendances transitives,
• La capacité à exprimer des métadonnées de sécurité (hash, provenance),
• L’interopérabilité avec les outils de scan de vulnérabilités,
• La facilité d’échange avec un client, un auditeur ou une autorité.

Dans une logique de gouvernance, l’enjeu consiste moins à “produire un SBOM” qu’à produire un SBOM exploitable, cohérent avec le cycle de vie du logiciel et intégrable dans les processus de sécurité et de conformité.

Ce que le SBOM révèle vraiment : dépendances transitives, héritage et dette technique

La valeur d’un SBOM tient largement à sa capacité à exposer les dépendances transitives : composants intégrés indirectement, parfois inconnus des équipes produit, mais présents dans l’artefact livré. C’est souvent à ce niveau que se nichent les risques : versions obsolètes, bibliothèques non maintenues, modules qui tirent eux-mêmes des dépendances vulnérables.

Le SBOM permet également d’objectiver une dette de dépendances : accumulation de versions anciennes, multiplication de bibliothèques redondantes, ou dépendance forte à un composant unique. Pour une direction technique, cela nourrit une trajectoire de maintenance. Pour une direction juridique ou conformité, cela permet d’identifier les dépendances associées à des licences à obligations de réciprocité, ou de vérifier que les obligations de notices sont respectées. Le SBOM devient ainsi un point d’entrée commun entre RSSI, CTO, DSI, juristes et acheteurs.

 

SBOM et exigences réglementaires européennes : vers une obligation indirecte

Il est utile de clarifier un point : le droit de l’Union ne dit pas toujours “vous devez produire un SBOM”. En revanche, plusieurs textes structurants imposent des obligations de gestion des risques, de maîtrise de la chaîne d’approvisionnement, de documentation et de traitement des vulnérabilités. Dans ce cadre, le SBOM s’insère comme un mécanisme de preuve et d’exécution des politiques internes.

Cette approche est cohérente avec la logique européenne : fixer des objectifs et des exigences (gérer le risque, réduire l’exposition, tracer les composants, traiter les vulnérabilités), tout en laissant les organisations choisir les outils et démarches pour y parvenir. Le SBOM n’est donc pas une case à cocher ; il s’analyse comme un instrument de gouvernance aligné sur des obligations déjà présentes, dont l’intensité varie selon le secteur, le produit et le niveau de risque.

Directive NIS 2 : gestion des risques et chaîne d’approvisionnement

La directive NIS 2 (directive (UE) 2022/2555) renforce les mesures de gestion des risques de cybersécurité attendues des entités concernées. Elle vise notamment la gestion des risques liés à la chaîne d’approvisionnement et la sécurisation des systèmes au travers d’une approche par les risques.

Dans une organisation soumise à NIS 2 (directement ou via exigences contractuelles), la question devient : comment démontrer que l’on connaît ses composants, que l’on sait repérer une exposition, et que l’on sait remédier ?

Le SBOM apporte une réponse méthodologique :

• cartographie,
• corrélation avec les vulnérabilités,
• priorisation,
• traçabilité de la remédiation.

Les guides de mise en œuvre et l’écosystème de conformité autour de NIS 2 soulignent l’importance de mesures opérationnelles et vérifiables, ce que permet un SBOM maintenu dans le temps.

Cyber Resilience Act : documentation technique et gestion des vulnérabilités

Le Cyber Resilience Act (règlement (UE) 2024/2847) établit des exigences de cybersécurité pour les produits comportant des éléments numériques, avec une attention particulière portée à la sécurité dès la conception et à la gestion des vulnérabilités sur la durée de support.

Dans cette logique, le SBOM constitue un support naturel de documentation : il décrit les composants intégrés et facilite l’analyse d’exposition lorsqu’une vulnérabilité est divulguée. Il contribue également à la gestion des mises à jour et à la transparence attendue par les utilisateurs et les clients professionnels, notamment lorsque des périodes de support et des correctifs doivent être organisés et documentés. L’enjeu n’est pas seulement technique : c’est une question de responsabilité produit, de capacité à gérer les alertes et à démontrer que l’on maîtrise son assemblage logiciel.

DORA : supervision des prestataires TIC et auditabilité

Le règlement DORA (règlement (UE) 2022/2554) organise la résilience opérationnelle numérique du secteur financier, notamment au travers d’exigences encadrant la relation avec les prestataires TIC et les dispositions contractuelles.

Même si DORA ne prescrit pas explicitement “un SBOM”, la dynamique de conformité pousse à renforcer la visibilité sur les dépendances et sur les composants qui soutiennent des fonctions sensibles. Pour un prestataire TIC travaillant avec des entités financières, fournir un SBOM (ou un équivalent structuré) devient un signal de maturité : capacité à documenter l’architecture logicielle, à qualifier des dépendances, à accélérer une analyse en cas d’incident, et à soutenir des démarches d’auditabilité. Dans les négociations contractuelles, cette transparence peut être déterminante pour démontrer l’alignement opérationnel entre engagements de sécurité et réalité technique.

 

SBOM et propriété intellectuelle : un outil de maîtrise des actifs logiciels

Au-delà de la cybersécurité, le SBOM constitue un outil de pilotage des droits et actifs logiciels : il distingue les développements internes des composants tiers et open source, et permet d’identifier les obligations juridiques associées (licences, redistribution, documentation).

Gouverner les licences open source : de la conformité à la sécurisation contractuelle

L’intégration de composants open source est devenue une norme. Le risque ne réside pas dans l’open source en soi, mais dans l’absence de gouvernance : méconnaissance des licences, dépendances introduites sans validation, obligations de notices non respectées, ou incompatibilités entre licences et modèle de distribution.

Le SBOM permet d’identifier et d’agréger les informations de licence par composant. Il soutient une politique interne : validation des dépendances, règles d’acceptation (ex. interdiction de certaines licences dans certains produits), gestion des obligations de redistribution, et documentation destinée aux clients. Dans le cadre d’appels d’offres ou de contrats B2B, la capacité à produire un SBOM et une synthèse de conformité open source permet également de limiter les frictions : la discussion ne porte plus sur des déclarations générales, mais sur une cartographie vérifiable.

Due diligence technologique : de l’inventaire à l’évaluation du risque

Lors d’une due diligence (acquisition, partenariat structurant, levée de fonds, transfert d’actifs), le SBOM apporte un niveau d’objectivation rarement atteint par une simple revue documentaire. Il aide à répondre à des questions centrales :

• dépendance à quelques briques tierces,
• présence de composants non maintenus,
• exposition potentielle à des vulnérabilités connues,
• alignement des licences avec la stratégie de commercialisation.

Il permet aussi de mieux qualifier la valeur d’un actif logiciel : un produit dont la chaîne de dépendances est maîtrisée, mise à jour, et documentée est plus facile à maintenir, à intégrer et à auditer. À l’inverse, l’absence de visibilité sur les composants introduit une incertitude technique et juridique qui se traduit souvent en renégociations, garanties renforcées, ou mécanismes d’ajustement de prix.

Dans le cadre de ces audits, certains acteurs spécialisés en due diligence technologique, comme notre partenaire Vaultinum, proposent des dispositifs permettant de générer un SBOM, accompagné d’un rapport explicatif au format PDF destiné aux parties prenantes non techniques (direction générale, investisseurs, juristes, conseils).

SBOM, preuve et titularité : articuler traçabilité technique et stratégie probatoire

Le SBOM distingue ce qui relève des composants internes et ce qui relève de composants externes. Cette distinction est utile pour piloter la titularité, la réutilisation et la stratégie de protection. Toutefois, le SBOM ne remplace pas une stratégie probatoire : il décrit, mais ne confère pas une preuve d’antériorité ou de paternité sur les développements internes.

Dans une logique de protection des actifs numériques, il est pertinent d’articuler SBOM et dispositifs probatoires : dépôt et horodatage de versions significatives, dépôts de documentation technique associée, et conservation des éléments permettant de démontrer une chronologie de développement. C’est typiquement dans ce type d’articulation qu’un tiers de confiance, comme l’Agence pour la Protection des Programmes, intervient : sécuriser la preuve des actifs logiciels (code source, documentation, versions) et soutenir la gouvernance interne lors d’un audit, d’un contentieux ou d’une négociation.

 

Contrats, achats, et exigences clients : le SBOM comme clause de transparence

À mesure que les exigences de cybersécurité et de conformité s’intensifient dans les entreprises, le SBOM tend à quitter la seule sphère technique pour devenir un objet contractuel.

Le SBOM comme exigence client dans les contrats B2B

Côté clients, le SBOM peut être demandé pour : vérifier l’absence de composants interdits, qualifier les risques liés à la software supply chain, ou organiser des procédures de notification en cas de vulnérabilité affectant un composant intégré.

Dans certains secteurs très surveillés et soumis à une réglementation contraignante (finance, santé, défense, infrastructures critiques), le SBOM permet d’objectiver la composition logicielle du produit livré et d’encadrer les obligations de transparence.

Encadrer clairement l’usage du SBOM dans le contrat

Côté fournisseurs, le SBOM doit faire l’objet d’un encadrement précis : déterminer quels livrables sont concernés, à quelle fréquence il est mis à jour, quel périmètre il couvre (produit, module, image conteneurisée) et dans quelles conditions il peut être utilisé ou communiqué (confidentialité, non-divulgation, responsabilité).

Sans cet encadrement, le SBOM peut être perçu à tort comme une garantie d’absence de vulnérabilités. Or, il s’agit d’un inventaire destiné à faciliter la gestion des risques, non d’une assurance contre ceux-ci.

 

SBOM et offre APP : un inventaire technique et un rapport explicatif

Au-delà de la production d’un inventaire technique, la valeur du SBOM réside dans sa capacité à être compris, exploité et intégré dans une stratégie de gouvernance des actifs logiciels. C’est précisément sur ce point que se distingue l’approche de l’APP.

Une génération de SBOM intégrée aux dépôts

L’Agence pour la Protection des Programmes propose désormais, en option dans le cadre de ses dépôts (standards, vérifiés et contrôlés), une prestation de génération de SBOM.

Cette offre permet aux éditeurs de logiciels et à leurs clients d’obtenir :

• un fichier SBOM au format JSON, conforme aux standards du marché ;
• un rapport complémentaire au format PDF pour rendre le livrable exploitable et compréhensible pour tous.

Le SBOM ainsi généré s’inscrit dans une logique de sécurisation et de réassurance : il accompagne le dépôt horodaté du code source et contribue à renforcer la valorisation de l’actif logiciel.

Un rapport PDF explicatif à destination des parties prenantes non techniques

La principale valeur ajoutée de l’offre APP réside dans la production d’un rapport explicatif au format PDF, conçu pour être lisible par des interlocuteurs non techniques (direction générale, investisseurs, juristes, partenaires commerciaux).

Contrairement à certaines solutions concurrentes, parfois gratuites mais compréhensibles uniquement par les équipes IT, l’APP fournit un document synthétique présentant :

• Les composants logiciels utilisés,
• Les licences associées,
• Les CVE (failles de vulnérabilité).

Ce document permet au client d’obtenir une vision claire et sécurisée de la composition de son code, et peut servir à faire valoir la qualité de l’actif auprès de tiers clients ou partenaires.

Modalités pratiques et transmission sécurisée

Les deux livrables — SBOM en JSON et rapport explicatif en PDF — peuvent être transmis par voie électronique. Leur poids, après compression, demeure inférieur à 1 Mo, ce qui facilite leur envoi sécurisé par courriel dans le cadre d’un audit, d’une négociation contractuelle ou d’une opération stratégique.

L’offre SBOM s’inscrit en complément des dispositifs historiques de l’APP :

• dépôt probatoire horodaté des versions de code et de documentation ;
• entiercement logiciel, notamment en contexte B2B ou SaaS, pour organiser la continuité d’activité si le fournisseur n’est plus en mesure d’assurer la maintenance ou l’accès, en cohérence avec les engagements contractuels.

Le SBOM ne constitue pas en soi un mécanisme probatoire. Il complète un dispositif global de protection, de traçabilité et de valorisation des actifs logiciels.

Pour toute information complémentaire sur l’option SBOM intégrée aux dépôts vérifiés et contrôlés, contactez les équipes de l’APP afin d’étudier votre situation et vos besoins spécifiques.