Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- Les éléments minimaux de la CISA pour 2026 ont remplacé, le 29 juillet 2026, les critères de référence de 2021 de l'Administration nationale des télécommunications et de l'information (NTIA) et ont défini 17 champs de données.
- En janvier 2026, le Bureau de la gestion et du budget (OMB) a abrogé les notes de service fédérales relatives à l'attestation de sécurité des logiciels, laissant ainsi à la discrétion de chaque agence la décision de demander ou non un SBOM.
- Les exigences de la CRA en matière de SBOM entreront en vigueur le 11 décembre 2027 et fixent les dépendances de niveau supérieur comme couverture minimale.
- Un composant peut être correctement répertorié dans une SBOM tout en étant malveillant, altéré ou abandonné sans correctif.
Les exigences relatives aux SBOM évoluent. L’Office of Management and Budget (OMB) a abrogé ses notes de service fédérales en janvier 2026 ; la FDA a réédité ses recommandations sur la cybersécurité des dispositifs médicaux en février ; la CISA a remplacé la norme de référence de 2021 concernant les données SBOM en juillet, et la loi européenne sur la cyber-résilience (CRA) commencera à exiger des SBOM de la part des fabricants en décembre 2027. Partout où une SBOM est exigée, ce que vous fournissez est une liste des composants présents dans votre logiciel.
Cette liste est utile. La liste des ingrédients figurant sur l'emballage d'un produit alimentaire indique que celui-ci contient des cacahuètes, ce qui est important si vous y êtes allergique. Vérifier si l'usine était propre ou si le fournisseur est bien celui qu'il prétend être nécessite une inspection, ce qui relève d'une autre mission.
Une SBOM fonctionne de la même manière. En rédiger une ne modifie en rien votre exposition aux risques, car tout composant vulnérable, altéré ou abandonné reste présent dans votre logiciel une fois la liste établie. Et aucune de ces quatre règles ne se limite à la liste. L’exigence fédérale a inscrit la SBOM dans un ensemble plus large de pratiques de développement sécurisées. Le document de la CISA précise que la SBOM constitue des données qui doivent encore être analysées, tandis que la FDA et la CRA vont plus loin en y associant l’obligation d’évaluer les composants qu’elle répertorie et d’y appliquer des correctifs.
Exigences relatives à la SBOM à compter d'octobre 2026
Quatre séries de règles sont particulièrement importantes à l'heure actuelle. Le tableau en présente un résumé, tandis que les sections suivantes fournissent les détails.
| Source | Ce qu'il demande | Situation au 7 octobre 2026 |
|---|---|---|
| Marchés publics fédéraux (décret présidentiel n° 14028 et directive OMB M-26-05) | Transmission de la liste des composants (SBOM) aux acheteurs, à la discrétion de l'agence d'achat | Le décret présidentiel n° 14028 est toujours en vigueur. Les notes d'attestation de l'OMB ont été abrogées le 23 janvier 2026. |
| Éléments minimaux de la CISA 2026 | Un ensemble de base de champs de données SBOM | Publié le 29 juillet 2026. Remplace le scénario de référence 2021 de la NTIA. |
| Section 524B de la FDA | Une liste des composants logiciels (SBOM) dans les dossiers de demande d'autorisation de mise sur le marché des dispositifs cybernétiques | En vigueur pour les demandes déposées depuis le 29 mars 2023. Directives rééditées le 3 février 2026. |
| Loi européenne sur la cyber-résilience | Une SBOM couvrant au moins les dépendances de niveau supérieur | L'obligation relative à la liste des composants (SBOM) s'applique à compter du 11 décembre 2027. Les obligations de déclaration ont pris effet le 11 septembre 2026. |
Ce qu'il reste de l'obligation fédérale relative à la liste des composants logiciels (SBOM)
Le décret présidentiel n° 14028, signé en mai 2021, a marqué le début de l’obligation fédérale relative à la liste des composants logiciels (SBOM). La section 4(e)(vii) prévoyait que le NIST émettrait des recommandations visant à fournir aux acheteurs une SBOM pour chaque produit, soit directement, soit sur un site web public. Le décret n’a pas été abrogé, mais la plupart des dispositions qui l’accompagnaient ont été retirées. Un décret de juin 2025 (décret n° 14306) a supprimé les dispositions relatives à l’attestation que le décret n° 14144, signé en janvier 2025, avait ajoutées, notamment la validation centralisée par la CISA des attestations des fournisseurs. Puis, le 23 janvier 2026, la note de service M-26-05 de l’OMB a abrogé les notes M-22-18 et M-23-16, qui étaient à l’origine du formulaire d’attestation de développement logiciel sécurisé.
Les agences peuvent toujours utiliser ce formulaire et continuer à inclure la fourniture d'une SBOM dans les clauses contractuelles, mais la politique à l'échelle du gouvernement n'impose plus aucune de ces deux obligations. Si vous vendez des logiciels à un acheteur fédéral, l'obligation de fournir une SBOM dépend désormais de la politique propre à cette agence et du contrat en question.
Référentiel CISA 2026 pour les données SBOM
Le 29 juillet 2026, la CISA, la NSA, le FBI et 15 organisations partenaires internationales ont publié les « Éléments minimaux pour une nomenclature logicielle (SBOM) 2026 ». Ce document remplace celui de 2021 publié par l’Administration nationale des télécommunications et de l’information (NTIA) à la suite du décret présidentiel 14028, et porte le nombre minimal de champs de données de 7 à 17. Parmi les nouveaux champs figurent la signature de l’auteur de la SBOM, une valeur de hachage et un algorithme de hachage pour chaque composant, les licences des composants, le nom et la version de l’outil de génération, ainsi qu’un contexte de génération indiquant à quelle phase du cycle de vie la SBOM a été générée, par exemple avant ou après la compilation.
Deux autres changements ont une incidence concrète. La couverture doit désormais inclure les dépendances transitives sans profondeur minimale, alors que la version de 2021 n'exigeait que les dépendances de premier niveau. De plus, chaque composant doit disposer d'au moins un identifiant exploitable par une machine, tel qu'un Package-URL.
Le document précise que ses éléments ne créent pas de nouvelles exigences, mais se contentent d'affiner la manière dont les organisations génèrent et demandent des SBOM. Il exclut également la vérification de l'exactitude, de la couverture et de l'exhaustivité d'une SBOM des éléments minimaux, car celles-ci nécessitent des mesures de qualité différentes de celles fournies par une signature.
Remarque : la CISA conclut elle-même qu’une SBOM, en soi, constitue un ensemble de données relatives aux composants logiciels, et que c’est l’analyse qui permet de transformer ces données en informations exploitables.
Exigences de la FDA relatives au SBOM en vertu de l'article 524B
Le Congrès a ajouté l’article 524B à la loi FD&C dans le cadre de la loi de réforme globale sur les aliments et les médicaments (Food and Drug Omnibus Reform Act) en décembre 2022. Cet article s’applique aux demandes de mise sur le marché déposées à compter du 29 mars 2023 pour un « dispositif cybernétique », c’est-à-dire un dispositif qui intègre un logiciel, peut se connecter à Internet et présente des caractéristiques susceptibles de le rendre vulnérable aux cybermenaces. La FDA interprète cette disposition de manière large, en considérant le micrologiciel comme un logiciel et en incluant les connecteurs tels que les ports USB et les ports série parmi les moyens de connexion. Les types de demandes concernés sont les demandes 510(k), PMA, PDP, De Novo et HDE. En vertu de l’article 524B(b)(3), le fabricant doit fournir une liste des composants logiciels (SBOM) couvrant les composants commerciaux, open source et prêts à l’emploi.
Les recommandations de la FDA, rééditées le 3 février 2026, vont au-delà des champs de base. Elles préconisent que chaque entrée relative à un composant précise son statut de support (par exemple : « activement maintenu », « plus maintenu » ou « abandonné ») ainsi que sa date de fin de support, et que les fabricants prévoient comment mettre à jour ou remplacer les composants tiers lorsque le support prend fin. Ces recommandations ne sont pas contraignantes, sont antérieures à la mise à jour de la CISA de 2026 et citent toujours les travaux de la NTIA de 2021 sur les attributs de base. La loi elle-même ajoute une obligation de correction. L’article 524B(b)(2) impose aux fabricants de dispositifs cybernétiques de mettre à disposition des mises à jour et des correctifs selon un cycle régulier pour les vulnérabilités connues inacceptables, et hors cycle pour celles jugées critiques susceptibles d’entraîner un risque incontrôlable.
Les exigences de la CRA en matière de SBOM et les questions qu'elles laissent en suspens
L'annexe I, partie II, point 1, de la loi sur la cyber-résilience impose aux fabricants d'identifier et de documenter les vulnérabilités et les composants, notamment en établissant une liste des composants logiciels (SBOM) dans un format couramment utilisé et lisible par machine, couvrant au minimum les dépendances de premier niveau. Le règlement est entré en vigueur le 10 décembre 2024, et les principales obligations, y compris celle relative à la SBOM, s'appliquent à compter du 11 décembre 2027. La SBOM fait partie de la documentation technique, et une autorité de surveillance du marché peut en faire la demande, en la motivant, lorsqu’elle en a besoin pour vérifier la conformité. Son partage avec les utilisateurs est facultatif.
La partie II de cette même annexe impose également aux fabricants de traiter et de corriger sans délai les vulnérabilités, notamment en fournissant des mises à jour de sécurité. L’article 13 impose une obligation de diligence raisonnable lors de l’intégration de composants tiers, y compris ceux open source, et exige des fabricants qui découvrent une vulnérabilité dans un composant qu’ils la signalent à son responsable de maintenance, puis qu’ils la corrigent dans leur propre produit. L’obligation relative à la SBOM s’accompagne donc d’obligations que la SBOM elle-même ne remplit pas. La liste indique ce que contient le produit, mais la vérification de ces composants et leur correction restent à la charge du fabricant. Dans la pratique, le seuil fixé au niveau supérieur va également à l’encontre de ces obligations : lorsqu’un avis de sécurité est publié, le composant concerné est souvent une dépendance transitive, et une SBOM qui se limite aux dépendances de niveau supérieur ne permet pas de savoir si vous l’utilisez. Il est plus facile de respecter l’obligation de correction avec une SBOM allant au-delà du minimum requis.
Le rôle du NIST
Si vous recherchez les exigences du NIST en matière de SBOM, la première chose à savoir est que le NIST ne publie pas lui-même d’éléments de données SBOM. C’est la NTIA qui a défini la norme de référence en 2021, et la CISA qui a établi celle actuellement en vigueur. Le rôle du NIST consiste à fournir des recommandations sur les processus. Le Cadre de développement logiciel sécurisé (SSDF, SP 800-218, version 1.1) cite la SBOM comme un exemple de données de provenance que les éditeurs doivent conserver pour chaque composant d’une version. Le SSDF revêtait une importance particulière pour les fournisseurs fédéraux, car le formulaire d’attestation que l’OMB a abrogé en janvier leur imposait de confirmer leur conformité au SSDF. Depuis cette abrogation, une agence peut toujours demander cette attestation, mais la politique à l’échelle du gouvernement ne l’exige plus.
Si un contrat stipule de se conformer aux normes du NIST, alignez vos pratiques de développement sur le SSDF, établissez une SBOM conforme aux éléments de la norme CISA 2026 et régénérez-la à chaque nouvelle version. Aucune autorité de régulation n’impose encore les éléments de la norme 2026, mais il s’agit de la référence publiée la plus stricte, et une SBOM établie selon ces critères satisfait également aux exigences minimales de la FDA et de la CRA. Lisez d’abord les termes du contrat, car ce sont eux qui déterminent lesquels de ces critères importent à l’acheteur.
Ces règles précisent qui est tenu d'établir une SBOM et ce qu'elle doit contenir. La FDA et la CRA mentionnent également les obligations qui en découlent, à savoir l'application de correctifs et la diligence raisonnable, mais ne donnent que peu de précisions sur la manière de les mettre en œuvre. C'est là que la SBOM ne suffit plus.
Ce qu’une SBOM conforme ne peut pas faire à elle seule
Respectez toutes les exigences relatives à la SBOM énoncées ci-dessus, et vous obtiendrez un document répertoriant le contenu de votre logiciel. Celui-ci peut contenir bien plus que les noms et les versions, comme par exemple un hachage et une signature de l’auteur pour chaque composant. D’autres documents peuvent également y être joints. Une déclaration VEX (Vulnerability Exploitability eXchange) indique si une vulnérabilité répertoriée affecte le produit, tandis qu’une attestation de provenance relie un artefact à la version qui l’a généré. Même en disposant de toutes ces informations, trois vérifications supplémentaires sont encore effectuées en dehors de ce cadre.
L'artefact correspond-il à sa source ?
La spécification de référence 2026 exige une valeur de hachage pour chaque artefact exécutable d’un composant ainsi qu’une signature de l’auteur de la SBOM. La valeur de hachage identifie l’artefact décrit, et la signature garantit que l’auteur déclaré a bien signé la SBOM et que celle-ci n’a pas été altérée par la suite. Aucune de ces deux informations ne compare l’artefact au dépôt source vers lequel pointe le projet. Si un compte de responsable piraté publie une version altérée, ou si un paquet du registre contient du code qui ne figure pas dans le dépôt du projet, la SBOM l’enregistre comme n’importe quelle autre entrée, avec une valeur de hachage correspondant au fichier que vous avez téléchargé.
La vérification de la conformité d’un artefact par rapport à son code source peut s’effectuer de différentes manières. Une attestation de provenance, par exemple, relie l’artefact à la compilation qui l’a produit. Une recompilation à partir du code source remplace l’artefact du registre par celui que vous avez compilé vous-même, de sorte que ce que vous distribuez ne contient que ce qui se trouve dans le référentiel. Ces deux méthodes présentent la même limite : elles permettent de vérifier si l’artefact correspond au code source, mais pas si ce dernier est « propre ». Un compte piraté ou un commit malveillant passerait ainsi l’une ou l’autre de ces vérifications.
Ce composant aurait-il dû être admis ?
Les « typosquats », l’usurpation d’espace de noms et les paquets présentant un comportement d’installation malveillant sont tous répertoriés comme n’importe quel autre paquet. Le rôle du SBOM est d’enregistrer ce qui a été résolu, et c’est ce qu’il a fait. La décision de résoudre ou non le paquet avait été prise auparavant, et la CRA considère cette décision comme un exercice de diligence raisonnable lors de l’intégration de composants tiers.
Certains écosystèmes exécutent du code de paquet lors de l'installation ou de la compilation. Un script de cycle de vie npm s'exécute lors de l'installation, un script Rust `build.rs` s'exécute lors de la compilation, et un hook de démarrage Python `.pth` peut exécuter du code à chaque démarrage de l'interpréteur. De nombreux pipelines génèrent la SBOM au moment de la compilation ou ultérieurement ; le paquet est donc documenté après avoir eu l'occasion de s'exécuter.
Y a-t-il un correctif, et qui va le développer ?
Une liste SBOM accompagnée de données consultatives vous indique qu’un composant présente une vulnérabilité connue. Un document VEX peut préciser si une vulnérabilité affecte votre produit, et le statut de prise en charge que les recommandations de la FDA conseillent d’enregistrer indique si le fournisseur en amont existe toujours pour y remédier. Tout cela décrit le problème, mais rien de tout cela ne génère de correctif.
Imaginez un composant de votre arborescence présentant une vulnérabilité connue dans une branche de version qui n’est plus maintenue en amont. Parfois, le projet est toujours actif sur une version majeure plus récente ; parfois, il a été purement et simplement abandonné. Dans tous les cas, vous pouvez mettre à niveau, remplacer ou appliquer un correctif à la version que vous utilisez. La mise à niveau n’est pas possible lorsqu’il n’existe pas de version corrigée, et elle n’est pas toujours sans risque même lorsqu’il y en a une. Le remplacement implique une réécriture de tout ce qui utilise ce composant, ce qui est d’autant plus difficile lorsque celui-ci est arrivé sous la forme d’une dépendance transitive que vous n’avez jamais choisie. Il ne reste donc plus qu’à appliquer un correctif à la version que vous utilisez. Quelqu’un doit écrire le correctif ou le rétroporter depuis la branche majeure la plus récente, si le projet y est toujours actif, puis vérifier que le comportement du composant reste compatible. C’est un travail pointu, et c’est un travail que l’amont ne va pas effectuer pour un composant qu’il ne maintient plus.
Mis côte à côte, les trois chèques se présentent comme suit.
| Vérifier | Quand il le faut | Ce qu'une SBOM peut contenir | Ce qu'il ne peut pas faire |
|---|---|---|---|
| L'artefact correspond à sa source | Avant que le paquet n'entre dans votre processus de compilation | Un hachage et une signature de l'auteur | Comparez l'artefact avec sa source |
| On peut considérer que ce composant est sans danger | Avant que le paquet n'entre dans votre processus de compilation | Nom, version et relations | Déterminez si l'exécution du paquet ne présente aucun risque. |
| Un correctif existe et est appliqué | Lorsqu'une faille de sécurité est détectée | État de la prise en charge et données VEX, le cas échéant | Créer ou appliquer un correctif |
À quoi ressemble le reste du travail ?
Chacune de ces trois vérifications correspond à une tâche que quelqu’un doit effectuer. La validation permet de déterminer si un paquet doit être accepté avant d’atteindre la machine d’un développeur ou un agent de compilation. La recompilation à partir du code source vous fournit un artefact qui correspond au code présent dans le référentiel du projet. La mise à jour continue permet de maintenir les composants à jour lorsque le développement en amont ralentit ou s’arrête.
D'après le SSDF : le cadre du NIST cite, à titre d'exemples concernant les composants tiers, la nécessité de les examiner avant leur utilisation, de vérifier que chacun d'entre eux fait toujours l'objet d'une maintenance, de prévoir des solutions pour ceux qui ne le sont plus, et de les compiler à partir du code source lorsque la provenance d'un binaire ne peut être confirmée.
La SBOM reste indispensable pour déterminer si l’on est concerné lorsqu’un avis de sécurité est publié. Elle ne permet de répondre correctement à cette question que si elle prend en compte les dépendances transitives et reflète fidèlement ce qui a effectivement été livré ; c’est l’une des raisons pour lesquelles il est préférable de la constituer selon la référence 2026 de la CISA plutôt que selon le seuil minimal fixé par la CRA.
Lorsque vous évaluez l’un des outils de sécurité de la chaîne logistique disponibles sur le marché, demandez-vous à quel stade du processus chacun d’entre eux intervient : avant que le paquet ne vous parvienne, pendant l’installation ou une fois l’artefact en place. De nombreux outils de cette catégorie fournissent des rapports sur ce qui existe déjà, et une attaque qui se produit pendant l’installation, la compilation ou le démarrage de l’interpréteur a déjà eu lieu au moment où le rapport est généré.
SecureChain de TuxCare intervient avant même que le paquet ne vous parvienne. Il analyse les paquets à la recherche de logiciels malveillants cachés et de code suspect, et bloque ceux qui ne passent pas l’analyse. Il recompile ensuite les paquets à partir du code source dans des environnements de compilation isolés. Pour les composants actifs, il corrige les vulnérabilités dans le cadre du SLA dès l’apparition de nouveaux CVE, et lorsque le développeur en amont cesse de maintenir un paquet, le service « Endless Lifecycle Support » (ELS) continue de fournir les correctifs. La couverture s’étend aux paquets JavaScript, Python, Java, Go, Rust et PHP.
Que faire une fois que la SBOM est établie ?
Les exigences relatives à la SBOM ont évolué à plusieurs reprises depuis 2021 ; considérez donc ce document comme un élément à régénérer à chaque version, et mettez en place en amont les contrôles permettant de réduire les risques. Si vous n’en disposez pas encore, créez-la en respectant les éléments de la norme CISA 2026, y compris les dépendances transitives. Si vous en possédez déjà une, vérifiez qu’elle va au-delà des dépendances de premier niveau et qu’elle reflète ce qui a réellement été livré. Si ce n’est pas le cas, générez-en un nouveau à partir de l’arborescence des dépendances résolues ou de l’artefact compilé, sans limite de profondeur, avant toute autre action. Comparez-le ensuite aux données des avis de sécurité, triez les composants vulnérables selon l’existence ou non d’un correctif en amont, puis décidez de la marche à suivre pour ceux qui n’en disposent pas. Vous pouvez remplacer le composant, faire appliquer un correctif à la version que vous utilisez ou consigner une acceptation explicite du risque.
Si votre SBOM continue de signaler des paquets dont personne n'assure la maintenance, découvrez comment SecureChain for Open Source bloque les paquets à risque avant qu'ils n'atteignent votre environnement et continue à leur appliquer des correctifs même après la fin du support en amont.
FAQ
Quelles sont les exigences relatives à la SBOM ?
Les exigences relatives à la nomenclature logicielle (SBOM) sont des règles qui obligent les éditeurs de logiciels à fournir une nomenclature logicielle, c'est-à-dire une liste des composants d'un produit. Les principales d’entre elles sont la section 524B de la FDA relative aux dispositifs médicaux, en vigueur depuis 2023 ; la loi européenne sur la cyber-résilience, qui entrera en vigueur le 11 décembre 2027 ; et les conditions fédérales en matière de marchés publics que les agences américaines fixent désormais au cas par cas, pour chaque contrat. Les « éléments minimaux » de 2026 définis par la CISA précisent les champs de données de base.
Existe-t-il toujours une obligation fédérale concernant la SBOM ?
Le décret présidentiel n° 14028, qui fournissait des orientations concernant la remise d’une SBOM aux acheteurs, reste en vigueur. Le Bureau de la gestion et du budget (OMB) a abrogé, le 23 janvier 2026, les notes de service exigeant des attestations de sécurité des logiciels (M-22-18 et M-23-16). Les agences américaines peuvent toujours exiger une SBOM dans les clauses contractuelles ; votre obligation de fournir une telle liste dépend donc de l’acheteur.
Quelles sont les exigences de la FDA en matière de SBOM pour les dispositifs médicaux ?
L'article 524B de la loi FD&C exige qu'une liste des composants logiciels (SBOM) couvrant les logiciels commerciaux, open source et prêts à l'emploi soit incluse dans les dossiers de demande d'autorisation de mise sur le marché des dispositifs cybernétiques, c'est-à-dire les dispositifs dotés d'un logiciel capable de se connecter à Internet et susceptibles d'être vulnérables aux cybermenaces. Les recommandations de la FDA de février 2026 préconisent également d'indiquer le statut de prise en charge de chaque composant ainsi que la date de fin de prise en charge.
Quelles sont les exigences de la CRA en matière de SBOM ?
La loi européenne sur la cyber-résilience (CRA) impose aux fabricants de produits comportant des éléments numériques d’établir une liste des composants logiciels (SBOM) dans un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de premier niveau. Cette obligation s’applique à compter du 11 décembre 2027, et les autorités de surveillance du marché peuvent demander la SBOM, en motivant leur demande, afin de vérifier la conformité. La CRA impose également aux fabricants de corriger sans délai les vulnérabilités de leurs produits et composants.
Comment vous conformez-vous aux exigences du NIST en matière de SBOM ?
Le NIST ne définit pas les éléments de données de la SBOM. Ceux-ci proviennent des « éléments minimaux 2026 » de la CISA, qui ont remplacé la référence de 2021 établie par l’Administration nationale des télécommunications et de l’information (NTIA), une agence du ministère américain du Commerce. Le rôle du NIST consiste à fournir des recommandations en matière de processus dans le cadre du « Secure Software Development Framework » (SP 800-218) ; la conformité implique donc généralement d’aligner ses pratiques de développement sur ce cadre, de produire une SBOM conforme aux éléments définis par la CISA et de la mettre à jour à chaque nouvelle version.
Une SBOM rend-elle les logiciels plus sûrs ?
Pas en soi. Une SBOM répertorie les composants présents dans le logiciel, ce qui vous aide à réagir lorsqu’une vulnérabilité est signalée. Elle ne vérifie pas si un paquet correspond à sa source, ne détermine pas s’il aurait dû être installé et ne fournit pas de correctif.
Que pouvez-vous faire face à un composant présentant une vulnérabilité mais pour lequel aucun correctif n'est disponible en amont ?
Vous pouvez remplacer le composant ou appliquer un correctif à la version que vous utilisez. Le remplacement peut impliquer une réécriture, tandis que l'application d'un correctif signifie que quelqu'un doit rédiger et tester la solution, puisqu'aucune version en amont n'en propose. Un fournisseur proposant un support étendu pour les paquets open source en fin de vie peut fournir ce correctif. Le fait de répertorier le composant dans une SBOM permet de documenter la vulnérabilité sans la modifier.
