Le SBOM d'une chaîne de firmware, lisible par euvex

Au dépôt, chaque composant est cherché dans OSV par son purl. OSV n'indexe pas pkg:generic, l'identifiant que ces chaînes écrivent le plus souvent, ni un composant sans purl. Ces composants ressortent « non analysé », et le rapport ne conclut pas à l'absence de vulnérabilité tant qu'il en reste un.

Pendant la surveillance programmée, euvex interroge la NVD pour ces composants-là : par leur cpe quand le SBOM en porte un, sinon par leur nom et leur version exacte, avec un éditeur inconnu. Un composant sans CPE ni version reste « non analysé », jamais compté comme sain.

La NVD répond un composant à la fois, et euvex borne le temps qu'il lui consacre à chaque revérification, une trentaine de composants environ. Tant qu'un composant n'a jamais été demandé, le scan revient à chaque passe, toutes les dix minutes, pendant les quarante-huit heures qui suivent le dépôt : un firmware de trois cents composants est couvert en deux heures environ, puis revu chaque jour. Le rapport affiche la couverture « N sur M » en attendant, et les alertes par email partent en une fois, à la fin.

Yocto écrit par défaut un SBOM au format SPDX, par la classe create-spdx que INHERIT_DISTRO hérite.

Yocto 5.1 et suivants. C'est du SPDX 3.0, en un seul fichier à côté de l'image, dans ${DEPLOY_DIR_IMAGE}, par exemple core-image-minimal-qemux86-64.rootfs.spdx.json. Déposez-le tel quel : le rootfs devient le produit, les paquets installés dans l'image les composants, avec les CPE que Yocto tire de CVE_PRODUCT. Les sources téléchargées et les recettes ne sont pas reprises.

Yocto 5.0 (scarthgap). La sortie par défaut est une archive .spdx.tar.zst, un document par paquet, qu'euvex ne lit pas. La classe create-spdx-3.0 y existe en option depuis yocto-5.0.14 ; sinon, pour du CycloneDX, il faut une couche de plus : meta-cyclonedx, maintenue hors du Yocto Project, avec une branche par version de Yocto (kirkstone, scarthgap et les suivantes).

git clone https://github.com/iris-GmbH/meta-cyclonedx.git
cd meta-cyclonedx
git checkout scarthgap

BBLAYERS += "${BSPDIR}/sources/meta-cyclonedx"

INHERIT += "cyclonedx-export"
CYCLONEDX_SPEC_VERSION = "1.6"

Pourquoi fixer la version. La couche écrit par défaut du 1.4 sur kirkstone et scarthgap, du 1.6 sur les branches suivantes, et du 1.7 sur sa branche principale. euvex lit 1.2 à 1.6 : demander 1.6 marche sur toutes.

Où trouver le fichier. Cela dépend de la branche. Sur scarthgap, bom.json dans ${DEPLOY_DIR}/cyclonedx-export ; sur les branches récentes, à côté de l'image, avec le suffixe .cyclonedx.bom.json. Le README de votre branche fait foi. Déposez le SBOM, pas vex.json : euvex ne lit pas le VEX.

Ce qu'il contient. Par défaut, les paquets installés dans l'image seulement, chacun avec un purl générique tiré de CVE_PRODUCT et un CPE. Si vous incluez les paquets de compilation (CYCLONEDX_RUNTIME_PACKAGES_ONLY = "0"), la couche les marque optional, et euvex les comptera comme distribués. Le réglage par défaut évite ce bruit.

Le nom du produit. Sur les branches qui les proposent, scarthgap comprise, CYCLONEDX_IMAGE_NAME et CYCLONEDX_IMAGE_VERSION fixent le nom et la version écrits dans metadata.component, donc ceux du scan.

Buildroot livre un script qui transforme la sortie de make show-info en CycloneDX 1.6, une version qu'euvex lit telle quelle.

make show-info | utils/generate-cyclonedx \
  --project-name thermostat-x --project-version 2.1.0 > sbom.cdx.json

Avant 2025.08, les deux options n'existent pas, et le produit s'appelle buildroot, à la version de Buildroot. Le script plus bas corrige le nom.

make show-info | utils/generate-cyclonedx > sbom.cdx.json

Ce qu'il contient. Chaque paquet avec son nom, sa version, ses licences, et un cpe quand le paquet en déclare un (variables LIBFOO_CPE_ID_*). Aucun purl : OSV ne pourra rien en dire au dépôt, la NVD prend le relais pendant la surveillance programmée.

Les outils de l'hôte. Le fichier liste aussi les paquets construits pour la machine de compilation, repérés par la propriété BR_TYPE à host, sans scope. euvex ne lit pas cette propriété : ils seraient comptés comme distribués. Le script suivant les marque excluded, ce que dit CycloneDX d'un composant absent à l'exécution, et pose le nom et la version du produit.

python3 - sbom.cdx.json sbom-euvex.cdx.json thermostat-x 2.1.0 <<'EOF'
import json, sys
source, cible, nom, version = sys.argv[1:5]
with open(source) as f:
    bom = json.load(f)
bom["metadata"]["component"]["name"] = nom
bom["metadata"]["component"]["version"] = version
for c in bom.get("components", []):
    if any(p.get("name") == "BR_TYPE" and p.get("value") == "host" for p in c.get("properties", [])):
        c["scope"] = "excluded"
with open(cible, "w") as f:
    json.dump(bom, f, indent=2)
EOF

Déposez ensuite sbom-euvex.cdx.json. Les CVE que Buildroot marque comme corrigées par ses correctifs, dans la section vulnerabilities, ne sont pas reprises : voyez « Ignoré », plus haut.

Zephyr produit ses SBOM avec west spdx, après une compilation faite avec CONFIG_BUILD_OUTPUT_META. Il écrit dans BUILD_DIR/spdx/ quatre documents SPDX 2.3 en tag-value : l'application, le noyau Zephyr, la compilation et les modules.

west build -d build
west spdx -d build

Ce qu'il faut déposer. Les trois documents qui disent le produit et ce qu'il embarque, mis bout à bout, l'application en premier : elle devient le produit, Zephyr et les modules ses composants.

cat build/spdx/app.spdx build/spdx/zephyr.spdx build/spdx/modules-deps.spdx > firmware.spdx

Le CPE et le purl d'un module viennent de son module.yml (security: external-references) : un module qui n'en déclare pas est cherché par son nom et sa version. Le SPDX 3.0 de Zephyr, encore expérimental, n'a pas été essayé.

Dans la console, « Nouveau scan », déposez le fichier. Puis rattachez le scan au produit qu'il documente : c'est le rattachement qui ouvre le volet RED ou Machines, la déclaration UE et la détection art. 14. Rattacher un scan à un produit.

À chaque nouvelle version du firmware, un nouveau SBOM : la version du produit change, la gamme reste la même.

• openembedded-core, spdx30_tasks.py, branches walnascar, whinlatter et master, et create-spdx-2.2.bbclass de scarthgap.
• Zephyr, « Software bill of materials: west spdx », et le générateur scripts/west_commands/zspdx/writer.py.
• Spécification SPDX 3.0.1 et 2.3.
• Yocto Project, « Creating a Software Bill of Materials », manuel du développeur.
• meta-cyclonedx, README des branches main, kirkstone, scarthgap, whinlatter et wrynose.
• Manuel de Buildroot, section 8.9, édition 2026.08, et le script utils/generate-cyclonedx aux versions 2025.02 à 2026.08.
• CycloneDX 1.6, définition de scope.
• Ce qu'euvex mesure d'OSV et de la NVD : nos sources.