Linux embarqué : demander et réceptionner une SBOM exploitable

Le problème à résoudre lors d’une livraison externalisée

Ce guide s’adresse au responsable technique qui réceptionne une carte ou une passerelle sous Linux embarqué développée avec un prestataire. L’équipement démarre et les fonctions convenues répondent, mais une question reste ouverte : quels composants logiciels sont réellement présents dans la version remise au client ? Sans réponse exploitable, une future alerte de sécurité peut déclencher une recherche manuelle dans plusieurs dépôts et échanges de fichiers.

L’objectif est de préparer un livrable vérifiable avant la recette, puis utilisable par l’équipe de maintenance. Il ne s’agit pas d’un tutoriel complet de construction Yocto ni d’une certification de conformité. Les recommandations supposent que le client puisse identifier la version livrée, désigner un responsable de réception et obtenir les informations convenues auprès du fournisseur. Si ces prérequis manquent, commencez par les clarifier plutôt que par choisir un format de fichier.

Définir le périmètre avant de choisir l’outil

Une SBOM, ou nomenclature logicielle, décrit des composants logiciels et leurs relations selon le format utilisé. Dans la documentation Yocto 5.0.12, la génération s’appuie sur SPDX et peut inclure les composants, licences, dépendances et informations de sources associés à la construction. Cette capacité ne dispense pas de définir le périmètre attendu pour le produit réellement livré. Yocto 5.0.12 : SBOM

Pour la consultation, distinguez l’image système, l’application métier, les logiciels de démarrage, les logiciels des périphériques et les éléments ajoutés après construction. Demandez au fournisseur lesquels entrent dans son inventaire et lesquels nécessitent un complément. Une liste d’exclusions explicite est plus utile qu’une promesse d’exhaustivité dont personne ne connaît les limites.

Précisez aussi ce qui n’appartient pas au livrable : par exemple un service hébergé séparément ou un logiciel de développement utilisé uniquement sur un poste. Ces éléments peuvent avoir leur propre inventaire, mais les mélanger sans indication avec le contenu installé rend la lecture ambiguë. Le périmètre doit permettre à deux équipes de répondre de la même façon à la question : cette version du produit contient-elle ce composant ?

Relier l’inventaire à l’image effectivement réceptionnée

Proposez un bordereau de livraison qui associe l’identifiant du produit, sa variante matérielle, la version du logiciel, le nom de l’image et son empreinte cryptographique. Ajoutez le nom et l’empreinte du fichier SBOM ainsi que la référence du processus de construction. Ce bordereau constitue une proposition de gestion de configuration ; il ne remplace pas les exigences contractuelles propres au projet.

L’empreinte aide à vérifier que deux fichiers sont identiques. Elle ne prouve pas que leur contenu est correct ni que leur origine est fiable. L’identité du fournisseur et le canal de livraison doivent donc être établis séparément. Une signature, lorsqu’elle est prévue par le projet, doit être vérifiée avec une clé dont la confiance est déjà définie ; ajouter une signature sans organiser cette confiance ne résout pas la question.

Refusez une correspondance fondée seulement sur un nom comme version-finale. Si l’image est reconstruite ou modifiée après génération de la SBOM, demandez comment le lien entre les deux est rétabli. Le résultat attendu est une association non ambiguë entre les fichiers reçus, leur version et la décision de recette, conservée dans un emplacement accessible à la maintenance.

Ce que l’on peut demander dans un projet Yocto

Pour un projet utilisant précisément Yocto 5.0.12, le manuel indique l’activation de create-spdx dans la configuration et décrit une archive SPDX associée à l’image. Il documente également des options pour inclure davantage d’informations sur les sources ou les paquets. Ces indications sont liées à cette version : vérifiez le manuel de la branche réellement employée avant de reprendre une commande ou de fixer un nom de fichier attendu. Yocto 5.0.12 : SBOM

Dans le cahier des charges, demandez la version de Yocto, les couches et révisions nécessaires à la construction ainsi que les options retenues pour la génération. N’imposez pas aveuglément une archive de toutes les sources si le besoin est d’abord un inventaire des composants installés. À l’inverse, un simple inventaire ne remplace pas un dossier de sources lorsque celui-ci est requis pour la reprise technique ou pour traiter les obligations de licence.

Préparez une vérification sur un échantillon choisi à l’avance : un composant système, l’application propre au produit et un élément fourni séparément, s’il existe. Pour chacun, demandez où se trouve l’information attendue et comment elle rejoint le logiciel installé. Cette vérification ne mesure pas une couverture globale, mais elle permet de détecter une incompréhension du périmètre avant d’accepter le dossier entier.

Traiter les ajouts manuels et les composants externes

Un fichier ajouté après la construction, un paquet installé au premier démarrage ou un micrologiciel chargé dans un module doit faire l’objet d’une décision explicite. L’équipe doit expliquer si cet élément est couvert par la génération, par un document fournisseur distinct ou par une entrée complémentaire. Ne supposez pas que l’outil connaît automatiquement toutes les étapes de fabrication et de configuration du produit.

Pour un composant propriétaire dont le détail n’est pas disponible, demandez au minimum l’identité vérifiable de l’artefact fourni et la limite de visibilité. Il faut conserver la distinction entre un composant identifié et un composant dont toutes les dépendances sont connues. Une valeur inconnue ne doit pas être remplacée par une version supposée pour faire disparaître un avertissement.

Si plusieurs variantes du produit ont des logiciels différents, convenez d’un inventaire par variante ou d’une règle permettant de retrouver sans ambiguïté le bon sous-ensemble. Un inventaire commun peut être pratique, mais seulement si la sélection est documentée. Sinon, la maintenance risque d’analyser une alerte pour un composant absent de l’équipement concerné ou d’en oublier un qui est réellement installé.

Séparer inventaire, licences et analyse de vulnérabilités

La SBOM fournit des informations utiles à d’autres analyses ; elle n’en constitue pas automatiquement le résultat. Le manuel Yocto 5.0.12 décrit séparément cve-check, qui rapproche les informations de recettes et de versions de données CVE et produit des états tels que Patched, Unpatched ou Ignored. Ces états doivent être interprétés dans le contexte du produit et des justifications disponibles. Yocto 5.0.12 : CVE

Demandez donc une livraison distincte pour les décisions de sécurité : problème examiné, version concernée, justification, mesure retenue et responsable de suivi. Le nombre d’alertes d’un outil n’est pas, à lui seul, une mesure de sécurité du produit. Une absence d’alerte ne permet pas de conclure qu’aucune vulnérabilité n’existe ; une correspondance automatique nécessite également une analyse.

Pour les licences, le manuel Yocto explique notamment le suivi des changements de textes avec LIC_FILES_CHKSUM. Ce contrôle technique n’équivaut pas à une validation juridique de l’ensemble du produit. Yocto 5.0.12 : licences Faites préciser qui examine les obligations applicables, qui rassemble les documents à distribuer et qui traite les exceptions. Le présent guide organise les questions de livraison ; il ne fournit pas de conclusion juridique sur une licence particulière.

Exemple hypothétique de recette d’une passerelle

Prenons un exemple fictif, sans lien avec un projet client : une passerelle comprend une image Linux construite avec Yocto, une application de collecte et un micrologiciel fourni avec un module radio. Le client reçoit l’image A, la SBOM S et un document fournisseur R pour le module. Le bordereau doit expliquer si S inclut le module ou renvoie à R, et identifier la version de R utilisée.

Lors de la réception, le client constate que S correspond à une construction antérieure à l’ajout de l’application de collecte. Même si l’équipement fonctionne, le dossier documentaire n’est pas cohérent. L’action proposée est de suspendre l’acceptation de ce livrable, demander une génération ou un complément conforme au périmètre convenu, puis refaire les contrôles concernés. Ce n’est pas une raison pour inventer une entrée à partir d’un nom de fichier.

Après correction, le procès-verbal conserve les références des fichiers, les points examinés et les limites restantes. Si le module reste opaque, cette limite demeure visible avec son responsable de suivi. L’exemple illustre une méthode de décision, sans prétendre démontrer une couverture de sécurité, un gain de temps mesuré ou un résultat commercial.

Organiser la maintenance et les coûts de travail

Avant la commande, demandez ce qui déclenche une nouvelle SBOM : nouvelle image, ajout de paquet, changement de variante ou modification d’un composant livré séparément. Définissez qui la produit, qui la réceptionne et où les versions précédentes sont conservées. Une procédure limitée à la première livraison laisse la maintenance sans référence dès que le logiciel évolue.

Les postes de travail à discuter comprennent l’intégration de la génération au processus existant, la collecte d’informations externes, la qualification des exclusions, les contrôles de cohérence et le suivi des versions. Ce sont des facteurs de charge, pas un tarif universel. Un devis utile distingue la mise en place initiale et les opérations récurrentes, avec les entrées attendues du client et les éléments hors périmètre.

Lorsque le fournisseur ne peut pas documenter la correspondance avec l’image livrée, ou lorsque les exclusions rendent l’inventaire inutilisable pour la question visée, ne validez pas le dossier par défaut. Réduisez d’abord l’ambiguïté : périmètre plus précis, complément ciblé ou étape de reprise documentaire. L’achat d’un nouvel outil ne remplace pas cette décision d’organisation.

Conclusion : réceptionner une correspondance, pas seulement un fichier

La décision de recette doit porter sur un ensemble cohérent : logiciel livré, inventaire, périmètre et méthode de mise à jour. Commencez par ce que votre équipe doit pouvoir vérifier, puis demandez au prestataire de montrer comment ses livrables permettent cette vérification. Conservez les inconnues et les exclusions au lieu de les masquer dans un résultat globalement positif.

Pour préparer une demande d’accompagnement en Linux embarqué, rassemblez la branche de construction utilisée, les variantes de carte, la liste des éléments ajoutés hors construction et votre organisation de maintenance. Ces informations permettent de discuter d’un périmètre technique concret. Elles ne constituent pas une promesse de conformité, d’exhaustivité ou de délai de la part d’InnovChip.

Questions fréquentes

Faut-il demander SPDX ou un autre format ?

Choisissez un format que les outils du fournisseur peuvent produire et que votre équipe peut exploiter. Avant de décider, demandez un exemple de fichier, sa version de format et une démonstration de lecture. L’interopérabilité concrète et le périmètre couvert comptent davantage qu’un nom de format ajouté au contrat sans essai.

Une SBOM suffit-elle pour reconstruire le logiciel ?

Non. La reconstruction nécessite aussi les sources, configurations, outils et dépendances appropriés au projet. Demandez un dossier de reconstruction séparé si la reprise par une autre équipe est un objectif. La présence de références de sources dans un inventaire ne démontre pas que ces sources sont disponibles et suffisantes.

Peut-on accepter provisoirement un composant non documenté ?

La décision dépend de l’usage attendu et du risque du projet. Formalisez ce qui manque, les fonctions concernées, le responsable et la condition de clôture. Si cette inconnue empêche la vérification demandée, la recette correspondante reste ouverte ; ne la présentez pas comme une validation complète.

Comment gérer une modification urgente après livraison ?

Prévoyez une procédure qui relie la modification à la nouvelle image et à la mise à jour de l’inventaire. Si le dossier suit avec un décalage accepté, rendez ce décalage visible et attribuez une responsabilité. Une correction urgente ne doit pas rendre durablement impossible l’identification du logiciel réellement déployé.

Le fournisseur doit-il communiquer tous ses outils internes ?

Pas nécessairement. Il faut convenir des informations nécessaires pour comprendre, contrôler et, si prévu, reproduire le livrable. Distinguez les détails internes sans effet sur la réception et les paramètres indispensables à la correspondance entre image et inventaire. Les droits d’accès et de remise doivent être clarifiés avec les parties concernées.

Peut-on annoncer que le produit est sécurisé après cette recette ?

La recette documentaire ne permet pas cette conclusion générale. Elle fournit une base pour identifier les composants et organiser des analyses. La sécurité dépend également de la configuration, de l’exposition, des correctifs, des essais et de la maintenance du produit ; ces sujets demandent leurs propres critères et preuves.