À notre époque, la création de produits logiciels ou d'applications sécurisés nécessite une connaissance complète des composants exacts de l'application que vous créez. Les dépendances, licences, fichiers et autres actifs qui composent votre progiciel sont des points de vulnérabilité potentiels par lesquels des acteurs malveillants peuvent lancer une attaque contre votre logiciel et d'autres applications tout au long de la chaîne d'approvisionnement.
Dans le cadre des efforts visant à lutter contre la récente augmentation de la fréquence et de l'impact des attaques contre les chaînes d'approvisionnement en logiciels, le gouvernement fédéral, en coordination avec la NTIA, a publié un décret qui détaille diverses mesures visant à améliorer la cybersécurité et à garantir l'intégrité des composants tiers utilisés dans les progiciels. Une de ces mesures est la Nomenclature du logiciel.
Il s'agit d'un document formel qui contient tous les composants d'un progiciel et les relations de la chaîne d'approvisionnement entre ces composants. La préparation d'une nomenclature logicielle complète n'est pas seulement une pratique courante, elle est également requise par la loi. Cet article définit la portée de la nomenclature logicielle et les éléments minimaux qui doivent être inclus dans une nomenclature complète.
Que fournissent les composants minimum d'un SBOM de la NTIA ?
Le SBOM sert de guide formel pour les entreprises qui créent, achètent ou exploitent des logiciels, fournissant toutes les informations dont elles ont besoin pour améliorer leur compréhension de la chaîne d'approvisionnement des logiciels. Cela permet également de détecter facilement les vulnérabilités émergentes si elles se produisent, et réduire les risques liés à la chaîne d'approvisionnement en logiciels. Cependant, pour que le SBOM réponde aux exigences du gouvernement fédéral, il doit contenir certains éléments de base. Ces éléments sont souvent classés en trois catégories :
- Champs de données: Un SBOM est censé fournir des données importantes sur les composants logiciels telles que le nom du composant, le nom du fournisseur, la version du logiciel et d'autres identifiants uniques. Il doit également détailler les relations entre les dépendances. Ces données permettent d'identifier avec précision tous les composants logiciels et de les suivre tout au long de la chaîne d'approvisionnement logicielle.
- Prise en charge de l'automatisation : La nomenclature du logiciel doit être lisible par machine et également capable de génération automatique. Cela permet un suivi continu des données incluses dans le SBOM. Habituellement, ces documents sont dans des formats standard tels que les balises SPDX, CycloneDX et SWID, ce qui les rend également lisibles par l'homme.
- Pratiques et processus : La documentation SBOM devrait également détailler les pratiques et processus standard de préparation et de mise à jour du SBOM. Il devrait également inclure des pratiques de distribution et d'accès au SBOM ainsi que des mesures de traitement des erreurs fortuites.
Les éléments minimum requis par la NTIA dans la documentation SBOM fournissent un critère clair de ce qui est attendu dans une directive SBOM pour les cas d'utilisation de base de votre nomenclature logicielle, tels que la gestion des vulnérabilités, l'inventaire des composants logiciels et la gestion des licences logicielles. Le cadre est en cours de mise à jour et pourrait inclure des éléments supplémentaires qui étendraient sa convivialité dans un avenir proche. Dans les sections suivantes de cette page, nous expliquerons plus en détail ces composants clés de votre nomenclature logicielle. Les éléments minimum requis d'une nomenclature logicielle comprennent sept champs de données, comme spécifié ci-dessous.
Champs de données : exigences minimales
L'objectif de la nomenclature logicielle est de fournir des informations qui aident les utilisateurs et autres parties prenantes à identifier facilement les composants logiciels. Comme on pouvait s'y attendre, l'un des premiers et des plus importants éléments du SBOM sont les données qui doivent être incluses pour chaque composant détaillé dans le document. En plus de faciliter l'identification des composants individuels, les données facilitent également le suivi des composants aux différents endroits où ils sont utilisés dans la chaîne d'approvisionnement logicielle.
- Nom du fournisseur: Le fournisseur est l'auteur ou le fabricant du composant logiciel en question. Il s'agit du nom de la personne ou de l'organisation qui crée, définit et identifie les composants logiciels.
- Nom du composant: Il s'agit du nom désigné attribué au logiciel tel que défini par le fournisseur ou le fabricant d'origine. Dans les cas où il existe plusieurs noms et alias pour le logiciel, ils peuvent également être notés.
- Version du composant : Le SBOM doit inclure le numéro de version ou le numéro de catégorie tel que spécifié par le fournisseur ou le fabricant. Les données de version servent d'identifiant qui spécifie toute modification apportée au logiciel par rapport à une version précédemment identifiée de la version ultérieure du logiciel.
- Autres identifiants uniques : Il s'agit d'identifiants supplémentaires autres que le nom et la version du composant. Ces identifiants supplémentaires fournissent une couche d'identification supplémentaire pour le composant et peuvent également être utilisés comme clé de recherche pour trouver le composant dans les bases de données pertinentes.
- Relation de dépendance : Il s'agit de l'un des composants de données les plus importants d'une nomenclature logicielle, puisque le SBOM est destiné à détailler la façon dont les composants logiciels s'emboîtent. La relation de dépendance spécifie la relation entre le logiciel X utilisé dans votre application et ses composants en amont.
- Auteur des données SBOM : Il s'agit de la personne qui a créé les données SBOM. Parfois, le fournisseur du logiciel peut également faire office d’auteur. Cependant, dans de nombreux cas, l’auteur est un autre individu ou un autre groupe.
Prise en charge de l'automatisation : exigences minimales
L’utilisation de la nomenclature logicielle dépasse souvent les frontières organisationnelles. Cela signifie que les données contenues dans le SBOM sont souvent utilisées par plusieurs départements au sein d'une organisation ainsi que par plusieurs organisations. Pour garantir la facilité d'utilisation de cette documentation, la NTIA recommande que le SBOM soit dans un format à la fois lisible par une machine et par un humain. La préparation et la transmission du SBOM dans des formats automatisés standards comme celui-ci améliorent l'interopérabilité de ce document pour ses diverses finalités.
La NTIA reconnaît trois formats de livraison pour générer et transmettre des SBOM. Votre nomenclature logicielle doit correspondre à l'un de ces formats pour être conforme aux normes établies par le décret du gouvernement sur la cybersécurité. Ces formats standards incluent :
- Échange de données sur les progiciels (SPDX)
- Balises d'identification de logiciel (SWID)
- CycloneDX
Échange de données sur les progiciels (SPDX)
Le SPDX est un standard ouvert pour la fourniture de données SBOM. Il capture des informations importantes sur le logiciel, notamment ses composants, sa provenance, ses licences et ses droits d'auteur. Il fournit également des références de sécurité. Le SPDX la version 2.2 est la version la plus récente et prend en charge le type de fichier YAML 1.2, JavaScript Object Notation et Resource Description Framework (RDF/XML). tag : valeur du fichier texte plat et des feuilles de calcul .xls
Balises d'identification de logiciel (SWID)
Les balises SWID sont conçues pour aider à identifier et contextualiser les composants de tout produit logiciel. Le projet Software Identification tags (SWID Tags) est un ensemble d'outils permettant de générer et de valider les tags d'identification d'un logiciel. Ces outils basés sur Java prennent en charge les balises XML SWID basées sur le format standardisé tel que défini par la norme ISO/IEC 19770-2:2015 et la représentation concise d'objet binaire (CBOR). Le Le NIST a un site Web avec une liste de ressources utiles pour :
- Création de balises SWID et CoSWID
- Validation des balises SWID et CoSWID en fonction d'exigences de schéma spécifiques et de directives de bonnes pratiques
- Une application Web qui fournit un service de validation de balise SWID qui peut être déployé sur un serveur d'applications Java
- Client de dépôt SWID pour publier des balises dans la base de données nationale sur les vulnérabilités
CycloneDX
CycloneDX prétend être une « norme légère de nomenclature logicielle (SBOM) ». Il est utile pour l’analyse des composants de la chaîne d’approvisionnement et la sécurité des applications. Les organisations qui adoptent CycloneDX peuvent répondre en toute transparence aux exigences minimales du SBOM et évoluer vers des cas d'utilisation plus sophistiqués de la documentation SBOM au fil du temps.
Les SBOM CycloneDX sont généralement présentés aux formats XML, JSON ou Protocol Buffers. La spécification comprend souvent ces cinq champs :
- Les métadonnées de la nomenclature : elles incluent les informations générales sur l'application ou le produit logiciel lui-même.
- Composants : il s'agit d'un inventaire complet qui couvre tous les composants propriétaires et open source du logiciel.
- Informations sur les services : celles-ci détaillent toutes les API externes que l'application est susceptible d'appeler lors de son fonctionnement. Il comprend toutes les URL des points de terminaison, les exigences d'authentification et les traversées des limites de confiance.
- Dépendances : la documentation détaille également tous les composants et services du progiciel. Cela inclut à la fois les relations directes et transitives.
- Compositions : cela fait référence à l'exhaustivité de tous les éléments constitutifs, y compris les composants individuels, les services et les relations de dépendance. Chaque composition est généralement décrite selon qu'elle est complète, incomplète, incomplète de première partie uniquement, incomplète de tiers uniquement ou complètement inconnue.
Pratiques et processus : exigences minimales
Le dernier élément de votre nomenclature logicielle se concentre sur les mécanismes d'utilisation du SBOM lui-même. Les pratiques et processus couvrent les détails opérationnels de la génération et de l’utilisation du SBOM et doivent être inclus dans toute politique ou contrat qui le demande. Voici les principales exigences qui doivent être détaillées dans la section Pratiques et processus de votre nomenclature logicielle :
- La fréquence: Cette section détaille la fréquence à laquelle une organisation doit générer une nouvelle facture logicielle pour les matériaux. Généralement, la NTIA vous recommande de générer un nouveau SBOM chaque fois que votre composant logiciel est mis à jour ou qu'une nouvelle version est publiée. Les fournisseurs sont également censés générer de nouveaux SBOM chaque fois qu'ils trouvent une erreur dans la version originale ou apprennent de nouveaux détails sur les composants de leur logiciel qui n'étaient pas inclus dans la documentation initiale.
- Profondeur: La profondeur de votre SBOM dépend de ce qui est inclus dans le document. Afin d'être conforme, votre SBOM doit inclure tous les composants de niveau supérieur et toutes les dépendances transitives. Dans les situations où l'auteur n'est pas en mesure d'inclure toutes les dépendances transitives, le document doit indiquer au consommateur où il peut les trouver.
- Il existe des cas où l'auteur du SBOM ne peut pas fournir un graphique de dépendance complet pour une raison ou une autre. Cela peut être dû au fait que le composant n'a plus de dépendances ou qu'ils ne savent pas si ces dépendances existent ou non. L'auteur du SBOM est tenu de préciser ce motif.
- Distribution et livraison : L’objectif de cette exigence est de garantir que les SBOM soient livrés rapidement et dans un format facilement digestible. Bien que cette exigence ne précise pas le nombre de jours ou de semaines dans lesquels les SBOM doivent être livrés, ils doivent être remis le plus rapidement possible. En outre, le SBOM doit avoir des rôles et des autorisations d'accès appropriés définis lors de sa livraison. Enfin, l'exigence stipule que le SBOM peut soit être distribué avec chaque instance du produit, soit être mis à disposition de toute autre manière facilement accessible, par exemple via un site Web public.
- Contrôle d'Accès : Dans les cas où le fournisseur décide de limiter l'accès aux données SBOM à des utilisateurs ou clients spécifiques, l'auteur est tenu de préciser les modalités de contrôle d'accès. Il est également nécessaire d'offrir des allocations spécifiques aux consommateurs qui souhaitent intégrer les données SBOM dans leurs propres outils de sécurité.
- Hébergement des erreurs : SBOM peut aider à améliorer l'assurance logicielle et gestion des risques de la chaîne d'approvisionnement logicielle. Cependant, il est encore loin d’être parfait. Ainsi, les consommateurs doivent être tolérants à l’égard des erreurs ou omissions involontaires occasionnelles qui peuvent survenir lors de la préparation des SBOM.
Penser au-delà des exigences minimales de la NTIA
Jusqu’à présent, nous avons discuté des éléments minimaux requis dans votre nomenclature logicielle. Ces éléments minimaux représentent les exigences recommandées, en particulier pour les cas d'utilisation les plus élémentaires de cette documentation. Même s’ils constituent une bonne base pour la provenance et la sécurité des logiciels, il faut regarder au-delà de ces exigences. Voici quelques recommandations à prendre en compte pour les cas d’utilisation SBOM plus avancés.
Champs de données supplémentaires
En plus des champs de données couverts dans le document sur les exigences minimales, il existe des champs de données supplémentaires recommandés dans les cas où un niveau de sécurité plus élevé est nécessaire. Certains de ces champs de données supplémentaires incluent :
- Un hachage cryptographique des composants logiciels
- Données sur les phases du cycle de vie du logiciel
- Relations entre d'autres composants
- Informations sur la licence
Logiciels basés sur le cloud et logiciels en tant que service
Un autre domaine potentiel dans lequel les exigences du SBOM peuvent aller au-delà des bases est la gestion des produits Software-as-a-Service (SaaS). Ces types de produits logiciels présentent des défis uniques en ce qui concerne les données SBOM. Pour commencer, les risques de sécurité dans le contexte du cloud sont uniques. En outre, la responsabilité de gérer ces risques incombe au prestataire de services. La préparation de la documentation SBOM pour les logiciels basés sur le cloud est également plus complexe car ils ont tendance à avoir un cycle de publication plus court.
Intégrité et authenticité du SBOM
Un autre problème probable qu'il convient de noter est le processus d'authentification de la source des données SBOM elle-même. Actuellement, les signatures et l'infrastructure à clé publique sont les solutions incontournables pour vérifier l'intégrité des logiciels dans le monde numérique d'aujourd'hui. Les auteurs et fournisseurs de SBOM devront peut-être exploiter ces signatures logicielles existantes pour améliorer la fiabilité des données SBOM.
Vulnérabilité et exploitabilité dans les dépendances
Même si le but des SBOM est de faciliter la détection des vulnérabilités, il est important de noter que toutes les vulnérabilités dans les dépendances ne constituent pas des risques majeurs pour les logiciels qui en dépendent. Pour éviter de perdre du temps et des ressources, les fournisseurs de logiciels devront mettre en place des mesures pour déterminer les impacts potentiels d'une vulnérabilité de dépendance sur les logiciels utilisés en aval et communiquer le niveau de risque (ou son absence dans ce cas) aux utilisateurs du SBOM. données en aval.
Flexibilité vs uniformité dans la mise en œuvre
Chaque fois qu’il est question de sécurité logicielle, la question de la flexibilité et de l’uniformité revient toujours au premier plan. Cela s'applique également aux cas d'utilisation avancés des SBOM. Pour réussir la mise en œuvre des SBOM, il faudra des politiques générales s’appliquant à tous les domaines ainsi qu’à des cas spécifiques où une certaine flexibilité sera nécessaire.