SBOM : le produire et le maintenir pour le Cyber Resilience Act

Le Cyber Resilience Act demande aux fabricants de produits comportant des éléments numériques d’identifier et de documenter les composants logiciels qu’ils intègrent. L’outil de référence pour cela est le SBOM (Software Bill of Materials), l’inventaire des composants d’un logiciel.

À quoi sert un SBOM

Quand une vulnérabilité est publiée dans une bibliothèque open source, la première question est : « quels produits, et quelles versions, l’embarquent ? ». Sans SBOM, la réponse prend des jours. Avec un SBOM à jour pour chaque version livrée, elle prend quelques minutes. C’est aussi ce qui rend tenables les délais de signalement du CRA (alerte précoce sous 24 heures, notification sous 72 heures), en vigueur depuis le 11 septembre 2026.

Deux formats standards

• SPDX, porté par la Linux Foundation et normalisé ISO/IEC 5962.
• CycloneDX, porté par l’OWASP, très utilisé dans les chaînes DevSecOps.

Les deux conviennent ; l’important est d’en choisir un et de le produire systématiquement.

Les bonnes pratiques

• Générer le SBOM dans la chaîne de build, à chaque version, plutôt qu’à la main.
• Couvrir tout le logiciel embarqué : système (Linux embarqué, RTOS), bibliothèques, micrologiciels tiers, pas seulement l’application.
• Archiver le SBOM de chaque version livrée, pendant toute la période de support.
• Le croiser automatiquement avec les bases de vulnérabilités pour être alerté.
• Documenter l’exploitabilité : une vulnérabilité présente n’est pas toujours exploitable dans votre produit ; le format VEX permet de le déclarer.

Le SBOM ne suffit pas

Il s’inscrit dans un ensemble : analyse de risques, démarrage sécurisé, mises à jour à distance, processus de gestion et de signalement des vulnérabilités. Notre accompagnement à la conformité CRA commence par une analyse d’écart sur un produit représentatif.

Article informatif à jour au 29 septembre 2026. Les textes réglementaires et leurs calendriers évoluent : il ne constitue pas un avis juridique.