Pourquoi les scanners SBOM ratent le contenu des builds Yocto

En quoi un build Yocto diffère de ce qu'attendent les scanners

Un build Yocto n'est pas une installation par gestionnaire de paquets. L'essentiel de ce qui arrive sur l'appareil est décidé au moment du build, dans BitBake, en cinq couches. Les scanners examinent une couche après coup et doivent deviner le reste.

1. L'hôte de build

BitBake s'exécute avec les outils de la machine de build. La variable HOSTTOOLS liste les outils de l'hôte de build que les tâches de build peuvent appeler, et le système de build crée des liens symboliques vers eux dans ${TMPDIR}/hosttools. BitBake construit aussi ses propres outils via des recettes -native et -cross. Les outils de l'hôte influencent l'image et, par conception, n'en font pas partie.

2. Récupération

Les recettes désignent leurs sources dans SRC_URI, et le fetcher les télécharge dans DL_DIR. Il cherche d'abord dans DL_DIR, puis dans PREMIRRORS, puis en upstream, puis dans MIRRORS. Les crates Rust passent par le fetcher crate://, listées dans un fichier -crates.inc que cargo-update-recipe-crates génère à partir de Cargo.lock. Les modules Go passent par la classe go-mod ou sont vendorés avec go-vendor. BB_NO_NETWORK et BB_ALLOWED_NETWORKS contrôlent ce que le fetcher peut atteindre.

3. Recettes et patches

Chaque recette fixe une version upstream dans PV et applique des patches par-dessus. Un patch dont l'en-tête contient une ligne CVE: marque cette CVE comme corrigée. Le numéro de version reste celui de l'upstream : la recette peut donc être corrigée alors que sa version dit le contraire.

4. Code compilé

Les bibliothèques statiques (les paquets -staticdev), les crates Rust et les modules Go finissent dans les binaires qui les utilisent. Le noyau et ses modules sont construits à partir d'une configuration propre au produit : deux plateformes sur la même version du noyau contiennent donc du code différent.

5. L'image

Le système de fichiers racine. La fonctionnalité d'image package-management installe les outils de gestion des paquets et conserve la base de données du gestionnaire de paquets. Sans elle, les fichiers de données du gestionnaire de paquets sont supprimés du système de fichiers racine, ce qui est courant sur les images de production.

Le cache shared state (sstate), ou cache d'état partagé

BitBake peut restaurer la sortie d'une tâche depuis le cache sstate au lieu de l'exécuter. Le manuel de présentation de Yocto le dit clairement : si les objets précompilés sont disponibles, le compilateur n'est pas nécessaire, « ainsi, le compilateur n'est même pas téléchargé ». Les tâches restaurées depuis sstate sautent les étapes fetch, compile et install, ce qui compte pour tout outil qui repose sur l'observation de ces étapes. Plus de détails dans la section sur les caches ci-dessous.

Pourquoi les scanners d'images et de systèmes de fichiers en ratent l'essentiel

• Pas de base de données des paquets. Une image de production construite sans package-management ne donne aucune liste à lire au scanner, qui se rabat sur des heuristiques de fichiers ou ne signale presque rien. Le résultat paraît complet et il est presque vide.
• Code statique et vendoré. Une bibliothèque statique ou une crate compilée dans /usr/bin/foo ne laisse aucune trace de paquet. librsvg en est un exemple : la recette oe-core actuelle liste plus de 350 crates Rust, et sur l'appareil, c'est une seule bibliothèque partagée.
• Hôte de build et outils récupérés. Ils ne sont jamais dans l'image, donc jamais dans un scan d'image, alors qu'un outil de l'hôte ou une GitHub Action compromis peut compromettre l'image. La backdoor de xz utils (CVE-2024-3094) est entrée dans la bibliothèque pendant sa construction, à partir des tarballs de release et non du dépôt Git. En mars 2025, la CISA a signalé que toutes les versions de la GitHub Action tj-actions/changed-files avaient été compromises pendant trois jours.
• Patches appliqués. L'image indique openssl dans une version upstream. La recette a appliqué le correctif d'une CVE qui touche cette version et a marqué le patch avec CVE:. Une comparaison par plages de versions la signale quand même. C'est la forme Yocto du problème des backports des distributions, et l'une des principales sources du bruit traité dans comment réduire le bruit des vulnérabilités.

Le total est un mélange de composants manquants et de résultats erronés, et rien dans le résultat ne vous dit lesquels sont lesquels. Le même argument vaut pour les conteneurs dans les SBOM d'images Docker et pour les projets de langage dans les générateurs de SBOM open source.

Pourquoi l'analyse binaire du firmware doit deviner

L'analyse binaire compare les chaînes, les symboles et les signatures de code du firmware extrait à des composants connus, puis en déduit les versions. Là où le binaire porte des indices clairs, cela fonctionne. Dans une image Yocto, elle doit souvent deviner :

• binaires strippés sans chaînes de version ;
• code lié statiquement, où les frontières entre bibliothèques ont disparu ;
• Rust compilé, où les frontières entre crates disparaissent dans un seul exécutable ;
• patches rétroportés, invisibles dans un numéro de version ;
• code du noyau que la configuration a inclus ou exclu à la compilation.

L'analyse binaire est le bon outil pour un firmware que vous n'avez pas construit : des blobs de fournisseurs, des modules achetés, un appareil que vous évaluez. Si vous n'avez pas le build, analyser le binaire est la seule option. La règle de décision est simple : si vous le construisez, enregistrez-le ; si vous ne faites que le recevoir, analysez-le et demandez au fournisseur une SBOM issue de son build.

Ce que les outils SBOM et CVE de Yocto font bien

Le travail du Yocto Project sur les SBOM est de l'ingénierie de qualité, et il sait des choses qu'aucun outil extérieur ne peut savoir. Sa documentation décrit la SBOM comme « une description de tous les composants que vous avez utilisés, de leurs licences, de leurs dépendances, de leurs sources, des modifications qui leur ont été appliquées et des vulnérabilités connues qui ont été corrigées ».

create-spdx selon la release

• 4.3 (Nanbield) : la génération SPDX est activée par défaut.
• 5.1 (Styhead) : SPDX 3.0 par défaut au lieu de 2.2, et une classe vex qui fournit aux outils CVE externes les informations dont ils ont besoin.
• 5.3 (Whinlatter) : SPDX_INCLUDE_COMPILED_SOURCES, qui n'inclut que les sources utilisées pour la compilation.
• 6.0 (Wrynose, support à long terme) : SPDX 2.2 supprimé ; SPDX_INCLUDE_KERNEL_CONFIG et SPDX_INCLUDE_PACKAGECONFIG ajoutés ; les recettes construites avec les classes Cargo, Go, PyPI, npm et CPAN reçoivent une package URL de leur écosystème.

La SBOM couvre ce que BitBake construit, y compris les outils natifs qu'il construit pour l'hôte. Elle est exhaustive pour tout ce qui a une recette.

Le statut des CVE en VEX dans la SBOM

En SPDX 3, le système de build écrit le statut des CVE de chaque recette sous forme de relations VEX : une CVE corrigée devient « fixed », liée aux fichiers de patch ; une CVE non corrigée « affected » ; une CVE ignorée « not affected », avec la raison comme impact statement. SPDX_INCLUDE_VEX détermine ce qui est inclus : none, current (la valeur par défaut, les vulnérabilités qui ne sont pas déjà corrigées dans la source upstream) ou all.

CVE_STATUS et la balise de patch

CVE_STATUS enregistre une décision par CVE, sous forme de raison et de description facultative. Les raisons correspondent à corrigé (backported-patch, cpe-stable-backport, fixed-version et d'autres), non corrigé (vulnerable-investigating) et ignoré (cpe-incorrect, disputed, not-applicable-config, not-applicable-platform, upstream-wontfix). CVE_STATUS_GROUPS applique une décision à un groupe de CVE, et CVE_PRODUCT définit le nom de produit utilisé pour la correspondance.

# In a recipe or .bbappend
CVE_STATUS[CVE-2020-15523] = "not-applicable-platform: Issue only applies on Windows"

# In the header of a patch file
CVE: CVE-2022-3341
Upstream-Status: Backport [link to the upstream commit]

De cve-check à sbom-cve-check

cve-check comparait les noms de recettes (CVE_PRODUCT) et les versions aux données de vulnérabilités. Les notes de version de la 5.2 avertissent que depuis début 2024, les mainteneurs de la NVD ont cessé d'annoter de nombreuses CVE avec les CPE concernés, de sorte que « les rapports CVE actuels peuvent sembler bons, mais en réalité certaines vulnérabilités ne sont tout simplement pas signalées ». La 5.2 a aussi fait du flux FKIE la source par défaut à la place de la NVD. Yocto 6.0 a supprimé cve-check et l'a remplacé par la classe sbom-cve-check, qui exécute sbom-cve-check de Bootlin sur la sortie SPDX. De la 5.0 à la 5.3, vous avez encore cve-check ; considérez-le comme un outil hérité.

Où s'arrête la SBOM de Yocto

Ce que Yocto ne peut pas voir, c'est tout ce qui se trouve hors des métadonnées de BitBake. Nous avons construit core-image-sato deux fois sur un runner ARM64 natif doté de 32 vCPU, une fois avec la génération de SBOM de Yocto et une fois sans, puis comparé la SBOM SPDX 3.0.1 de Yocto, écrite sous forme de 1 632 fichiers, avec la SBOM CycloneDX enregistrée par CRACI :

• Composants. La SBOM enregistrée par CRACI contenait tous les composants de la SBOM de Yocto, plus 88 qu'elle avait manqués : 23 paquets de l'hôte sur la machine de build (comme cpio d'Ubuntu), 10 sources GitHub dont la GitHub Action actions/upload-artifact, et 55 autres sources et outils récupérés pendant le build.
• Crates Rust. Les deux listaient les mêmes 653 versions de crates Rust. Dans la release que nous avons construite, la SBOM de Yocto ne les listait que comme fichiers .crate avec un emplacement de téléchargement, sans package URL pkg:cargo, si bien qu'elles ne pouvaient pas être comparées aux avis de sécurité. Depuis Yocto 6.0, les recettes construites avec la classe Cargo portent une package URL pour la recette elle-même, comme pkg:cargo/librsvg ; dans le code actuel, les téléchargements de crates individuels n'en ont toujours pas. Vérifiez ce qu'écrit votre release.
• Coût. Le build avec la génération de SBOM de Yocto a duré 155 min 40 s et a écrit 1 632 fichiers SPDX. Sans elle, le build a duré 88 min 48 s, soit 43 % de moins. SPDX_INCLUDE_SOURCES, SPDX_INCLUDE_COMPILED_SOURCES, SPDX_INCLUDE_KERNEL_CONFIG et SPDX_INCLUDE_PACKAGECONFIG étaient activés, donc une configuration par défaut coûte moins. La documentation de Yocto elle-même avertit qu'avec les sources compilées incluses, la SBOM non compressée de core-image-minimal « peut passer de centaines de mégaoctets à plusieurs gigaoctets ».

Les recettes natives comme cmake, llvm, ninja et qemu figurent dans la SBOM de Yocto. La méthode, les deux SBOM et le rapport complet sont sur les builds Yocto sur CRACI.

Les CVE du noyau Linux : le problème par configuration

Le projet du noyau Linux a annoncé le 13 février 2024 qu'il était devenu CVE Numbering Authority, et il attribue des CVE aux correctifs de façon généreuse. Sa documentation sur les CVE indique que l'applicabilité d'une CVE donnée « est à déterminer par l'utilisateur de Linux », car « nous ne connaissons pas votre cas d'usage, et nous ne savons pas quelles parties du noyau vous utilisez ».

Une correspondance sur la version du noyau produit donc des centaines de résultats, pour la plupart concernant du code que votre configuration ne compile jamais. Quatre plateformes matérielles avec quatre configurations du noyau donnent quatre réponses différentes pour la même version du noyau. Il existe quatre façons de le gérer :

1. Correspondance de version seule. Toutes les CVE de la version sont signalées. Bruit maximal.
2. Listes d'exclusion maintenues. Des entrées CVE_STATUS générées à partir des données CVE du noyau. En mai 2026, oe-core a supprimé sa liste générée pour linux-yocto, car sbom-cve-check le fait lui-même à partir de la liste de CVE fournie par le noyau, avec un rapport CVE inchangé et un SPDX plus petit de près de 20 Mo.
3. Filtrage selon ce qui a été compilé. Avec SPDX_INCLUDE_COMPILED_SOURCES activé pour la recette du noyau, improve_kernel_cve_report.py vérifie si les fichiers concernés par une CVE ont servi à construire le noyau. Le manuel de sécurité de Yocto indique qu'il « réduit les faux positifs CVE de 70 % à 80 % ».
4. Enregistrer la configuration. SPDX_INCLUDE_KERNEL_CONFIG (6.0) écrit la configuration du noyau dans la SBOM, ce qui permet de vérifier la réponse plus tard.

Exemple concret. Une CVE du noyau dans un pilote réseau. La plateforme A construit le pilote ; la plateforme B, non.

Plateforme	Pilote compilé ?	Correspondance de version	Filtre sur les sources compilées
A	Oui	Signalée	Signalée : les fichiers concernés ont été construits
B	Non	Signalée	Non signalée : les fichiers concernés n'ont pas été construits

Pour obtenir aujourd'hui des rapports CVE du noyau par plateforme, exécutez l'outillage de Yocto sur les sources compilées une fois par configuration de machine. C'est la configuration qui décide de la réponse : le rapport doit donc provenir du build de chaque configuration.

Caches, miroirs et vendoring : là où tout enregistreur doit être prudent

• Un build qui restaure tout depuis sstate ou depuis un DL_DIR déjà rempli récupère peu de choses, voire rien. Un enregistreur qui voit les récupérations doit transporter ses preuves avec ces caches, sinon l'enregistrement se réduit.
• Une recette qui pointe vers un tarball pré-vendoré montre un seul téléchargement, pas les crates ou les modules qu'il contient.
• Quel que soit l'outil, construisez les images de release à partir d'un état de cache connu, gardez des miroirs que vous contrôlez et comparez le nombre de composants d'un build à l'autre.

Sur CRACI, les paquets restaurés depuis les caches de CI restent dans la SBOM, et l'état de complétude de chaque job signale ce que l'enregistrement n'a pas pu voir.

Quoi utiliser : un tableau de décision

Situation	Quoi utiliser	Ce que vous obtenez	Ce qui vous manque encore
Vous construisez l'image dans GitHub Actions	Enregistrer le build (CRACI) ; garder create-spdx si vous dépendez de son statut de patches et de CVE	Paquets de l'hôte, sources et Actions récupérées, une URL pkg:cargo par crate, une surveillance continue	Filtrage du noyau par configuration : utilisez l'outillage de Yocto
Vous construisez avec Yocto dans un autre système de CI ou sur un serveur de build	create-spdx avec sbom-cve-check (ou cve-check sur les anciennes releases), filtrage du noyau avec les sources compilées	Recettes, patches, statut des CVE en VEX	Un inventaire des paquets de l'hôte et des outils récupérés, tenu séparément
Vous recevez un firmware que vous ne construisez pas	L'analyse binaire, et une SBOM de build fournie par le fournisseur	Des composants déduits du binaire	Une certitude sur les versions, les patches et les entrées du build
Vous avez besoin des CVE du noyau par plateforme	L'outillage de Yocto sur les sources compilées, par configuration de machine	Les CVE du code que chaque configuration construit	Les composants hors noyau, depuis votre SBOM
Vous n'avez qu'un scanner d'images	L'utiliser pour les paquets installés, si la base de données des paquets est conservée	Une partie de la liste des paquets d'exécution	Tout ce qui est compilé dedans, patché ou resté sur l'hôte de build ; un résultat propre n'est pas une preuve

Ce que voit chaque méthode

Classe de composants	Scanner d'images	Analyse binaire	Yocto create-spdx	Enregistrement du build (CRACI)
Paquets installés	Seulement si la base de données des paquets est conservée	Déduits des fichiers	Oui	Oui, à partir des sources récupérées par le build
Bibliothèques statiques	Non	Déduites des signatures	Oui, en tant que recettes	Oui, à partir des sources récupérées par le build
Crates Rust	Non	Déduites ; les frontières entre crates disparaissent	En tant que téléchargements .crate, sans package URL par crate	Oui, chacune avec une package URL pkg:cargo
Modules Go	Non	Déduits du binaire	En tant que téléchargements de modules de la recette	Oui, lorsqu'ils sont récupérés pendant le build
Patches appliqués et statut des CVE	Non	Non	Oui, en VEX	Non
Configuration du noyau	Non	Non	Oui, avec SPDX_INCLUDE_KERNEL_CONFIG (6.0)	Non
Outils de l'hôte sur la machine de build	Non	Non	Non (recettes natives, oui)	Oui
Outils de build récupérés hors des recettes, et GitHub Actions	Non	Non	Non	Oui

La place de CRACI

Pour les builds Yocto qui s'exécutent dans GitHub Actions, CRACI est le runner, avec jusqu'à 32 vCPU et 96 Go de RAM. Il enregistre ce que le build a récupéré, y compris les paquets de l'hôte, les sources et Actions GitHub et les autres sources récupérées, avec une package URL pour chaque crate Rust : dans la comparaison publiée, tous les composants de la SBOM de Yocto, plus 88 qu'elle avait manqués. Il compare les composants aux avis de sécurité, réévalue en continu la SBOM à mesure que de nouveaux avis sont publiés, et montre quels builds contenaient une dépendance vulnérable.

BitBake peut déjà restreindre son fetcher avec BB_ALLOWED_NETWORKS. La politique d'egress de CRACI ajoute un second contrôle au niveau du runner, vérifié avant le démarrage du job et bloquant en cas d'échec, de sorte qu'un script ou un outil qui contourne le fetcher ne peut toujours pas atteindre un hôte que vous n'avez pas autorisé.

Pour la couverture de la supply chain, la SBOM de CRACI peut remplacer create-spdx. Le SPDX de Yocto contient toujours les patches appliqués et les CVE marquées comme corrigées, que CRACI n'enregistre pas : gardez donc create-spdx activé si vous en dépendez. La documentation de CRACI comprend un exemple qui construit core-image-sato. Pourquoi l'enregistrement l'emporte sur le scan en général : voir les SBOM au moment du build ; les outils Yocto sont comparés dans comparatif des outils de sécurité embarquée et CRACI vs Timesys Vigiles.

Quand CRACI n'est pas la réponse

• Vous dépendez du statut des CVE au niveau des patches, comme les décisions CVE_STATUS et les CVE corrigées ou ignorées en VEX. Cela se trouve dans le SPDX de Yocto : conservez-le.
• Vous avez besoin dès aujourd'hui de rapports CVE du noyau par configuration. Utilisez l'outillage de Yocto sur les sources compilées.
• Vous ne construisez pas le firmware. Utilisez l'analyse binaire.
• Vos builds Yocto s'exécutent hors de GitHub Actions, ou doivent s'exécuter sur votre propre infrastructure. CRACI propose aujourd'hui des runners managés sur une infrastructure européenne ; les autres systèmes de CI et les runners hébergés par le client sont sur la roadmap.
• Vous avez besoin de la SBOM du job Yocto spécifiquement en SPDX. La SBOM de CRACI dans la comparaison publiée était au format CycloneDX ; la SBOM propre à Yocto est en SPDX.

Vous concevez des appareils connectés pour le marché européen ? Lisez ce qu'exige le CRA, comment fonctionne VEX, et comment CRACI s'adapte aux équipements télécoms et réseau, à l'IoT industriel et à l'électronique grand public.

Yocto CVE check et SBOM : questions fréquentes

Pourquoi mon outil SCA ne peut-il pas analyser nos produits basés sur Yocto ?

Parce que la plupart des outils SCA lisent des manifestes, des lockfiles ou la base de données des paquets d'une image, alors qu'un build Yocto décide de son contenu dans BitBake. Les images de production suppriment souvent la base de données des paquets, les bibliothèques statiques et les crates Rust sont compilées dans les binaires, les patches des recettes laissent les numéros de version upstream en place, et les outils de l'hôte de build n'atteignent jamais l'image.

Puis-je scanner une image Yocto ou un firmware avec Trivy, Grype ou un scanner binaire ?

Oui, et vous obtiendrez une réponse partielle. Un scanner d'images lit les paquets installés si la base de données des paquets est conservée, et rate ce qui est compilé dedans. Un scanner binaire déduit les composants à partir de chaînes et de signatures, et doit deviner face aux binaires strippés, au code statique et au Rust compilé. Aucun des deux ne voit l'hôte de build ni les patches appliqués par une recette.

La SBOM de Yocto inclut-elle les crates Rust et les modules Go ?

Elle les liste comme sources de la recette qui les utilise. Dans la release que nous avons construite, chaque crate Rust apparaissait comme un téléchargement .crate avec un emplacement de téléchargement et sans package URL pkg:cargo. Depuis Yocto 6.0, les recettes construites avec les classes Cargo et Go reçoivent une package URL de leur écosystème pour la recette elle-même, pas pour chaque téléchargement de crate ou de module.

Pourquoi mon scanner signale-t-il des CVE que nos recettes Yocto corrigent déjà ?

Parce qu'il compare des numéros de version. Une recette Yocto conserve la version upstream et applique les correctifs de sécurité sous forme de patches, marqués par une ligne CVE: ou enregistrés dans CVE_STATUS. Une comparaison par plages de versions ne peut pas voir le patch. Le SPDX de Yocto enregistre ces CVE comme corrigées, liées aux fichiers de patch.

Qu'est-ce qui a remplacé cve-check dans Yocto ?

La classe sbom-cve-check, dans Yocto 6.0. Elle exécute sbom-cve-check de Bootlin sur la sortie SPDX du build. Les releases 5.0 à 5.3 ont encore cve-check, qui comparait les noms et les versions des recettes ; les notes de version de la 5.2 avertissent que ses rapports peuvent manquer des vulnérabilités, car de nombreuses CVE ne portent plus de données CPE.

Comment obtenir les CVE du noyau Linux pour ma propre configuration du noyau ?

Activez SPDX_INCLUDE_COMPILED_SOURCES pour la recette du noyau et exécutez improve_kernel_cve_report.py, qui vérifie si les fichiers concernés par chaque CVE ont été compilés. Le manuel de sécurité de Yocto indique qu'il réduit les faux positifs CVE de 70 % à 80 %. Exécutez-le par configuration de machine, puisque chaque configuration construit du code différent.

Le cache shared state a-t-il un effet sur la SBOM ?

C'est possible. Les tâches restaurées depuis sstate sautent les étapes fetch et compile, si bien qu'un outil qui repose sur l'observation de ces étapes voit moins de choses. create-spdx de Yocto s'appuie sur les métadonnées des recettes. Quelle que soit la méthode, construisez les images de release à partir d'un état de cache connu et comparez le nombre de composants d'un build à l'autre.

La SBOM intégrée de Yocto suffit-elle pour le CRA ?

Le CRA exige une SBOM couvrant au moins les dépendances de premier niveau, et la SBOM de Yocto est exhaustive pour ce que BitBake construit. Elle ne liste pas les paquets de l'hôte sur la machine de build, les GitHub Actions ni les outils récupérés hors des recettes. C'est à vous de juger si cela suffit ; la SBOM est une preuve de votre processus, pas une conformité en soi.