La cybersécurité de la CISA relève le niveau de référence des SBOM, mais de meilleurs inventaires laissent encore des failles de sécurité

Les recommandations de cybersécurité de la CISA ont remplacé un niveau de référence fédéral vieux de cinq ans pour les nomenclatures logicielles, malgré des doutes persistants quant à la capacité des organisations à les utiliser efficacement.

La Cybersecurity and Infrastructure Security Agency a publié les Minimum Elements for a Software Bill of Materials 2026 avec la National Security Agency, le Federal Bureau of Investigation et des partenaires internationaux. Ces recommandations mettent à jour le cadre publié en 2021 par la National Telecommunications and Information Administration.

Un SBOM, ou nomenclature logicielle, est un inventaire lisible par machine des composants et des relations au sein d’un produit logiciel. Il peut indiquer à une organisation si une vulnérabilité nouvellement divulguée apparaît quelque part dans ses applications ou son infrastructure.

Ce remplacement est important, car le cadre de 2021 a été rédigé à une époque où les outils de SBOM se concentraient surtout sur la génération d’inventaires. Les systèmes actuels échangent, combinent, valident et analysent également ces inventaires à travers les pipelines de développement et les environnements clients.

Cette transition crée la tension centrale qui sous-tend les nouvelles recommandations. La CISA souhaite des données plus riches et plus cohérentes que les machines peuvent traiter, mais l’ajout de champs ne garantit pas que l’inventaire obtenu soit complet ou exploitable.

Le niveau de référence initial de la NTIA a contribué à établir un vocabulaire commun. Le nouveau cadre de cybersécurité de la CISA demande aux producteurs et aux consommateurs de logiciels de traiter les SBOM comme des données opérationnelles de sécurité plutôt que comme des documents statiques de conformité.

La cybersécurité de la CISA remplace le niveau de référence SBOM de 2021

Le changement le plus important est institutionnel et opérationnel : la CISA est désormais responsable d’un niveau de référence plus étendu, conçu pour la gestion courante des risques logiciels.

La NTIA a publié les éléments minimums initiaux le 12 juillet 2021, à la suite de l’Executive Order 14028. Son cadre répartissait un SBOM acceptable en trois catégories : les champs de données, la prise en charge de l’automatisation, et les pratiques et processus.

Les sept champs de données initiaux couvraient le nom du fournisseur, le nom du composant, la version, les identifiants uniques, les relations de dépendance, l’auteur du SBOM et un horodatage. Les exigences d’automatisation encourageaient les formats lisibles par machine, tandis que les pratiques opérationnelles portaient sur la fréquence de génération, la distribution, l’accès, la profondeur et les lacunes connues.

Ces éléments étaient volontairement modestes. Ils définissaient le plus petit inventaire utile à une époque où de nombreux fournisseurs n’avaient jamais généré de SBOM.

La publication de 2026 met à jour et remplace ce cadre. Elle fait suite à une consultation publique ouverte par la CISA en août 2025 et clôturée le 3 octobre 2025.

L’avis d’appel à commentaires indiquait que les outils de SBOM s’étaient étendus au-delà de la génération aux fonctions de partage, d’analyse et de gestion. Il relevait également une participation croissante des communautés open source, des gouvernements et d’autres secteurs.

La CISA n’a pas créé de règle fédérale contraignante en matière d’achats publics par le biais de ces recommandations. Les éléments minimums restent un niveau de référence pour générer et demander des SBOM utilisables, et non une nouvelle loi ou une obligation universelle.

Cette distinction est importante pour les fournisseurs. Un client peut adopter le cadre dans un contrat ou un processus d’achat, mais la publication à elle seule n’oblige pas toutes les entreprises de logiciels à produire un SBOM.

Le champ d’application envisagé reste néanmoins vaste. Le cadre peut s’appliquer aux logiciels acquis ou développés par des organismes publics, y compris les composants open source, les logiciels en tant que service et les logiciels impliquant l’intelligence artificielle.

La CISA reconnaît également que les services complexes peuvent nécessiter des informations allant au-delà du minimum général. Une plateforme SaaS évolue en continu, tandis qu’un système d’IA peut dépendre de modèles, d’ensembles de données, de cadres et de services externes qui ne ressemblent pas aux packages conventionnels.

Des recommandations distinctes axées sur l’IA, publiées en 2026, traitent certaines de ces différences. Les éléments minimums généraux du SBOM restent le point de départ sous-jacent à ces inventaires spécialisés.

Les agences établissent donc un socle commun, sans décrire chaque chaîne d’approvisionnement logicielle possible. Les organisations ont toujours besoin de politiques adaptées à leurs architectures, à leurs risques et à leurs obligations réglementaires.

Il s’agit d’une évolution plus conséquente qu’une liste de champs plus longue. Elle fait passer la discussion sur les SBOM de la définition d’un document au maintien de preuves partagées sur la composition des logiciels.

Les nouveaux éléments minimums exigent davantage de contexte

Le nom et la version d’un composant ne suffisent plus lorsque les équipes de sécurité doivent distinguer des packages, vérifier des artefacts et relier des résultats entre différents outils.

Le niveau de référence de 2026 préserve la structure en trois parties établie par la NTIA. Il couvre toujours les champs de données, les formats traitables par machine ainsi que les pratiques utilisées pour créer, mettre à jour et échanger un SBOM.

Cependant, le modèle mis à jour demande un contexte plus riche autour du logiciel comme de l’inventaire lui-même. Le processus d’élaboration a mis en avant quatre ajouts : les hachages de composants, les informations de licence, l’identification des outils et le contexte de génération.

Un hachage de composant est une valeur cryptographique calculée à partir du contenu logiciel. Il peut aider un consommateur à distinguer des artefacts partageant un même nom et une même version, mais contenant des octets différents.

Cette distinction est importante lorsque les fournisseurs reconstruisent des packages, appliquent des correctifs privés ou distribuent des binaires propres à une plateforme. Une chaîne de version peut rester inchangée même si l’artefact réel diffère.

Les hachages ne constituent toutefois pas un système d’identité universel. Les résultats dépendent de l’objet haché, de la compression éventuelle de cet objet et de la manière dont le processus de compilation empaquette ses fichiers.

La Business Software Alliance a soulevé ce point lors de la consultation. Sa réponse sectorielle soutenait que le hachage peut fournir une validation utile, mais nécessite des définitions plus claires pour les archives, les fichiers extraits, les firmwares et d’autres formes de logiciels.

Les informations de licence ajoutent une autre dimension. Elles aident les organisations à identifier les conditions associées aux composants, y compris les dépendances open source et propriétaires.

Les données de licence soutiennent l’examen juridique et la gouvernance des composants, mais elles améliorent aussi l’identification de base. Deux packages aux noms similaires peuvent être assortis de conditions de propriété ou de distribution différentes.

Le nom de l’outil indique quel système a généré le SBOM. Ce champ permet aux consommateurs d’examiner des résultats incohérents et de comprendre pourquoi deux scanners décrivent différemment le même artefact.

Le contexte de génération décrit la manière dont l’inventaire a été produit. Un SBOM créé à partir du code source peut détecter des composants différents de ceux relevés à partir d’une image de conteneur, d’un système installé ou d’un binaire final.

Cette provenance influe sur ce qu’une équipe de sécurité doit déduire de données manquantes. Une analyse du code source peut identifier des dépendances déclarées qui n’entrent jamais dans une compilation de production. Une analyse binaire peut trouver du code intégré que le manifeste du package a omis.

Le cadre mis à jour précise également les champs établis. Les identifiants uniques sont importants, car les systèmes automatisés de gestion des vulnérabilités ne peuvent pas corréler de manière fiable un nom de package en texte libre avec des enregistrements de sécurité.

Les Package URLs, les identifiants Common Platform Enumeration et les balises SWID offrent des moyens structurés d’identifier les logiciels. Aucun schéma unique ne couvre tous les composants ; les producteurs doivent donc choisir des identifiants adaptés à l’écosystème disponible.

Les relations de dépendance restent centrales. Un inventaire devient plus utile lorsqu’il montre comment un composant inclut ou dépend d’un autre, plutôt que de présenter chaque élément comme une ligne sans lien avec les autres.

Les éléments minimums de 2021 exigeaient déjà des informations sur les dépendances. Les recommandations actuelles accordent davantage de poids opérationnel à cette exigence, car le triage des vulnérabilités s’appuie de plus en plus sur des graphes de relations.

Les pratiques mises à jour préservent également le concept des « inconnues connues ». Les producteurs doivent identifier les domaines dans lesquels les outils disponibles ne peuvent pas déterminer si des dépendances supplémentaires existent.

Cette formulation évite une hypothèse dangereuse. L’absence d’une relation peut signifier qu’aucune dépendance n’existe, ou que le générateur n’a pas pu la détecter.

La différence est cruciale pendant la réponse à un incident. Les équipes de sécurité doivent savoir si un résultat de recherche négatif représente une preuve d’absence ou simplement une visibilité incomplète.

La CISA demande en pratique aux producteurs d’associer un niveau de confiance et un contexte à leurs inventaires. Cela rend un SBOM moins ordonné, mais rend aussi les données plus honnêtes.

Les fournisseurs de logiciels font face à une charge de preuve plus élevée

Le nouveau niveau de référence pousse les fournisseurs à produire des preuves de sécurité reproductibles, tandis que les acheteurs doivent créer des systèmes capables de les interpréter.

Pour les producteurs de logiciels, un SBOM ne peut plus être considéré comme un fichier généré une seule fois avant une évaluation commerciale. Il doit accompagner le produit au fil des versions, des reconstructions, des changements de dépendances et des divulgations de vulnérabilités.

Cela exige une intégration avec les systèmes de développement et de livraison. Un producteur doit générer l’inventaire suffisamment près du processus de compilation pour qu’il décrive l’artefact que les clients reçoivent réellement.

Les équipes ont également besoin d’identifiants de composants stables. Si une même dépendance reçoit des identifiants différents lors de compilations successives, la comparaison automatisée et l’échange d’informations sur les vulnérabilités deviennent peu fiables.

La divulgation de l’outil et le contexte de génération créent une attente connexe. Les producteurs doivent comprendre le fonctionnement de leurs scanners, les sources qu’ils inspectent et les limites de leur visibilité.

Cela peut révéler des lacunes inconfortables. Une entreprise peut découvrir que son scanner de compilation capture les manifestes de packages, mais manque les plugins chargés dynamiquement, les firmwares intégrés, les fichiers sources copiés ou les binaires propriétaires.

Les équipes d’ingénierie sont alors confrontées à un choix pratique. Elles peuvent améliorer le pipeline, documenter la zone inconnue ou obtenir de meilleures données de composition auprès d’un fournisseur en amont.

Ce travail va au-delà des spécialistes de la sécurité. Les équipes achats ont besoin de clauses contractuelles pour recevoir des SBOM, les équipes juridiques ont besoin de règles de distribution, et les équipes produit ont besoin de processus pour informer les clients.

Les organisations qui gèrent de nombreuses applications ont également besoin d’un stockage interrogeable. Recevoir des milliers de documents JSON sans indexer leurs composants produit de la paperasse, et non une visibilité opérationnelle.

La charge pèse donc autant sur les acheteurs que sur les vendeurs. Les acheteurs doivent normaliser différents fichiers, protéger des données potentiellement sensibles, surveiller les nouvelles vulnérabilités et décider quelles conclusions justifient une action.

Une correspondance brute de composant n’établit pas automatiquement une exposition. Le code vulnérable peut être exclu de la compilation, désactivé par la configuration ou inaccessible dans des conditions d’exploitation normales.

Le Vulnerability Exploitability eXchange, ou VEX, peut fournir des déclarations lisibles par machine sur la question de savoir si un produit est affecté par une vulnérabilité. Ces déclarations dépendent d’identifiants stables reliant l’enregistrement VEX au bon composant du SBOM.

Cette relation explique pourquoi la qualité des identifiants est devenue plus importante. Un enregistrement de composant ambigu affaiblit chaque tentative ultérieure de décrire l’exploitabilité ou la remédiation.

Elle montre également pourquoi les éléments minimums de la CISA ne peuvent pas fonctionner seuls. Les organisations ont besoin autour de l’inventaire de bases de données de vulnérabilités, de données VEX, d’informations sur la propriété des actifs, de contexte d’exécution et de flux de réponse.

Les sous-traitants fédéraux ressentiront la pression en premier, car les agences peuvent intégrer cette base de référence dans les exigences d’acquisition. Les clients d’entreprise sont également susceptibles de reprendre les mêmes questions pour leurs évaluations de fournisseurs.

L’alignement international amplifie cet effet. Un fournisseur présent sur plusieurs marchés gagne à produire un inventaire interopérable unique plutôt qu’à maintenir des versions nationales distinctes.

Cependant, l’harmonisation ne réduit la charge que lorsque les clients interprètent la base de référence de manière cohérente. Des champs, formats et règles de livraison supplémentaires propres à chaque contrat peuvent recréer la fragmentation que les éléments minimaux visent à éviter.

Les équipes logicielles devraient donc considérer ces orientations comme un contrat de données. Les producteurs promettent un niveau de visibilité défini, et les consommateurs s’engagent à traiter ces données de manière responsable.

Une base de connaissances d’ingénierie peut aider les équipes à relier les décisions relatives aux SBOM aux enregistrements de build, à la documentation des fournisseurs et aux notes de remédiation. Elle ne remplace pas une plateforme d’analyse des composants, mais elle peut conserver le raisonnement qui entoure chaque réponse.

L’exigence accrue en matière de preuves n’est pas intrinsèquement négative. Des inventaires reproductibles peuvent raccourcir la recherche des produits concernés lorsqu’une dépendance largement utilisée devient vulnérable.

Le bénéfice n’apparaît qu’une fois que les organisations relient la génération à la responsabilité et à l’action. Sinon, le SBOM amélioré devient une pièce jointe supplémentaire que personne n’examine avant le début d’un audit.

De meilleures données SBOM ne peuvent toujours pas garantir une meilleure sécurité

La base de référence enrichie de CISA améliore les données d’entrée de la gestion des vulnérabilités, mais des graphes de dépendances incomplets peuvent encore produire des conclusions dangereusement trop confiantes.

Un préprint de juillet 2026 a examiné 78 612 fichiers SBOM issus d’un jeu de données public, dont 77 092 pouvaient être analysés. Les chercheurs se sont concentrés sur les arêtes de dépendance plutôt que de vérifier simplement la présence de champs de composants.

Leur étude sur les graphes de dépendances a révélé que 52,9 % des SBOM analysables ne déclaraient aucune arête de dépendance. Chaque composant de ces fichiers apparaissait isolé.

8,8 % supplémentaires contenaient un bloc de dépendances, mais laissaient la plupart des composants déconnectés. Parmi les inventaires plus importants de ce groupe, la part médiane de composants orphelins était de 93 %.

Seuls 38,3 % de la population totale formaient des graphes bien connectés. L’étude a également constaté que la qualité des graphes variait fortement selon le générateur, même lorsque les outils examinaient des logiciels comparables.

Ces résultats proviennent d’un préprint et ne doivent pas être considérés comme une mesure universelle des inventaires d’entreprises privées. Ils illustrent néanmoins le problème de mise en œuvre qui sous-tend l’accent mis par CISA sur les relations de dépendance et les inconnues connues.

Un inventaire plat peut répondre à la question de savoir si le nom d’un paquet apparaît quelque part. Il ne peut pas expliquer de manière fiable quelle application le contient, ce qui en dépend, ou si un chemin mène au code vulnérable.

Cette limite affecte la priorisation. Certains systèmes de sécurité masquent un signalement lorsque le SBOM n’indique aucun chemin entre le produit et le composant concerné.

Si le graphe est incomplet, « aucun chemin » ne signifie pas « non atteignable ». Cela signifie que l’inventaire ne contient pas les preuves reliant les nœuds.

L’étude a testé une approche qui convertissait les résultats négatifs suspects en un état explicite d’incertitude. Dans son expérience contrôlée de réévaluation, le rappel par rapport au catalogue Known Exploited Vulnerabilities de CISA est passé de 0,600 à 0,950.

Ces chiffres décrivent le système des chercheurs, et non un résultat garanti pour chaque organisation. La leçon sous-jacente est plus large : l’incertitude doit rester visible tout au long du processus d’analyse.

C’est là que la conformité minimale peut diverger de la sécurité opérationnelle. Un fichier peut contenir tous les champs nommés tout en donnant une représentation erronée du produit en raison d’une découverte superficielle ou de relations rompues.

Les hachages de composants ont également leurs limites. Un hachage peut vérifier que deux objets sont identiques, mais il n’explique pas si l’objet contient du code vulnérable ou reçoit des entrées non sûres.

Les champs de licence n’établissent pas non plus la sécurité. Ils améliorent la gouvernance des composants, mais identifier correctement une licence ne dit rien sur l’exploitabilité.

Les noms d’outils et le contexte de génération aident les consommateurs à évaluer la qualité des preuves, mais seulement s’ils comprennent les outils. Indiquer « analyse du code source » est utile lorsque le système destinataire la traite différemment d’une analyse d’artefact post-build.

Les SBOM peuvent également révéler des informations sensibles. Des inventaires détaillés de composants peuvent exposer des choix d’architecture, d’anciennes dépendances ou des cibles qu’un attaquant peut étudier.

Les organisations ont besoin de politiques de diffusion qui équilibrent l’accès et le risque. Un projet open source public, un dispositif médical réglementé et un système gouvernemental restreint ne nécessitent pas des modèles de partage identiques.

La fraîcheur des données constitue un autre défi. Un inventaire exact devient trompeur après une modification du logiciel, à moins que les producteurs ne le régénèrent et que les consommateurs ne l’associent à la version correcte.

Les services cloud compliquent cette association, car leurs composants déployés peuvent changer sans qu’un client télécharge un nouveau paquet. Les services continus nécessitent des pratiques de mise à jour et de notification que les inventaires statiques de produits ne fournissent pas.

Les systèmes d’IA introduisent une ambiguïté supplémentaire. Les modèles, jeux de données, adaptateurs, API distantes, cadres d’orchestration et bibliothèques conventionnelles peuvent tous influencer le comportement, sans que chaque élément corresponde aux champs de composants traditionnels.

La nouvelle base de référence reconnaît que les systèmes spécialisés nécessitent des informations supplémentaires. Elle ne règle pas toutes les questions concernant l’inventaire d’un pipeline de modèles évolutif ou d’une dépendance hébergée en externe.

Ces limites ne rendent pas les SBOM inutiles. Elles définissent la frontière entre visibilité et assurance.

Une liste d’ingrédients peut aider à identifier un ingrédient faisant l’objet d’un rappel, mais elle ne peut pas prouver que la cuisine a suivi des procédures sûres. Le développement sécurisé, les tests, les correctifs, la surveillance et la réponse aux incidents restent nécessaires.

La lecture la plus solide des orientations n’est donc pas « davantage de champs équivaut à un logiciel sécurisé ». Elle est : « de meilleures preuves favorisent de meilleures décisions lorsque les organisations préservent leur contexte et leur incertitude ».

L’alignement international relève les enjeux

Le soutien conjoint fait de la mise à jour de CISA un point de référence susceptible d’influencer les achats de logiciels bien au-delà du gouvernement fédéral américain.

Les chaînes d’approvisionnement logicielles traversent les frontières nationales. Un produit conçu dans un pays peut contenir des paquets open source maintenus dans plusieurs autres et fonctionner sur une infrastructure exploitée ailleurs.

Des définitions SBOM différentes créent des frictions tout au long de cette chaîne. Les producteurs doivent traduire des champs, régénérer des fichiers ou expliquer pourquoi les données exigées par un client n’existent pas dans un autre format.

Les partenaires internationaux travaillent à une vision commune de ce que les SBOM doivent accomplir. Leur participation aux orientations de 2026 renforce l’argument en faveur de données minimales communes et d’échanges lisibles par machine.

Cet alignement ne crée pas une loi mondiale unique. Chaque gouvernement conserve ses propres règles d’acquisition, son autorité réglementaire et son calendrier d’application.

Il peut néanmoins façonner les contrats et les attentes techniques. Les acheteurs adoptent souvent le langage des orientations gouvernementales, car il fournit une base de référence défendable lors des évaluations de fournisseurs.

Le Cyber Resilience Act de l’Union européenne ajoute une urgence pour les fabricants qui vendent des produits comportant des éléments numériques. Ses exigences créent un cadre juridique distinct, mais l’inventaire logiciel et le traitement des vulnérabilités occupent un terrain opérationnel similaire.

Les fabricants de dispositifs médicaux font face à un autre cas d’usage déjà établi. La législation américaine exige que les fabricants de certains dispositifs cybernétiques fournissent un SBOM et des processus de traitement des vulnérabilités après commercialisation.

Les opérateurs d’infrastructures critiques ont également besoin de réponses rapides lorsqu’une bibliothèque courante ou un composant intégré devient une cible. Leur défi n’est souvent pas d’identifier une dépendance, mais de la localiser dans des systèmes durables fournis par plusieurs fournisseurs.

Une base de référence commune n’aide que si les fournisseurs en amont participent. Le producteur d’une application finale ne peut pas toujours identifier le contenu d’un binaire fermé reçu d’une autre entreprise.

Les exigences contractuelles peuvent pousser cette demande plus profondément dans la chaîne d’approvisionnement. Elles peuvent également désavantager les petits fournisseurs dépourvus d’équipes dédiées à la conformité et à l’ingénierie de sécurité.

L’accent mis par CISA sur l’automatisation vise à réduire cette charge. Les outils de développement modernes peuvent générer des inventaires pendant les builds, et les formats communs permettent aux systèmes en aval de les traiter sans transcription manuelle.

L’automatisation peut aussi amplifier les erreurs. Si un scanner omet systématiquement des dépendances, chaque SBOM généré peut reproduire le même angle mort avec une impressionnante constance.

Les tests d’interopérabilité importent donc autant que le choix du format. Les producteurs devraient comparer les résultats, valider les graphes de relations et confirmer que les outils en aval préservent correctement les identifiants.

Les consommateurs ont besoin d’une discipline réciproque. Ils devraient définir comment les données SBOM influencent les achats, la surveillance, la remédiation et la communication avec les fournisseurs avant de les exiger à grande échelle.

La Business Software Alliance a soutenu des attentes harmonisées lors de la consultation de 2025. Elle a également mis en garde contre les exigences d’acquisition lorsque les destinataires n’ont pas la capacité d’ingérer les informations et d’agir sur elles.

Cette position résume le principal compromis de politique publique. Exiger des preuves peut encourager une meilleure ingénierie, mais collecter des preuves inutilisables gaspille des ressources et crée un faux sentiment de contrôle.

L’alignement international relève les enjeux, car une pratique faible peut se diffuser aussi facilement qu’une bonne pratique. Une base de référence reconnue mondialement devrait encourager des inventaires cohérents et utiles, plutôt qu’une paperasse cohérente à l’échelle mondiale.

Trois signaux montreront si la base de référence de 2026 fonctionne

Les orientations ne réussiront que si la qualité des dépendances s’améliore, si les acheteurs opérationnalisent les données et si les pratiques SBOM spécialisées restent interopérables.

Le premier signal est une amélioration mesurable des graphes de dépendances. Les études futures devraient constater moins d’inventaires plats, moins de composants déconnectés et une plus grande utilisation d’indicateurs explicites d’exhaustivité.

Ce résultat renforcerait la prémisse de CISA selon laquelle des éléments minimaux plus clairs peuvent améliorer les décisions de vulnérabilité assistées par machine. La persistance des défaillances de graphes montrerait que les définitions seules ne peuvent pas corriger le comportement des générateurs.

Le deuxième signal est la manière dont les agences fédérales et les acheteurs d’entreprise modifient leurs achats. Une adoption utile reliera la livraison de SBOM à la validation, à la responsabilité des actifs, au traitement des VEX et aux attentes de réponse.

Les demandes qui ajoutent simplement un champ de téléversement à un questionnaire affaibliront l’argument. Elles augmentent le travail des fournisseurs sans améliorer la rapidité ni la qualité des décisions de sécurité.

Le troisième signal est l’interopérabilité entre les inventaires conventionnels, cloud et d’IA. Les orientations spécialisées devraient étendre la base de référence commune sans créer de définitions incompatibles pour les identifiants, les relations ou les horodatages.

Un alignement réussi permettrait à une organisation de suivre un paquet conventionnel vulnérable à travers un service cloud ou une application d’IA. Des schémas fragmentés recréeraient les lacunes de visibilité que la mise à jour de 2026 cherche à combler.

Les producteurs de logiciels n’ont pas besoin d’attendre ces résultats. Ils peuvent examiner leurs inventaires actuels, identifier la manière dont chacun a été généré et tester si les relations survivent à leur ingestion dans des systèmes destinés aux clients.

Les acheteurs peuvent effectuer le même exercice de l’autre côté. Demandez si une vulnérabilité nouvellement divulguée peut être retracée depuis un enregistrement de composant jusqu’à un produit concerné, un responsable, une décision et un état de remédiation.

Ce flux de travail constitue le véritable test des orientations de cybersécurité de CISA. Si votre organisation recevait aujourd’hui un SBOM exact, pourrait-elle transformer ces preuves en une décision de sécurité prise en temps utile ?

Commencez par un produit important et suivez les données, de la compilation jusqu’à la réponse. Les maillons manquants révéleront si votre programme SBOM constitue un contrôle opérationnel ou seulement une archive d’inventaire.