En avril 2023, le DHS, la CISA, le DOE et le CESER ont publié un rapport intitulé «Rapport sur le cycle de vie du partage de nomenclatures logicielles (SBOM)'. L'objectif du rapport était d'examiner les manières actuelles dont les gens partagent les SBOM et de décrire, en termes généraux, comment ce partage pourrait être amélioré, avec une plus grande sophistication pour permettre une meilleure transparence dans les logiciels.
Le rapport décompose le cycle de vie du partage SBOM en 3 phases : découverte, accès et transport. Découverte C'est ainsi qu'un utilisateur ou un consommateur peut prendre conscience de l'existence d'un nouveau SBOM provenant d'un auteur ou d'un fournisseur. pour l'entretien C'est ainsi qu'un utilisateur ou un consommateur peut accéder à ce SBOM et à toutes les données pertinentes qui l'accompagnent (enrichissement SBOM). Transport C'est ainsi qu'un consommateur peut recevoir le SBOM. Dans tous les cas, plus le processus est automatisé, mieux ce sera pour toutes les parties impliquées.
Bien que le rapport ne mentionne spécifiquement aucun outil, il inclut divers exemples et listes d'attributs que ces outils souhaités incluraient.
Nous avons été ravis de découvrir ici chez Scribe que notre plateforme, qui permet le partage de SBOM l'information dans le cadre de son utilisation principale, obtient des notes très élevées lorsqu'on la compare à la liste d'exigences publiée.
Dans cet article, nous passerons en revue les 3 parties du cycle de vie du partage SBOM telles que spécifiées dans le rapport et examinerons la solution la plus sophistiquée vue par CISA.. Nous terminerons en décrivant comment Plateforme du Scribe répond à ces exigences.
Sophistication du cycle de vie du partage SBOM
Découverte est la phase initiale du cycle de vie et implique la manière dont un consommateur prend conscience de l'existence d'un SBOM provenant d'un auteur ou d'un fournisseur. Cela peut être aussi simple que de placer un nouveau SBOM dans un emplacement standardisé sur le site Web d'un fournisseur ou dans un emplacement d'un référentiel de logiciels. Le consommateur doit être suffisamment clair sur la manière d'obtenir ou au moins de demander l'accès à ces données SBOM afin de pouvoir y accéder ultérieurement et les télécharger pour son usage. Parfois, le consommateur devra rester en contact avec le fournisseur et demander des mises à jour sur son SBOM. Alternativement, des mises à jour continues automatisées pourraient être mises à disposition.
Une approche très sophistiquée, comme indiqué dans le rapport, place davantage la charge de la découverte sur le fournisseur afin de faciliter la vie du consommateur. Idéalement, il peut exister un processus bien connu et bien documenté, idéal pour l’automatisation et qui nécessite peu de choses à faire manuellement. À titre d'illustration, un fournisseur pourrait développer un publier/s'abonner service qui mettra automatiquement à jour les utilisateurs avec des informations sur les nouveaux SBOM ainsi que sur les versions mises à jour des SBOM existants et un mécanisme pour les localiser. De plus, les niveaux plus sophistiqués devraient être plus précis pour orienter les clients vers les informations demandées tout en masquant les informations non pertinentes.
pour l'entretien est la prochaine étape et elle détaille comment obtenir l’accès aux données. L'accent de cette étape est mis sur les restrictions d'accès imposées au SBOM et sur la manière dont un utilisateur obtiendra l'autorisation de passer à l'étape Transport. Le moyen le plus simple consiste à rendre le SBOM entièrement accessible au public et il se peut même qu’il ne soit pas nécessaire de mettre en place des contrôles d’accès. Mais, de manière réaliste, un fournisseur pourrait exiger que les SBOM soient conservés dans un référentiel où leur accès doit être approuvé manuellement ou défini par un rôle avant d'être accordé à un destinataire spécifique. De plus, les SBOM peuvent nécessiter une granularité de contrôle d'accès spécifique pour garantir que les clients ne peuvent afficher que des versions SBOM particulières liées à un produit ou accéder à des parties particulières des données.
Dans une approche très sophistiquée, un consommateur peut demander l'accès pour consulter un SBOM et un compte restreint peut être créé automatiquement. Si un consommateur peut prouver qu'il a acheté un appareil ou un logiciel pertinent pour le SBOM en question, comme une clé logicielle, l'accès aux SBOM peut être automatiquement accordé. Avec les rôles ou les contrôles d’accès au niveau de l’organisation, il existe un niveau élevé de granularité des autorisations. Cette fonctionnalité nécessite un haut niveau de sophistication en raison de la nécessité d'analyser et de comprendre les autorisations de chaque activité souhaitée ainsi que de suivre les données requises pour valider automatiquement les achats des clients. En utilisant un système tel que la délégation d'infrastructure à clé publique utilisant la signature de certificats, un fournisseur peut être en mesure de déléguer les demandes d'authentification et de contrôle d'accès à une autre organisation pour un niveau de sophistication encore plus élevé.
Transport est la dernière étape et détaille la méthode par laquelle un consommateur reçoit le SBOM. Les SBOM peuvent être transportées par diverses méthodes d'un emplacement à un autre ou d'un emplacement à plusieurs emplacements. Ce processus est facilité plus efficacement par certaines méthodes que par d’autres. Une copie stockée sur un disque dur et envoyée de l'auteur au consommateur peut suffire si le transport du SBOM n'implique que le déplacement d'un seul SBOM. Une méthode permettant aux clients de récupérer le SBOM en toute sécurité devrait être mise à disposition si une large base de consommateurs en a besoin. Cette étape est nécessaire pour que le consommateur puisse utiliser les données. Gardez à l’esprit que la plupart des utilisations pratiques du SBOM nécessitent un format lisible par machine, le transport doit donc en tenir compte.
À l'aide de protocoles établis, le processus de la phase de transport doit être soigneusement documenté pour permettre autant d'automatisation du transport que possible. Une interface de programmation d'application (API) doit être accessible, reproductible et cohérente. Il suffirait de classer une interface OpenAPI comme hautement sophistiquée si elle propose une documentation pour un transfert d'état représentatif (REST) ou une API RESTful. 13 D’autres normes API, comme SOAP (Simple Object Access Protocol) ou Graph Query Language (GraphQL), peuvent également être considérées comme suffisantes. REST n'est qu'un exemple populaire d'interface standardisée. En fait, toutes les interfaces offrant un niveau comparable de facilité d’intégration suffisent pour être classées comme hautement sophistiquées.
Comment la plateforme Scribe répond-elle aux exigences
Scribe a développé une plateforme qui permet une gestion automatique publier/s'abonner service. Un producteur de logiciels peut relier ses pipelines CI à la plate-forme afin que chaque fois qu'il exécute une build, un SBOM correspondant soit créé. Ces SBOM sont ensuite enrichis d'informations supplémentaires et sont accessibles en fonction du projet spécifique, du pipeline de build, de la date et de l'heure. Le producteur peut ajouter des abonnés à chaque projet afin qu'une fois qu'il décide de publier une nouvelle version du logiciel. Tous les abonnés sont avertis et ont immédiatement un accès complet, non seulement au nouveau SBOM mais également à toutes les autres informations de sécurité qui l'accompagnent. Les abonnés peuvent accéder à loisir aux SBOM auxquels ils ont accès et les télécharger quand ils le souhaitent.
Une fois que le lien du pipeline de création est établi et qu'un abonné approuve son intérêt pour les données, l'ensemble du flux d'informations est automatisé et nécessite peu ou pas d'intervention manuelle. Les données de sécurité sont cryptées et sécurisées par Scribe et seuls le producteur et les abonnés agréés y ont accès. La découverte est automatique, l'accès est déterminé par le producteur et le transport est au gré de l'abonné.
L'avenir du partage SBOM
De nos jours, le partage SBOM est aussi susceptible d'être effectué par courrier électronique que par un système automatisé, mais cette approche n'est pas évolutive. Pour permettre un meilleur partage, davantage d'outils et de plates-formes comme celui de Scribe doivent devenir disponibles, faciles à utiliser et accessibles. Une variété de solutions de partage conçues pour répondre aux besoins des diverses parties prenantes serait avantageuse pour l'écosystème de partage SBOM. Ces conditions existent parce qu'un fournisseur donné peut être invité à utiliser diverses méthodes de transport par ses clients, et qu'un client peut recevoir des données SBOM en utilisant diverses méthodes par ses partenaires en amont. Nous avons besoin de davantage de solutions capables de faire face aux situations particulières identifiées tout en essayant, lorsque cela est possible, de supprimer les processus manuels et d'éviter les actions qui entravent l'interopérabilité. L’objectif de l’industrie devrait être d’empêcher l’émergence de nombreuses solutions de partage de SBOM incompatibles les unes avec les autres dans une chaîne d’approvisionnement plus vaste, car cela ne ferait qu’exacerber les problèmes existants.
Depuis l' La plateforme Scribe est gratuite à utiliser jusqu'à 100 builds par mois, je vous encourage à l'essayer et à voir à combien de vos besoins en matière de sécurité et de réglementation la plate-forme répond. Nous avons encore un long chemin à parcourir pour parvenir à une plateforme véritablement universelle qui réponde à notre vision, mais c'est un bon point de départ que nous sommes impatients de partager avec le monde.
Ce contenu vous est proposé par Scribe Security, l'un des principaux fournisseurs de solutions de sécurité de bout en bout pour la chaîne d'approvisionnement logicielle, offrant une sécurité de pointe aux artefacts de code ainsi qu'aux processus de développement et de livraison de code tout au long des chaînes d'approvisionnement logicielles. En savoir plus.