Le problème du SBOM n’est pas l’inventaire. C’est votre capacité à prouver votre innocence.

Il existe une forme de panique très particulière dans les entreprises de produits connectés quand un journaliste, un régulateur ou un client pose une question simple : « Que fait ce logiciel dans votre produit ? »

Pas « ce que vous pensez qu’il fait », ni « ce que votre fournisseur vous a dit ». Ce qu’il fait, point.

Dès que le soupçon s’installe, vos intentions ne comptent plus. Seules les preuves comptent. C’est pourquoi la phrase la plus dangereuse dans une entreprise hardware connectée est : « On pense que ça va. »

L’histoire récente sur un logiciel associé à un spyware apparaissant sur une liste de licences d’un constructeur chinois de véhicules électriques est un bon déclencheur pour se rappeler une vérité inconfortable : vous pouvez vous retrouver, du jour au lendemain, au cœur d’un récit de sécurité nationale même si vous n’avez livré aucun code malveillant. Si vous ne pouvez pas démonter l’histoire rapidement, vous avez déjà perdu la première manche.

Un SBOM est nécessaire, mais il ne suffit pas. Un tableur de composants ne vous sauvera pas quand la pression monte. Ce qui vous protège, c’est une gouvernance qui relie trois éléments en un système défendable : l’hygiène des licences, les limites de télémétrie et les droits d’audit.

C’est le playbook que j’aimerais voir adopté par toute entreprise de produits connectés avant le premier scandale, pas après.

1) Traiter le SBOM comme un système de preuve, pas comme un livrable de conformité

La plupart des équipes abordent le SBOM comme un inventaire. Elles veulent une liste. Elles veulent un outil qui sort une liste. Elles veulent cocher la case.

Cette approche échoue parce que, sous scrutiny, la vraie question n’est pas « quelles librairies existent », mais « que peut faire ce produit, et qui peut le modifier ». Un SBOM incapable de répondre à ces questions, sous contrainte de temps, relève du théâtre.

Définissez donc votre résultat SBOM comme suit :

• Je peux relier chaque binaire livré à une source, une licence, un responsable et une build pipeline.
• Je peux relier chaque flux de données à un objectif explicite et à une politique de conservation.
• Je peux démontrer qui a l’autorité de mise à jour, comment les mises à jour sont signées, et comment je couperais un canal de mise à jour si nécessaire.

Si vous ne savez pas faire ces trois choses, vous n’avez pas un programme SBOM. Vous avez un fichier.

2) Gouvernance des licences : rendre impossible l’expédition d’un « composant inconnu »

Les listes de licences deviennent publiques de manière chaotique : questionnaires achats, revues sécurité chez les clients, audits de partenaires, parfois des fuites. Rien ne crée plus vite le soupçon que de publier une liste dont certains éléments paraissent inconnus, génériques ou incohérents avec la fonction du produit.

La solution n’est pas une meilleure ligne de communication. C’est un meilleur dispositif d’entrée et d’approbation.

Mettre en place trois verrous, et les garder simples

1. Verrou d’entrée (avant que le code n’arrive). Aucun composant tiers n’entre dans le repo sans un minimum d’informations : nom, version, origine, type de licence, usage dans le produit et responsable interne.
2. Verrou de build (avant l’existence des artefacts). La CI échoue si le composant manque au manifest, s’il a une classe de licence non approuvée ou s’il provient de registres sources non autorisés.
3. Verrou de release (avant exposition aux clients). Le release candidate doit inclure un instantané SBOM signé, stocké avec les outputs de build. Pas « généré plus tard ». Rattaché à ce build.

Deux règles pratiques évitent que tout cela ne s’essouffle :

• Rendre la responsabilité explicite. Chaque dépendance a une personne comptable. Pas un nom d’équipe. Une personne.
• Interdire la « gouvernance au presse-papiers ». Si les approbations vivent dans les e-mails et les réunions, vous échouerez lors d’un incident. Mettez les approbations dans le même système que les changements de code.

C’est aussi là que vous stoppez la dérive lente des outils « temporaires ». L’outil introduit pour un test rapide reste pour toujours, finit sur une liste de licences, puis devient un titre de presse.

3) Limites de télémétrie : décider de ce que vous ne collecterez jamais

La télémétrie est l’accélérant silencieux de toute crise de confiance. Beaucoup de produits connectés seraient défendables si le chemin de données était étroit. Ils deviennent indéfendables quand le « diagnostic » se transforme en collecte large par simple commodité.

Il vous faut une constitution de télémétrie. Pas une politique de confidentialité écrite en comité, mais des limites nettes que les ingénieurs peuvent implémenter.

Quatre décisions à verrouiller ce trimestre

• Finalité. Pour chaque événement de télémétrie, écrivez la raison en une phrase. Si vous ne pouvez pas l’exprimer simplement, supprimez-le.
• Minimisation. Collectez le niveau de granularité le plus faible qui résout encore le problème. Les comptes agrégés valent mieux que les flux bruts. Le traitement on-device vaut mieux que des copies dans le cloud.
• Conservation. Décidez combien de temps vous gardez les données, et automatisez la suppression. Si la suppression est manuelle, elle ne se fera pas.
• Séparation. Isolez analytics produit, diagnostics et logs de sécurité dans des compartiments distincts, avec des règles d’accès distinctes. Les mélanger, c’est transformer des données « utiles » en passif.

La limite la plus importante est celle-ci : séparer ce dont le produit a besoin pour fonctionner de ce que l’entreprise aimerait savoir. Quand vous mélangez les deux, vous finissez par défendre une curiosité marketing comme une « opération essentielle ». Personne n’y croit.

Et oui, cela touche aussi à la géopolitique. Si vous vendez au-delà des frontières, votre design de télémétrie doit anticiper l’interprétation la plus dure. Si un régulateur part du pire, pouvez-vous quand même montrer un chemin de données suffisamment étroit pour rendre ce pire peu crédible ?

4) Droits d’audit : vos contrats fournisseurs doivent tenir quand le soupçon tombe

La plupart des entreprises hardware sont des écosystèmes : modules, firmware, piles de connectivité, SDK mobiles, services cloud. Quand le soupçon tombe, le maillon faible est rarement votre code. C’est ce que vous avez intégré parce que « ça marchait » et que « ça venait d’un fournisseur réputé ».

En crise, la réputation n’est pas une preuve. Les droits contractuels, si.

Mettre ces clauses en place avant signature

• Droit d’inspection. Pas une vague « coopération sécurité ». Un droit défini d’inspecter les parties pertinentes de la supply chain logicielle, y compris la provenance des builds et les listes de dépendances.
• Droit à des tests indépendants. Vous pouvez mandater des tests de sécurité tiers sur les artefacts livrés et les intégrations, sans violation des conditions.
• Contrôle et notification des mises à jour. Vous êtes notifié des changements, vous pouvez différer ou bloquer des mises à jour, et vous pouvez exiger signature et attestation pour les updates.
• Coopération en incident avec délais. Délais de réponse, chemins d’escalade nommés, et accès aux équipes techniques pendant l’investigation.
• Géographie et limites de traitement des données. Le lieu de traitement des données et les personnes pouvant y accéder doivent être explicités contractuellement, pas supposés.

Sans ces droits, vous ne pouvez pas enquêter au rythme des gros titres. Vous attendrez des validations pendant que l’histoire s’écrit sans vous.

5) La leçon du terrain : le soupçon va plus vite que votre processus de release

J’ai vu des équipes de produits connectés construire une excellente discipline d’ingénierie, puis perdre des semaines parce qu’un seul composant ne pouvait pas être expliqué proprement, de bout en bout, entre firmware, cloud et mobile. Pas parce qu’il était malveillant, mais parce que personne n’avait une responsabilité de bout en bout sur « ce qui est exactement dans cette release » et « ce qui sort exactement de l’appareil ».

Dans ces moments-là, le travail technique n’est pas le plus difficile. Le plus difficile, c’est de formuler, sous pression, une affirmation cohérente et falsifiable, puis de l’étayer avec des artefacts auxquels des tiers peuvent faire confiance.

C’est pour cela que le SBOM ne peut pas être relégué à une personne sécurité équipée d’un outil. C’est un accord transverse entre produit, engineering, juridique, et les équipes qui pilotent les relations commerciales. Vous construisez un système capable de répondre à des questions hostiles avec une précision calme.

Quand votre produit est accusé d’espionner, votre avantage n’est pas l’indignation. Votre avantage, c’est une chaîne de traçabilité propre pour le logiciel et les données.

Tout cela recoupe directement votre manière de penser la souveraineté et le contrôle. Si vous traitez la souveraineté comme un achat, vous changez de fournisseurs tout en conservant les mêmes angles morts. Le vrai basculement est procédural et contractuel. J’ai développé cette idée dans Sovereign Compute Isn’t a Purchase. It’s an Operating Model.

Que faire ensuite : un sprint de préparation SBOM en 30 jours

Si vous voulez que ce soit réel en un mois, et pas « un programme », lancez un sprint avec un seul objectif : prendre un produit déjà livré et le rendre démontrable.

1. Choisir le produit et cadrer le périmètre. Firmware de l’appareil, application mobile, services cloud, pipeline CI et les cinq principaux fournisseurs. Restez serré.
2. Produire un instantané SBOM de référence. Pour chaque artefact livré. Stockez-le avec les outputs de build. Rendez-le récupérable en quelques minutes.
3. Red-teamer votre propre récit. Posez la question : si un journaliste affirmait que ce composant est un spyware, que montrerions-nous en 24 heures pour le réfuter ?
4. Verrouiller les limites de télémétrie. Écrivez le catalogue d’événements. Supprimez tout ce qui n’a pas de finalité en une ligne. Ajoutez des durées de conservation par défaut.
5. Corriger les contrats là où c’est critique. Commencez par le fournisseur dont vous comprenez le moins le code, et dont vous dépendez le plus.
6. Faire un exercice d’incident. Simulez un scénario « découverte d’un composant suspect ». Cadrez la réponse dans le temps. Mesurez le temps nécessaire pour produire des preuves, pas des opinions.

Si l’exercice montre que vous ne pouvez pas répondre vite, c’est une bonne nouvelle : vous avez trouvé la faille avant le public.

Ma conviction : la confiance est une fonctionnalité produit, et elle doit compiler

Les récits de sécurité nationale n’attendent pas votre alignement interne. Ils comblent le vide que vous laissez quand vous ne pouvez pas prouver ce qui est dans votre produit et ce que fait votre produit.

Donc construisez la preuve tôt. Rendez les composants inconnus inlivrables. Décidez ce que vous ne collecterez jamais. Inscrivez des droits d’audit dans les contrats avant d’en avoir besoin. Puis répétez le jour où tout se complique, parce que ce jour-là arrivera pour quelqu’un dans votre catégorie.

Si vous le faites bien, le SBOM n’est pas un livrable bureaucratique. C’est un avantage compétitif : vous livrez plus vite avec moins de peur, vous répondez aux revues sécurité des entreprises avec clarté, et vous ne vous retrouvez pas prisonnier d’une histoire que vous ne pouvez pas réfuter.