Document de cadrage SBOM CISA : Troisième édition
Interlynk
Aux États-Unis, l'Agence de cybersécurité et de sécurité des infrastructures (CISA) travaille depuis 2018 à promouvoir les normes et l'adoption des factures de matériaux logiciels (SBOM).
Le focus de la CISA est d'opérationnaliser et d'échelonner l'utilisation des SBOM en partageant des outils, en recommandant des technologies et en décrivant des cas d'utilisation. En même temps, la CISA continue d'itérer sur les exigences sous-jacentes pour s'adapter à la prochaine phase d'adoption.
La semaine dernière, la CISA a publié Framing Software Component Transparency, 3rd Edition pour aider à faire avancer cette prochaine étape.
Contexte
Après une forte augmentation des attaques sur la chaîne d'approvisionnement des logiciels qui ont touché plusieurs agences fédérales, le NTIA et ensuite le CISA ont entrepris la tâche d'améliorer la transparence dans les chaînes d'approvisionnement des logiciels. Le CISA reconnaît qu'une visibilité limitée dans ces chaînes d'approvisionnement entraîne des risques plus élevés en matière de cybersécurité, augmente les coûts de maintenance technologique et encourage à privilégier la vitesse au détriment de la sécurité. En 2018, le NTIA s'est associé à l'industrie et à des partenaires communautaires pour rendre les chaînes d'approvisionnement des logiciels plus transparentes, avec pour objectif de réduire les risques, les coûts et le temps nécessaire pour gérer les incidents de cybersécurité. Des recommandations pour Software Bill of Materials (SBOM) et Vulnerability Exploitability eXchange (VEX) ont émergé de ces groupes de travail collaboratifs.
Cadre de transparence des composants logiciels
La première édition de Framing Software Component Transparency est sortie en 2019, suivie de la deuxième en 2021.
Le groupe de travail sur les outils et la mise en œuvre de SBOM a été responsable de la troisième édition. Ce groupe vise à développer un modèle pour les informations sur les composants logiciels qui peuvent être partagées ouvertement entre les secteurs.
Dans ce modèle, la facture logicielle de matériaux (SBOM) est l'artéfact clé—elle énumère les composants d'un logiciel, inclut des détails sur la propriété et montre comment les composants sont connectés.
Troisième édition Modifications
Le problème de nomination de logiciel - la capacité d'identifier de manière unique un logiciel ou un composant au sein du SBOM - est l'un des défis fondamentaux dans le traitement du SOM. Le principal objectif de la troisième édition est de recommander des pratiques qui aident à relever ce défi.
Pour y parvenir, elle se concentre sur -
1. La déclaration d'un ensemble minimum requis d'attributs de base nécessaires pour identifier des composants avec une relative unicité suffisante
2. L'identification des attributs supplémentaires, optionnels et des éléments externes au-delà de l'ensemble de base pour servir une variété d'applications SBOM et
3. L'activation de la corrélation des SBOM avec des sources externes pour une analyse pertinente
Attributs de Base des Composants
Cette édition se concentre sur la définition des attributs de base pour l'identification des composants.
Un attribut de composant, niveau de maturité, est également spécifié pour les organisations/outils qui visent à fournir des détails supplémentaires pour répondre à des exigences plus complètes.
Ces niveaux de maturité sont :
Minimum attendu
Pratique recommandée
Objectif aspirational
La liste des attributs de base est la suivante, accompagnée de leur niveau minimum et recommandé :
Attributs de niveau SBOM
Date et heure
Type
Composant Principal
Attributs de niveau Composant
Nom du Composant
Version
Nom du Fournisseur
Minimum : Si le composant est non modifié, utilisez le nom du fournisseur en amont sinon, remplacez-le par le nom du fournisseur du composant principal
Identificateurs Uniques
Recommandé : Au moins un identifiant unique pour chaque composant
Minimum : Autant d'identifiants uniques à l'échelle mondiale que disponibles pour chaque composant
Hachages Cryptographiques
Recommandé : Au moins un hachage sécurisé et son algorithme pour le composant principal
Minimum : Au moins un hachage et son algorithme pour tout composant, si connu
Relations
Recommandé : Relations et leur exhaustivité pour tous les composants inclus
Minimum : Relations et leur exhaustivité pour le composant principal et ses dépendances directes
Licence
Recommandé : Informations sur la licence pour autant de composants que possible
Minimum : Informations sur la licence pour le composant principal
Avis de Copyright
Recommandé : Avis de copyright pour autant de composants que possible
Minimum : Avis de copyright pour le composant principal
De plus, cette édition clarifie comment gérer les scénarios lorsque les données nécessaires pour compléter le SBOM sont inconnues, indisponibles ou ne peuvent pas être déclarées.
Attributs Inconnus des Composants
Un attribut inconnu doit être géré avec
Utiliser la valeur “aucune assertion” (c'est-à-dire, les données sont manquantes) différemment de la valeur “aucune valeur” (c'est-à-dire que l'Attribut n'est pas applicable pour ce SBOM spécifique).
Après tous les efforts raisonnables pour éliminer “aucune assertion” des Attributs de Base.
Composants Rédigés
Si un composant nécessite une rédaction, il doit continuer à préserver la version du composant et les hachages cryptographiques ainsi que ses relations de dépendance.
Dépendances Inconnues
Si un SBOM contient des dépendances inconnues connues, les champs d'exhaustivité des relations doivent être utilisés pour déclarer l'état d'exhaustivité de chaque composant.
Informations Supplémentaires
La troisième édition clarifie l'extension du SBOM pour supporter des cas d'utilisation supplémentaires en fournissant des informations supplémentaires telles que -
Données de fin de vie ou niveau de support pour les composants
Indication des technologies qu'un Composant implémente ou supporte
SWID Retiré
Dans un autre changement majeur, la troisième édition a retiré le SWID du format recommandé et a mis à jour le mapping pour les formats SPDX et CycloneDX restants.
Conformité avec la troisième édition
sbomqs - L'outil open source multi-spécifications SBOM d'Interlynk a été mis à jour pour vérifier la conformité des SBOM avec la troisième édition. Avec la version de build 0.2.2 ou ultérieure, sbomqs peut décomposer la conformité des SBOM le long des lignes de
score pour chaque champ à l'achèvement
pourcentage d'achèvement d'un attribut de base spécifique
niveau de maturité de l'attribut de base - Aucun / Minimum / Recommandé
Avec la commande - sbomqs conformité -f sbom.cdx.json --color
Résumé
CISA reste engagée envers la transparence logicielle et les groupes de travail sur le SBOM contribuent à standardiser et à opérationnaliser le SBOM afin d'améliorer la transparence des risques logiciels. La troisième édition de Framing Software Component Transparency comprend des conseils pratiques pour les constructeurs et opérateurs d'outils SBOM pour garantir la cohérence dans la génération de SBOM et l'extraction de valeur réelle de ces SBOM.
Chez Interlynk, nous faisons progresser nos outils open source et nos capacités de plateforme à mesure que les spécifications sont clarifiées. Les utilitaires open source d'Interlynk tels que sbomqs et sbomasm ainsi que la plateforme de gestion SBOM gratuite d'Interlynk - https://app.interlynk.io/ restent les utilitaires les plus fiables et à jour pour travailler avec le SBOM.