La CISA a réécrit les règles du SBOM : ce que signifient les Minimum Elements 2026, et comment monsys y est déjà conforme

Le 29 juillet 2026, la CISA a publié les 2026 Minimum Elements for a Software Bill of Materials. Ils remplacent la base de 2021 rédigée par la National Telecommunications and Information Administration (NTIA), et ont été rédigés par une coalition remarquablement large : la CISA, la NSA et le FBI aux côtés de l'ACSC australien, du Cyber Centre canadien, du NÚKIB tchèque, de l'ANSSI française, du BSI allemand, du NCSC-NL néerlandais et d'autres.

Cette coalition est parlante. Elle signale qu'« un SBOM » n'est plus une simple case à cocher pour les achats américains. Il devient le langage commun et lisible par machine qu'attendent aussi les régulateurs européens, en phase avec le Cyber Resilience Act (CRA) de l'UE et NIS2.

Si vous générez des SBOM aujourd'hui, la barre vient de monter. Voici ce qui a réellement changé, et ce qu'il faut pour s'y conformer.

Ce que demande la norme 2026

La base de 2021 comptait sept champs de données et une poignée de pratiques. La révision de 2026 conserve ces principes fondamentaux mais y met beaucoup plus de mordant. Les éléments minimaux se répartissent désormais en trois groupes.

Métadonnées au niveau du SBOM (sur le document lui-même) :

Données au niveau des composants (sur chaque partie du logiciel) :

Pratiques et processus : Accommodation of Updates, Coverage (tous les composants, y compris transitifs, sans profondeur minimale), Distribution and Delivery (une API ou une URL est désormais explicitement un canal de livraison accepté), Explicitly Identifying Unknown Information, Frequency et Machine-Processable Data. Sur ce dernier point, la norme nomme exactement deux formats acceptés : SPDX et CycloneDX.

Pourquoi ce changement

Trois forces ont motivé la réécriture.

L'outillage a rattrapé. En 2021, exiger que chaque SBOM soit signé ou porte des empreintes par composant était irréaliste. En 2026 les outils le font, donc les acheteurs peuvent exiger davantage.

L'intégrité est devenue l'enjeu. L'ajout phare est la SBOM Author Signature. Un SBOM non signé n'est qu'un fichier texte que n'importe qui peut modifier. Un SBOM signé permet au destinataire de prouver que l'inventaire n'a pas été altéré en transit et qu'il provient bien de qui il prétend. C'est la différence entre « une liste » et « une preuve ».

La réglementation a convergé. La liste des co-auteurs se lit comme un who's who des agences cyber européennes, et ce n'est pas un hasard. Le CRA va exiger des SBOM pour les produits comportant des éléments numériques, et les auditeurs NIS2 réclament une visibilité sur la chaîne d'approvisionnement. Une base unique, resserrée et co-signée à l'international, c'est précisément ce qui permet à un seul SBOM de satisfaire plusieurs régimes à la fois.

La norme ajoute même une section sur la corrélation des SBOM avec les avis de sécurité, en nommant explicitement VEX et CSAF. Autrement dit : un inventaire seul n'est pas l'objectif. Il faut l'inventaire plus un signal d'exploitabilité par vulnérabilité. (Nous avons écrit sur cette combinaison en publiant VEX ; il se trouve que la norme nous donne désormais raison.)

Les parties réellement difficiles

La plupart des nouveaux champs sont faciles si votre générateur parcourt déjà l'hôte. Trois ne le sont pas.

1. La signature. Il vous faut une vraie clé, une sérialisation canonique pour que la signature soit reproductible, et un chemin de vérification public. Signez les mauvais octets et chaque vérificateur en aval la rejette.
2. Les empreintes de composants. La norme veut une empreinte de chaque artefact de composant. Un outil qui inventorie des métadonnées installées (nom et version du paquet) n'a pas les octets originaux de l'artefact à hacher. Fabriquer une empreinte est pire que de n'en fournir aucune.
3. L'honnêteté sur les inconnues. La norme de 2026 est explicite : indiquez quand une valeur est réellement inconnue plutôt que de la laisser vide ou de deviner. Cela paraît anodin, mais c'est une vraie contrainte de conception, car cela interdit le mensonge de confort.

Comment monsys s'y conforme

Chaque SBOM que monsys génère, en SPDX 2.3 comme en CycloneDX 1.5, émet déjà l'ensemble complet. Voici la correspondance, élément par élément.

La signature, faite pour que chacun puisse la vérifier

Chaque SBOM est signé avec la clé Ed25519 du hub. CycloneDX utilise son bloc signature JSF natif ; SPDX porte la signature dans une annotation au niveau du document. Point crucial : la signature couvre la forme RFC 8785 (JSON Canonicalization Scheme) du document sans le porteur de signature. Ainsi, un tiers peut re-canoniser le fichier, récupérer notre clé publique et le vérifier hors ligne, avec n'importe quelle bibliothèque standard. C'est la même clé qui signe l'Audit Pack mensuel, donc une seule clé publique couvre toute notre preuve.

Honnête sur les empreintes de composants

monsys fait un inventaire d'hôte de métadonnées seules : il lit ce que rapportent les gestionnaires de paquets, il ne télécharge pas chaque binaire pour le stocker. Il ne peut donc pas calculer une véritable empreinte d'artefact, et il le dit, en enregistrant Component Hash comme unknown plutôt que d'inventer une valeur. C'est exactement le comportement que réclame l'élément « Explicitly Identifying Unknown Information » de la norme. Lorsque nous ajouterons une source qui porte des empreintes, le champ se remplira automatiquement.

Ce que vous obtenez concrètement

Ouvrez un hôte dans le tableau de bord, allez dans l'onglet CVE, et la barre d'export d'audit vous donne quatre téléchargements en un clic :

• SBOM en SPDX 2.3 ou CycloneDX 1.5, sur trois couches : dépendances applicatives, paquets OS et noyau en cours d'exécution.
• VEX en OpenVEX ou CycloneDX-VEX, indiquant par CVE si l'hôte est réellement affecté.

Ou récupérez-les directement depuis l'API, que la norme reconnaît désormais comme canal de livraison :

GET /api/v1/agents/{id}/sbom?format=spdx-json
GET /api/v1/agents/{id}/sbom?format=cyclonedx-json
GET /api/v1/agents/{id}/vex?format=openvex

Chaque téléchargement est signé et vérifiable hors ligne, et exactement les mêmes données sont incluses dans l'Audit Pack mensuel, de sorte que votre preuve signée correspond à ce que vos opérateurs peuvent récupérer à la demande.

L'essentiel

Les Minimum Elements 2026 relèvent le plancher de « une liste de composants » à « un inventaire signé, licencié et vérifiable par machine, couplé à un signal d'exploitabilité ». C'est plus de travail pour qui génère vos SBOM. Avec monsys, c'est un téléchargement, généré au sein d'une plateforme hébergée dans l'UE à partir de données que l'agent rapporte déjà, sans rien envoyer à des tiers.

Lisez la norme complète : 2026 Minimum Elements for a Software Bill of Materials (CISA, TLP:CLEAR). SBOM et VEX sont documentés sur docs.monsys.ai/fr/security/sbom-vex. Cinq premiers serveurs gratuits : monsys.ai/fr/signup.