Comment promouvoir l'application de la nomenclature logicielle à l'ère post-« élément minimum »

Cet article prend environ 15 minutes pour lire 5978 mots

La nomenclature logicielle (SBOM) est un document qui enregistre des informations telles que la composition du logiciel afin d'améliorer la transparence de la chaîne d'approvisionnement. Il est d'une grande importance pour réduire la charge de travail et la difficulté de maintenance et de garantie de la chaîne d'approvisionnement. Ces dernières années, alors que la sécurité de la chaîne d'approvisionnement en logiciels est devenue le centre d'attention, en particulier après la publication du décret américain EO 14028, la poursuite du SBOM a également montré une tendance brûlante.

En raison de certaines difficultés et résistances dans le processus d'utilisation et de promotion du SBOM, la réflexion des praticiens sur le SBOM a également commencé à revenir à la rationalité. Vincent Danen, vice-président de la sécurité des produits chez Red Hat, a déclaré que selon les données statistiques du "2022 Software Bill of Materials and Network Security Report", SBOM n'est utile que lorsqu'il est utilisé , et le seul fait d'exiger une génération ne résout pas le problème. L'orientation future du SBOM est de centraliser les données et de créer des données SBOM. Il doit travailler pour piloter son utilisation.

Cet article prend comme point d'entrée le goulot d'étranglement des applications rencontré dans « SBOM Minimal Elements », et résume et analyse les efforts d'organisations telles que la Cybersecurity and Infrastructure Security Agency (CISA) des États-Unis et l'Open Source Security Foundation (OpenSSF) pour promouvoir la « utilisation » et « praticabilité » du SBOM. », Idées, mesures et progrès « applicables », et proposer des suggestions correspondantes basées sur l'état actuel des travaux du SBOM dans mon pays.

1. L’« élément minimum » n’est pas réellement « petit »

Les « Éléments minimaux du SBOM » publiés par la National Telecommunications and Information Administration (NTIA) sont l'un des résultats importants du guide requis par l'EO 14028, qui a attiré une large attention. Cependant, Chainguard, un fournisseur de services de sécurité de la chaîne d'approvisionnement en logiciels, a mentionné dans un rapport d'analyse sur les résultats de détection de plus de 3 000 fichiers SBOM publiés en janvier 2023 que seulement 1 % des fichiers SBOM répondent aux exigences des « éléments minimaux », et un grand Il existe un certain nombre de fichiers SBOM. Données manquantes sur les fournisseurs de composants, impossibilité de spécifier les noms ou les versions de tous les composants, etc. De ce point de vue, l'exigence d'« éléments minimaux » semble constituer un seuil plus élevé pour le SBOM.

De plus, le Bureau de la gestion et du budget (OMB) de la Maison Blanche a publié un mémorandum de septembre 2022 intitulé « Renforcer la sécurité de la chaîne d'approvisionnement logicielle grâce à des pratiques de développement de logiciels sécurisés » (M-22-18), en réponse à l'EO 14028 4k. L'annexe du mémorandum précise les tâches et les délais que chaque agence devra accomplir à l'avenir, parmi lesquels la CISA a pour tâche de "publier les lignes directrices actualisées du SBOM" , mais le délai d'achèvement n'est pas précisé. Cela reflète également le fait que les plus petits éléments ne constituent peut-être pas le meilleur choix pour la promotion de l’utilisation du SBOM. L'ère des « éléments minimaux » est appelée à prendre fin avec la formulation de nouvelles lignes directrices, mais une série de documents de la NTIA constituent toujours une base importante pour le travail de suivi.

2. Avancement des travaux de la « Mise à jour du guide SBOM » de CISA

L'expérience et le positionnement fonctionnel de CISA déterminent que son travail SBOM accorde plus d'attention aux risques de mise en œuvre et de vulnérabilité, en se concentrant sur l'opérabilité, les outils, les nouvelles technologies et les nouveaux cas d'utilisation. CISA réalise que le développement et l'amélioration du SBOM doivent venir de la communauté et promeut le travail du SBOM en promouvant la participation, le développement et l'amélioration continue de la communauté. Depuis plus d'un an, CISA a amélioré et promu la formulation des documents d'orientation SBOM en créant des plates-formes, en créant des modèles et en développant VEX (Vulnerability Exploitability Information Exchange).

1. Construire une plateforme : favoriser la mise en place de 5 groupes de travail

Pour faciliter la compréhension par la communauté des logiciels et de la sécurité de la création, de l'utilisation et de la mise en œuvre des SBOM au sein de l'écosystème technologique plus large, CISA a facilité la formation de cinq groupes de travail.

2. Création de modèles : partage condensé et modèles de type

(1) Modèle de cycle de vie partagé SBOM

Afin d'aider les utilisateurs à choisir raisonnablement une solution SBOM partagée, en avril 2023, le « SBOM Sharing Life Cycle Report » a été publié, décrivant le processus complet de partage de SBOM de l'auteur du SBOM à l'utilisateur, y compris la découverte (Découverte), l'accès (Access) et Il y a trois étapes de transport, comme le montre la figure ci-dessous.

Le rapport définit des niveaux de complexité élevés, moyens et faibles pour une série de méthodes spécifiques de découverte, d'accès et de transmission, et les explique en détail à l'aide d'exemples. Par exemple, pour l'accès, les approches de complexité faible, moyenne et élevée incluent respectivement le contrôle manuel, la granularité du contrôle d'accès restreint, l'authentification autorisée et le contrôle d'accès. Le modèle et ces méthodes sont basés sur le « partage et échange de SBOM » de la NTIA, mais la NTIA répertorie moins de méthodes et n'effectue pas de classification de complexité.

(2) Modèle de type SBOM

En avril 2023, le groupe de travail sur les outils et la mise en œuvre SBOM de CISA a publié « Types SBOM », qui résume six types SBOM courants que les outils actuels peuvent créer ainsi que leurs avantages et limites respectifs. Les types de SBOM spécifiques sont indiqués dans le tableau ci-dessous.

Sur RASC2023, Chris Blask, co-directeur du partage CISA SBOM et vice-président de la stratégie Cybeats, a rendu compte du thème "Le monde du SBOM", présentant la relation entre les types de SBOM mentionnés ci-dessus et améliorant la transparence et l'efficacité pour l'approvisionnement typique. acteurs de la chaîne du secteur de l'énergie et des exemples de divers types d'applications de collaboration SBOM dans trois scénarios typiques de « solutions fournies par les futurs intégrateurs », « opérations de programme pour l'installation de nouveaux produits » et « programmes de gestion des correctifs de sécurité ».

3. Développer VEX : compléter et formuler des lignes directrices VEX

VEX est une forme d'avis de sécurité lisible par machine utilisée pour indiquer si un produit logiciel est affecté par une vulnérabilité connue. Ce n'est pas un composant nécessaire du SBOM, mais il est bien pris en charge pour l'utilisation efficace des données SBOM, en particulier dans le champ de sécurité. VEX a été initialement proposé par la NTIA, mais la CISA l'a étendu et standardisé de nombreuses manières au cours de l'année écoulée.

(1) Définir les éléments minimaux VEX et les scénarios d'application

En avril 2022, « VEX Use Cases » a été publié, recommandant les éléments de données minimaux des documents VEX et fournissant une série d'exemples de scénarios d'application que les fournisseurs de produits peuvent rencontrer, qui peuvent être utilisés pour guider la construction de documents VEX de complexité différente. . Son objectif ultime est de soutenir une plus grande automatisation dans l’ensemble de l’écosystème des vulnérabilités, y compris la divulgation, le suivi et la correction des vulnérabilités, et bien plus encore.

Les éléments de données minimum d'un document VEX comprennent : les métadonnées VEX, les détails du produit, les détails de la vulnérabilité et les détails de l'état du produit (les quatre états "non affecté", "affecté", "réparé" et "sous enquête" définis dans le VEX initial de la NTIA. ) 4 parties. Il stipule également que si le statut du produit est « affecté », il doit y avoir une déclaration d'action pour indiquer ce que l'utilisateur doit faire ; si le statut du produit est « non affecté », il doit y avoir une déclaration d'impact pour expliquer davantage les détails.

Le document présente des cas spécifiques pour 9 scénarios typiques répartis en quatre catégories, notamment « produit unique et vulnérabilité unique », « produit unique et vulnérabilités multiples », « produits multiples et vulnérabilité unique » et « produits multiples et vulnérabilités multiples », ainsi que des documents VEX dans Formats CSAF et CycloneDX avec un minimum d'éléments de données appliqués.

(2) Déterminer l'option d'interprétation du statut « non affecté »

En juin 2022, « Interprétation du statut VEX » a été publié, recommandant 5 options d'explication possibles pour le statut du produit « non affecté » et fournissant des exemples d'utilisation de différentes options dans les documents VEX à des moments appropriés pour aider les utilisateurs à comprendre le produit. Dans quelles circonstances la conclusion a-t-elle été de "non affecté" soit faite.

Les cinq options d'interprétation sont les suivantes : le composant n'existe pas, le code vulnérable n'existe pas, le code vulnérable ne sera pas contrôlé, le code vulnérable n'est pas sur le chemin d'exécution et des atténuations internes existent. Le document donne des exemples spécifiques et des diagrammes d'interprétation d'état correspondants pour chaque option d'interprétation d'état.

Des exemples de « le composant n'existe pas » peuvent inclure, par exemple, qu'un produit écrit en Python ne serait pas affecté par la vulnérabilité Log4j du composant Java, une automatisation conduisant à une sauvegarde incorrecte de l'identité du composant dans le fichier JAR, d'autres couches supprimant la base. couche contenue dans l'image du conteneur, packages inutilisés, etc. ; le diagramme d'interprétation de l'état "le code vulnérable n'est pas sur le chemin d'exécution" est présenté ci-dessous.

(3) Standardiser les exigences minimales et le format standard de VEX

En avril 2023, les exigences minimales VEX ont été publiées, spécifiant dans un format standard les éléments minimaux requis pour créer un document VEX. Les « exigences minimales » sont orientées vers l'automatisation, les outils et l'interopérabilité et sont facultatives. Des formats tels que CSAF, CycloneDX et OpenVEX peuvent tous être utilisés pour générer de la documentation VEX basée sur des exigences minimales.

Les éléments de données VEX « Exigences minimales » sont présentés dans le tableau ci-dessous. Un document VEX peut contenir une ou plusieurs instructions VEX. Le contenu entre crochets après le nom de l'élément de données dans le tableau est l'identifiant de l'élément ; le contenu entre parenthèses est l'explication de l'élément correspondant.

3. Avancement du plan OpenSSF « SBOM Everywhere (SBOM Everywhere) »

Lors du Sommet II sur la sécurité des logiciels open source de la Maison Blanche en mai 2022, OpenSSF a publié le « Plan d'action pour la sécurité des logiciels open source », présentant 10 orientations pour améliorer la sécurité des logiciels open source. La direction 9 est "SBOM est partout : améliorer l'utilisation de l'outil SBOM et la formation publicitaire pour promouvoir son application autant que possible", l'idée principale est "Améliorer l'état de sécurité de l'ensemble de l'écosystème open source grâce à l'omniprésence du SBOM. La publication ne suffit pas, SBOM doit être activement utilisé".

Par la suite, OpenSSF a créé le « SBOM Everywhere Interest Group (SIG) » au sein du groupe de travail sur les outils de sécurité, en se concentrant sur la promotion de la disponibilité et de la facilité d'utilisation de SBOM grâce à des outils et des formations améliorés. Depuis sa création, le travail principal de SIG s'est concentré sur l'exploration et la création d'un panorama de l'écosystème des outils SBOM, la coopération avec des écosystèmes et des projets open source pour développer et promouvoir des expériences réussies, et l'identification de cas d'utilisation SBOM orientés sécurité, etc.

1. Construction du panorama écologique des outils SBOM

(1) Objectifs et tâches du panorama SBOM

Actuellement, le manque de suivi des outils SBOM crée des difficultés pour trouver des outils. Dès le début de sa création, SIG a prévu de créer un panorama SBOM similaire au « panorama natif cloud » de la CNCF, qui est utilisé pour suivre tous les outils SBOM, entreprises, formats de données et cas d'utilisation, afin de classer, rechercher et analyser un large éventail d'outils. nombre de solutions dans l'écosystème.

Selon le plan, le projet SBOM Everywhere fournira des fonds pour la construction initiale, la population et le déploiement du panorama, et effectuera la maintenance ultérieure en collaboration avec les membres et les bénévoles d'OpenSSF. Le SIG estime qu'une fois les panoramas établis et acceptés comme source d'information standard, les développeurs maintiendront leurs outils à jour et seront en mesure d'aider tout le monde à naviguer dans le vaste monde des SBOM. Le SIG a prévu 4 tâches pour le développement et le déploiement de Panorama :

· Construire le panorama SBOM sur l'infrastructure OpenSSF. Panorama sera hébergé dans le référentiel GitHub d'OpenSSF, en utilisant la marque et les licences appropriées comme l'exige OpenSSF, et en mettant en œuvre les dernières normes de l'industrie ;

· Appliquer la taxonomie des outils OpenSSF à la liste des outils connus . La documentation des outils connus de la NTIA n'a pas été mise à jour depuis longtemps et n'est pas lisible par machine. Lors du déploiement de Panorama, SIG le convertira en un fichier YAML que les outils Panorama peuvent lire ;

· Améliorer les métadonnées de taxonomie des outils NTIA existants. La taxonomie de la NTIA est obsolète. Après vous être appuyé sur les membres de la communauté pour fournir une liste d'outils, de normes et de concepts actuels, essayez d'en identifier de nouvelles métadonnées taxonomiques ;

· Assurez-vous que le panorama est maintenable par la communauté. Une fois le panorama déployé, ce sera à la communauté de piloter les futures mises à jour. Il faut s'assurer que tous les composants nécessaires sont stockés dans le référentiel GitHub avec une documentation expliquant comment mettre à jour, ajouter et supprimer des entrées.

(2) Maintenance d'outils connue basée sur un modèle d'informations sur l'outil

Conformément aux exigences de la deuxième tâche ci-dessus, SIG promeut la compilation de modèles d'informations sur les outils SBOM et a trié 140 outils connus sur la base de la première ébauche du modèle (1er septembre 2022), dont 29 outils open source basés sur SPDX. et 15 outils de brevets, 61 outils de brevets open source et 12 outils de brevets basés sur CycloneDX, 15 outils de brevets open source et 8 outils de brevets basés sur SWID. En outre, le SIG explore également l’automatisation de l’acquisition des données d’outils en mettant en place des versions de modèles lisibles par machine. Une première ébauche du modèle d’informations sur l’outil et un exemple sont présentés dans le tableau ci-dessous.

(3) Taxonomie améliorée de l'outil SBOM

Conformément aux exigences de la troisième tâche ci-dessus, sur la base de la taxonomie des outils NTIA, SIG promeut et discute de l'amélioration et de l'amélioration des métadonnées de classification des outils SBOM. Le tableau suivant est la première ébauche de la taxonomie améliorée (1er septembre 2022). La police noire oblique est le nouveau contenu de SIG, et les autres sont la taxonomie originale de la NTIA.

On peut voir que la modification inclut une division supplémentaire de l'analyse dans la catégorie « génération » en analyse statique et dynamique, et l'ajout d'outils d'analyse et de surveillance des risques et vulnérabilités de sécurité dans la catégorie « utilisation », ce qui illustre également que ces outils La demande , le développement ou l'utilisation de sont en augmentation et ont été portés à la connaissance du SIG.

2. Recherche et développement coopératifs avec l'écologie et les projets open source

La bibliothèque SPDX Python est une bibliothèque Python permettant d'analyser, de valider et de créer des documents SPDX qui aident les utilisateurs à comprendre les dépendances et à améliorer la sécurité et la conformité. Cependant, en raison du manque de soutien technique et financier de la part des bénévoles, la bibliothèque n'a pas été mise à jour depuis longtemps et ne peut pas être cohérente avec la nouvelle version de SPDX. Le premier travail après la création du programme SBOM Ubiquitous a été de promouvoir le financement d'OpenSSF pour le développement de la bibliothèque SPDX Python. Ce travail a été lancé le 1er septembre 2022 et la version 0.7 de la bibliothèque SPDX Python a été publiée le 27 mars 2023. 0, prenant en charge SPDX V2.3.

La raison pour laquelle ce travail est activement promu est que SIG estime que quel que soit l'état futur de la sécurité logicielle, l'écosystème SBOM et les outils associés continueront à jouer un rôle important dans le maintien de la sécurité écologique des logiciels. En outre, fin juin de cette année, lorsque SIG envisageait avec impatience les travaux futurs, il a également mentionné que la prochaine étape serait d'envisager de coopérer avec certains projets open source. Par exemple, SIG comprend les conditions d'une génération réussie de SBOM par des projets open source. Les projets open source créent des playbooks de mise en œuvre unifiés.

3. Identification des cas d'utilisation du SBOM orienté sécurité

Un autre travail que le SIG avance est de soutenir la mise en œuvre de l'initiative SBOM Everywhere en identifiant les cas d'utilisation, car il est mentionné dans l'orientation 9 du plan d'action qu'un obstacle important à la suppression de l'adoption ultérieure du SBOM réside dans la garantie des cas d'utilisation. requis pour créer des cas d'utilisation à l'aide de SBOM Les conditions sont clairement comprises, documentées et mises en œuvre dans les spécifications SBOM actuelles ; il existe de bons outils open source pour générer des SBOM satisfaisant ces conditions. À cet égard, SIG a résumé les exigences en matière d'informations sur les cas d'utilisation du point de vue des besoins des utilisateurs et de l'ensemble initial d'utilisateurs/rôles clés du SBOM (au 10 août 2023).

Les informations sur le cas d'utilisation du point de vue des besoins de l'utilisateur doivent mettre en évidence la motivation du cas d'utilisation, exprimer clairement le point de vue de l'utilisateur et clarifier l'objectif du SBOM (c'est-à-dire clarifier les composants du logiciel qui ne sont pas contribués, modifiés et contrôlés). par la première partie, y compris comprendre les autorisations des dépendances pour garantir la conformité, comprendre la vulnérabilité des dépendances pour évaluer les risques de sécurité, comprendre rapidement si le logiciel dépend de composants tels que Log4j) ; l'ensemble initial d'utilisateurs/rôles SBOM clés comprend les développeurs, en aval Utilisateurs de produits avec SBOM, architectes/responsables produits, bureau de projet open source, ingénierie de sécurité, achats fournisseurs tiers, chaque type d'utilisateur est subdivisé en plusieurs types d'utilisateurs spécifiques.

Le SIG décrit également brièvement les cas d'utilisation typiques pour les producteurs et les utilisateurs de logiciels. Les cas d'utilisation typiques des producteurs de logiciels incluent 5 aspects de la génération de SBOM par construction, analyse ou édition, et les cas d'utilisation typiques des utilisateurs de logiciels incluent 8 aspects de visualisation, de vérification, d'analyse et d'importation de SBOM.

4. Les progrès et les suggestions pour promouvoir le travail du SBOM dans mon pays

Afin de favoriser la mise en œuvre du SBOM, notre pays a également réalisé divers travaux. En termes de formulation standard, la norme nationale « Exigences de sécurité de la chaîne d'approvisionnement logicielle (projet pour approbation) » et « Méthode d'évaluation de la sécurité du code source ouvert des produits logiciels (projet pour commentaire) » contiennent des définitions des champs de base du SBOM et des exigences en matière d'exhaustivité et de traçabilité du SBOM. , Le deuxième lot d'exigences des normes nationales de sécurité des réseaux pour 2023, publié par le Comité de normalisation de la sécurité nationale en juillet, comprend le guide des exigences pour le « Format de données de nomenclature logicielle » ; en termes de projets de recherche scientifique, les sujets de projet de génération automatique et Les applications de SBOM progressent régulièrement ; En termes d'évaluation des capacités SBOM de l'industrie, "l'évaluation des capacités SBOM de la nomenclature logicielle de confiance" et le "projet pilote de gestion des risques de la chaîne d'approvisionnement logicielle basé sur la nomenclature logicielle (SBOM)" organisés par l'Académie chinoise de Les technologies de l'information et des communications ont publié des résultats d'évaluation pertinents. Néanmoins, l'application et la promotion du SBOM dans mon pays en sont encore à leurs balbutiements. En combinant l'analyse des travaux existants dans les chapitres précédents, cet article suggère :

Développement inversé du format SBOM et de la spécification du contenu

SBOM est un travail très pratique, et la principale difficulté réside dans la promotion des applications plutôt que dans la technologie. Lors de la formulation de la spécification du format SBOM, il est recommandé de s'inspirer de l'expérience de CISA dans l'extraction et la synthèse des modèles de partage et de type SBOM à partir de la pratique, et d'utiliser la puissance de l'industrie (analogue aux communautés sur lesquelles s'appuient CISA et OpenSSF) pour résumer les spécifications du format SBOM. formater les données des cas réussis existants, puis vérifier et répéter un nombre suffisant d'essais pilotes. Adoptez la pensée inverse de « la théorie guide la pratique » pour formuler des normes.

· Construire un système d'outils SBOM pour les utilisateurs nationaux

Les outils d'automatisation sont une garantie importante pour la disponibilité et la facilité d'utilisation de SBOM. Permettre aux utilisateurs de SBOM de comprendre, d'acquérir et d'utiliser facilement ces outils peut grandement améliorer l'efficacité du travail. Suggestion : organiser ou financer la recherche et le développement d'une série d'outils dotés de fonctions spécifiques, tels que des outils de génération et de vérification SBOM prenant en charge la spécification de format ; suivre la progression du panorama OpenSSF SBOM en temps opportun, utiliser de manière sélective les réalisations pertinentes et compléter les informations sur les outils nationaux existants et améliorer continuellement la carte du système d'outils pour servir les utilisateurs du SBOM.

· Promouvoir l'application de la gestion des risques de sécurité basée sur le SBOM

Il est recommandé que la spécification du format SBOM inclue des champs liés à la sécurité tels que les licences open source et les vulnérabilités ; les fournisseurs de logiciels utilisent des outils de gouvernance de sécurité open source pour surveiller les matériaux open source et réduire leurs risques, surveiller les risques tels que les vulnérabilités de sécurité des matériaux utilisés, et fournir aux utilisateurs un support technique en temps opportun pour générer le SBOM Et fourni avec le produit ; les utilisateurs finaux du logiciel vérifient le SBOM pour confirmer les composants logiciels et les risques de sécurité. Dans le fonctionnement quotidien du logiciel, sur la base du SBOM, les renseignements sur les menaces liés aux matériaux logiciels sont un suivi continu et des mesures opportunes sont prises.

A propos de l'auteur

Dong Guowei, expert chez Hufu Think Tank, expert senior au laboratoire de sécurité des codes du groupe Qi Anxin et titulaire d'un doctorat, est engagé dans la sécurité des réseaux, la sécurité des logiciels, l'audit de code et l'analyse des vulnérabilités depuis près de 20 ans.

FIN