Summary

  • Dans GAO-26-107530, des responsables de 17 agences fédérales sur 24 ont déclaré que les orientations de l'OMB et du NIST compliquaient la collecte et la conservation des nomenclatures logicielles (SBOM). Il s'agit de difficultés rapportées pour les achats, pas d'un nombre d'incidents ou de logiciels vulnérables.
  • Le GAO oppose l'ancienne approche OMB M-22-18, où la collecte était facultative et le SBOM traité comme pièce statique, aux données par version encouragées par le NIST pour gérer les vulnérabilités. L'OMB a abrogé M-22-18 en janvier 2026 ; M-26-05 permet désormais à chaque agence de demander par contrat un SBOM actuel, sur requête.
  • Le GAO demande à la Cybersecurity and Infrastructure Security Agency (CISA) des instructions pratiques sur la production, la réception et l'analyse des données de composants dans les achats, le développement et la gestion des risques. Le contrôle utile est le chemin de la liste jusqu'à une décision de sécurité attribuable.

Une liste qui s'arrête au dossier ou rejoint la machine

La nomenclature d'un logiciel décrit les composants qui entrent dans une version. Pour les achats, elle peut devenir une pièce que le fournisseur remet et que l'agence classe. Pour les équipes de sécurité, elle peut être une table de correspondance : un composant est signalé comme vulnérable, quels logiciels en service le contiennent ? Le premier usage s'achève au dépôt du fichier. Le second exige une version précise, des données exploitables, un responsable et une action.

Le rapport du GAO publié le 23 juin 2026 a demandé aux responsables informatiques et des achats de 24 agences comment ils se procuraient des services cloud. Dans 17 d'entre elles, les responsables ont signalé un conflit entre les consignes de l'OMB et du NIST sur la collecte et le stockage des SBOM. Ce décompte décrit des difficultés exprimées par les administrations. Il ne décrit ni 17 failles ni 17 agences incapables de se protéger. L'audit mentionne aussi 17 agences rencontrant des problèmes de maîtrise des coûts du cloud : même chiffre, autre question.

Le rapport intégral du GAO précise pourquoi les instructions se frottaient l'une à l'autre. L'ancienne circulaire OMB M-22-18 laissait la collecte facultative; le NIST invitait les producteurs à suivre et communiquer les composants de chaque version. L'OMB demandait aux agences de construire leur propre processus de collecte; le NIST orientait les producteurs vers des formats de données normalisés. L'OMB voyait surtout une pièce de conformité, là où le NIST voyait une source pour l'analyse des vulnérabilités et la gestion du risque.

Ces différences ont des effets prosaïques. Cinq agences ont expliqué que des formulaires et méthodes distincts d'une administration à l'autre compliqueraient la tâche des fournisseurs communs. Cinq autres réponses ont décrit la difficulté d'obtenir les SBOM auprès des producteurs, notamment quand l'achat passe par un revendeur sans relation directe avec le fabricant du logiciel. Les deux groupes peuvent se recouper. L'enjeu commun est la chaîne de possession de la donnée : qui produit la liste, sous quel format, pour quelle version et qui peut la réclamer après la signature du contrat ?

Le texte de janvier a changé la règle, pas la tâche

L'OMB M-26-05 daté du 23 janvier 2026 a abrogé M-22-18 et sa circulaire complémentaire M-23-16. L'ancienne règle sert donc à comprendre l'audit, pas à définir une obligation encore en vigueur. Le nouveau texte maintient la responsabilité du chef d'agence en matière de sécurité matérielle et logicielle, ainsi que l'exigence d'inventaires complets. Il permet à chaque agence d'inscrire dans un contrat la fourniture d'un SBOM actuel sur demande. Pour une plateforme cloud, le contrat devrait viser l'environnement de production en fonctionnement.

Cette liberté donne aussi un propriétaire au choix. Un service acheteur peut ajuster sa demande au risque du logiciel. Mais s'il choisit d'obtenir des SBOM, il doit dire quand la donnée peut être demandée, comment elle parvient à l'agence et qui l'utilise. Le GAO juge que la circulaire de janvier clarifie les responsabilités sans résoudre ces questions pratiques. Un fichier facultatif arrivé trop tard ou sous une forme illisible n'aide pas beaucoup à décider quoi faire lorsqu'une vulnérabilité touche un composant.

Les orientations du NIST sur la chaîne logicielle placent les informations de composants au sein d'une pratique de sécurité. La vision commune publiée par la CISA en septembre 2025 veut que génération, consommation et analyse soient intégrées à la gestion des risques et au développement. Le GAO relève que cette vision ne fournissait pas encore aux agences les consignes précises pour relier la donnée à leurs outils et procédures. Une destination indiquée sur une carte n'est pas un itinéraire praticable.

La jonction a été confiée à la CISA

Le GAO recommande au Department of Homeland Security de charger la CISA d'instructions supplémentaires : comment intégrer production, réception et analyse des SBOM aux achats, au développement et à la gestion du risque, avec les outils appropriés. Le ministère a accepté. Dans sa réponse, il visait le 30 septembre 2026 pour achever les travaux. Ce calendrier est une prévision de l'administration; la page publique de la recommandation restait marquée « Open » lors de la vérification de cette enquête. Une date prévue n'est pas un manuel effectivement appliqué.

Le manuel utile commencerait par la version ou l'environnement réel décrit. Il préciserait le délai d'accès à la liste, y compris quand un intermédiaire vend le produit, son format, sa mise à jour, la comparaison avec les données de vulnérabilité et le propriétaire de la décision qui suit. L'OMB fixe le choix politique, le NIST expose la pratique technique, la CISA doit fournir la jointure opérationnelle. Les agences et les producteurs ont besoin d'une réponse commune au moment où le fichier change de mains.

Une instruction de la CISA qui nomme ces passages, suivie de contrats et de procédures montrant des données actuelles réellement reçues et analysées, changerait l'appréciation. Le GAO a déjà obtenu le signal : dix-sept agences disent que les consignes se contredisent là où elles doivent acheter et protéger le même logiciel. Une liste de pièces détachées ne devient un outil de sécurité qu'une fois reliée à la machine qu'elle décrit.

Sources