Nouvelles obligations pour les SBOM : la CISA impose la signature numérique et une couverture illimitée des dépendances

Le 31 juillet 2026, la CISA, conjointement avec 16 organismes gouvernementaux de quatre continents, a publié la version actualisée du guide sur les éléments minimaux pour le Software Bill of Materials. Le document remplace les lignes directrices NTIA de 2021 et apporte dix nouveaux champs obligatoires, le passage du concept de « profondeur » à celui de « couverture » et l’introduction de la signature numérique pour attester de l’intégrité et de l’authenticité. Le lendemain, l’agence a également diffusé un guide distinct sur la sécurité de l’open source.

Les dix champs qui redessinent l’inventaire logiciel

Le nouveau guide ajoute dix éléments jusqu’ici absents. Parmi eux, le plus impactant est la signature numérique du SBOM, conçue pour garantir son intégrité et son authenticité tout au long de la chaîne d’approvisionnement. S’y ajoute l’obligation d’indiquer le nom et la version de l’outil utilisé pour générer l’inventaire, ainsi que d’autres données qui rendent traçable l’origine de chaque composant.

La première version, datant de 2025, a été affinée après avoir reçu des commentaires de plus de 90 organisations, dont Google, Microsoft et AWS. Le résultat est un ensemble d’exigences qui, tout en formalisant des pratiques déjà répandues — comme le souligne Jeff Williams d’OWASP et de Contrast Security — rend plus stricte la transparence exigée des fournisseurs de logiciels pour le gouvernement fédéral.

De la profondeur à la couverture : adieu les limites sur les dépendances indirectes

La modification structurelle la plus importante concerne la gestion des dépendances. Jusqu’à présent, le champ « depth » fixait un niveau maximal d’imbrication à déclarer. Le nouveau guide le supprime et introduit le champ « coverage » : désormais, le SBOM doit inclure toutes les dépendances transitives, c’est-à-dire les dépendances des dépendances, sans aucune limite de profondeur.

Ce changement oblige les fournisseurs à une analyse récursive complète des composants tiers, réduisant les angles morts où une vulnérabilité pouvait se cacher dans un paquet imbriqué au-delà de la limite précédente. La couverture devient une exigence absolue, non paramétrable.

Ce que cela signifie pour les fournisseurs de logiciels au gouvernement américain

Les organisations opérant sous un régime de conformité fédérale devront adapter leurs processus de génération de SBOM pour respecter trois contraintes immédiates :

• inclure la signature numérique ;
• enregistrer l’outil et la version utilisés pour produire l’inventaire ;
• étendre l’analyse à tous les niveaux de dépendance, sans exception.

Il ne s’agit pas d’obligations révolutionnaires, car les outils basés sur SPDX et CycloneDX offrent déjà une grande partie de ces fonctionnalités. Cependant, le durcissement formel relève la barre pour la gestion du risque de la chaîne d’approvisionnement et pour la conformité aux cadres dérivés des indications de la CISA.

Les critiques : sans VEX et sans vérification, le SBOM reste un outil partiel

Selon Williams, le guide ne saisit pas deux nœuds essentiels. Il manque tout d’abord le VEX (Vulnerability Exploitability eXchange), c’est-à-dire un format pour contextualiser l’exploitabilité réelle des vulnérabilités dans un contexte de déploiement spécifique. En son absence, le SBOM continue de produire des listes de CVE sans aider à établir des priorités de correction.

Le second point douloureux est la vérification de l’exactitude et de la couverture. Le guide n’exige pas que l’inventaire déclaré corresponde à ce qui est effectivement distribué ou déployé, ni ne prévoit de contrôles automatiques de cohérence. Cela limite l’utilité pratique du document dans les décisions de sécurité quotidiennes. En attendant des évolutions, l’expert conseille des vérifications internes de complétude et de correspondance entre le SBOM et les artefacts réels.

Le lendemain : un guide sur la sécurité de l’open source

Le 1er août, la CISA a publié un second guide, consacré aux bonnes pratiques pour la sécurité des logiciels open source. Il ne s’agit pas d’un complément direct du nouveau SBOM, mais il s’inscrit dans le cadre global par lequel l’agence redessine les exigences de transparence et de rigueur dans la chaîne logicielle, en étendant les indications à l’écosystème des composants ouverts.