Le 29 juillet 2026, la CISA a publié les « Éléments minimaux pour 2026 » Software Bill of Materials (SBOM), remplaçant ainsi les lignes directrices de la NTIA en vigueur depuis 2021, rédigées en collaboration avec la NSA, le FBI et 15 agences internationales de cybersécurité.
Le document « Éléments minimaux pour une liste des composants logiciels ( Software ) 2026 » (Bill of Materials (SBOM) ) est la spécification mise à jour par la CISA concernant les données qu’une SBOM doit contenir. Le changement le plus important est d’ordre structurel et non quantitatif : les éléments de la version 2026 n’interdisent pas les SBOM générées à partir de manifestes source, mais ils exigent des auteurs qu’ils indiquent comment la SBOM a été générée, qu’ils calculent la fonction de hachage de l’artefact exécutable et qu’ils étiquettent chaque champ qu’ils n’ont pas pu remplir. Un SBOM basé uniquement sur un manifeste indique désormais ses propres lacunes sous une forme lisible par machine.
MetaDefender Software Supply Chain Il s'agit de la plateforme de sécurité de la chaîne logistique logicielle d'OPSWAT, conçue pour analyser les artefacts, les fichiers binaires et les couches d'images de conteneurs — soit précisément la catégorie de données visée par les nouvelles exigences en matière de hachage, de contexte de génération et de couverture.
En bref
- 17 champs de données — 9 métadonnées SBOM, 8 données relatives aux composants
- 6 pratiques et processus
- 10 nouveaux domaines, 8 mises à jour majeures, 1 suppression (Contrôle d'accès, intégré à la rubrique « Distribution et livraison »)
- S'applique à tous les logiciels, « y compris les logiciels libres, les logiciels d'IA et les logiciels SaaS »
- Il ne s'agit pas de nouvelles exigences, mais d'un affinement de la manière dont les organisations génèrent et demandent des SBOM.
Les modifications apportées à la SBOM en 2026 auxquelles les SBOM « source-only » ont le plus de mal à se conformer
1. La valeur de hachage du composant nécessite l'artefact exécutable
Les paramètres « Valeur de hachage du composant » et « Algorithme de hachage du composant » précisent clairement ce qui est soumis au hachage : « le résultat obtenu en appliquant un algorithme de hachage cryptographique à un artefact de composant exécutable ». Il ne s'agit ni de l'entrée du manifeste, ni de la chaîne de version déclarée.
- Un analyseur syntaxique qui lit les fichiers `package-lock.json`, `pom.xml` ou `requirements.txt` ne traite pas d'artefact exécutable ; par conséquent, les deux champs de hachage renvoient la valeur « inconnu ».
- Lorsqu'un hachage existe, l'algorithme doit utiliser les noms textuels des fonctions de hachage de l'IANA et être approuvé par une autorité telle que le NIST
- Les hachages permettent au destinataire de vérifier que le composant décrit correspond bien à celui qui a été expédié.
2. Le contexte de génération de la SBOM fait de cette méthode un élément du dossier
Le « contexte de génération de la SBOM » est l’ajout le plus discret, mais aussi le plus significatif sur le plan structurel : « la phase relative du cycle de vie du logiciel et les données disponibles au moment où l’auteur de la SBOM l’a générée ». La CISA définit trois valeurs — « avant la compilation », « pendant la compilation » et « après la compilation » — et associe chacune d’elles à la manière dont la SBOM a été produite : une SBOM issue du code source correspond à la phase la plus précoce, tandis que les outils d’analyse binaire la situent à la phase la plus tardive.
- Les équipes chargées des achats peuvent préciser quelle phase du cycle de vie elles acceptent, en privilégiant les SBOM issues de l'artefact compilé plutôt que celles au niveau du code source.
- Les plateformes de gestion des vulnérabilités peuvent pondérer les résultats en fonction du contexte déclaré
- Une SBOM issue du code source reste autorisée, mais ne peut plus être présentée comme équivalente à celle générée à partir du fichier binaire final.
3. L'étendue remplace la profondeur, sans minimum requis
L'élément « profondeur » de 2021 n'exigeait que les dépendances de premier niveau — une définition qui, selon la CISA aujourd’hui, « reflétait les capacités des outils SBOM de l’époque plutôt que le niveau de détail nécessaire pour prendre des décisions éclairées en matière de sécurité ». Les exigences en matière de couverture sont désormais plus strictes : « tous les composants qui constituent le logiciel cible, y compris les dépendances transitives. Il n’y a pas de niveau de détail minimum ».
Le test est fonctionnel. Un destinataire « devrait pouvoir conclure qu’une vulnérabilité récemment signalée ne le concerne pas si la SBOM ne mentionne pas le composant associé à cette vulnérabilité ». L’absence devient une preuve, ce qui n’est valable que si la couverture est suffisamment complète. L’analyse du manifeste à elle seule a peu de chances d’atteindre ce niveau d’exigence pour :
- Code lié statiquement et fourni par un fournisseur — ne génère aucune entrée dans le manifeste
- Projets C et C++: aucun gestionnaire de paquets universel ne suit les DLL et les objets partagés intégrés lors de la compilation
- Code source copié — que la CISA décrit comme « en réalité une dépendance qu’il vaut mieux suivre en tant que fork et relation de dépendance »
- Container couches d'images — paquets installés à l'aide de commandes « layer » plutôt que déclarés dans un manifeste
Les informations inconnues doivent désormais être déclarées
- Les auteurs doivent faire la distinction entre les informations dont ils n'ont pas connaissance et celles qui leur sont délibérément cachées.
- Il est recommandé aux auteurs de mettre en place un dispositif permettant aux destinataires de se renseigner sur les passages caviardés liés à la sécurité.
- « Les organisations peuvent considérer qu'une SBOM est incomplète si son auteur omet de fournir des données essentielles sur les composants. »
- La tolérance vis-à-vis des erreurs a été supprimée au motif que les destinataires « peuvent s'attendre à ce que les données SBOM soient exactes » — les erreurs résultant du « choix d'outils inadaptés » constituent désormais des éléments légitimes à prendre en compte dans l'évaluation des risques effectuée par le destinataire.
Autres modifications apportées par la CISA aux éléments de la liste SBOM 2026
Modifier | De quoi s'agit-il ? | Pourquoi est-ce important ? |
Signature de l'auteur de la SBOM (nouveau) | Une signature numérique associée à l'auteur de la SBOM | Permet au destinataire de vérifier que la SBOM est authentique et qu'elle n'a pas été modifiée après la signature. |
Licence de composant (nouvelle) | La licence sous laquelle chaque composant est distribué | Risques liés aux droits d'auteur et à la conformité ; la CISA met en avant les identifiants de licence SPDX |
Données exploitables par machine (anciennement « Assistance à l'automatisation ») | SPDX et CycloneDX uniquement | Le SWID a été supprimé car il n'était pas largement utilisé ; cela réduit le nombre de formats acceptés à deux. |
Fabricant de composants (anciennement : nom du fournisseur) | Une organisation nommée par composant | Ajoute une solution de secours explicite « provenance inconnue » lorsque la source n'est pas claire |
Fréquence (mise à jour) | Une nouvelle liste SBOM pour chaque version, mise à jour et compilation intégrant les composants modifiés | Il est difficile de maintenir ce rythme manuellement, ce qui pousse les équipes à se tourner vers la génération automatisée |
Combler le fossé après la construction
La mise à jour de 2026 reflète l'évaluation de la CISA selon laquelle les outils SBOM ont suffisamment mûri pour qu'on puisse leur en demander davantage, et les informations qu'elle attend désormais se trouvent au-delà de la phase de compilation.
MetaDefender™ Software Supply Chain génère des données SBOM directement à partir de l'artefact compilé :
- Analyse les artefacts, les fichiers binaires et les couches d'images de conteneurs, et pas seulement les fichiers de dépendances
- Identifie les fichiers binaires C, C++ et C# grâce aux les métadonnées du format Portable Executable et l'identification basée sur les signatures
- Génère des SBOM dans CycloneDX et SPDX, et enrichit les rapports existants afin de mettre en évidence les composants et les CVE non détectés lors des analyses précédentes
- Effectue des recoupements avec les bases de données GHSA, CVE et EUVD, et signale les licences non conformes
- S'intègre aux pipelines CI/CD et aux registres d'artefacts tels que JFrog Artifactory, afin que la génération de la SBOM puisse accompagner chaque build
Pour découvrir comment MetaDefender Software Supply Chain peut répondre aux exigences relatives à la liste des composants logiciels (SBOM) tout au long du cycle de vie du développement :
FAQ
Quels sont les changements apportés aux éléments minimaux de la SBOM prévus par la loi CISA 2026 ?
Cette mise à jour ajoute dix nouveaux champs de données, apporte huit modifications majeures et supprime un élément. Le changement structurel le plus important consiste à remplacer « Depth » par « Coverage » ; par ailleurs, de nouveaux champs, notamment « Component Hash Value », « SBOM Generation Context » et « SBOM Author Signature », renforcent les attentes concernant la manière dont les données SBOM sont produites et vérifiées.
Les éléments minimaux de la SBOM prévus par la loi CISA 2026 sont-ils obligatoires ?
Non. La CISA ne fixe aucune date limite de mise en conformité ni aucun mécanisme d’application, et précise que le document « ne constitue pas un avis à des fins de conformité, réglementaires ou juridiques ». Son caractère contraignant découle des exigences en matière de marchés publics et des réglementations qui font référence aux normes de référence en matière de SBOM, telles que la loi européenne sur la cyber-résilience.
Les éléments minimaux de la SBOM prévus par la norme CISA 2026 nécessitent-ils une analyse des fichiers binaires ou une analyse post-compilation ?
Pas explicitement. Cependant, le champ « Component Hash Value » nécessite l'accès à l'artefact exécutable, le champ « SBOM Generation Context » exige que les auteurs déclarent la phase du cycle de vie, et les champs non renseignés doivent être marqués comme « inconnus ». Une SBOM « source-only » respecte donc le format tout en documentant ses propres lacunes.
Les éléments minimaux prévus par la CISA 2026 s'appliquent-ils aux logiciels d'IA et aux solutions SaaS ?
Oui. Le champ d'application couvre tous les logiciels, y compris les logiciels libres, l'IA et les solutions SaaS. La CISA précise que ces catégories peuvent nécessiter des éléments supplémentaires, mais ne les définit pas ici, renvoyant plutôt aux recommandations conjointes du G7 sur les SBOM pour l'IA publiées en mai 2026.
Quels sont les formats SBOM acceptés dans le cadre des éléments minimaux de la norme CISA 2026 ?
SPDX et CycloneDX, décrits comme les deux formats largement utilisés pour générer et exploiter les SBOM. Les balises SWID ont été supprimées, car il ne s'agit « pas d'un format de données SBOM largement utilisé pour lequel il existe plusieurs outils ». Les versions obsolètes d'un format, quel qu'il soit, ne doivent pas être utilisées pour les nouveaux logiciels.
