Les SBOM ne sont pas définis et oublient – CPO Magazine
Les nomenclatures logicielles (SBOM) gagnent du terrain alors que les entreprises recherchent une meilleure visibilité dans les chaînes d’approvisionnement logicielles et ont besoin d’informations précises pour les exigences de divulgation des vulnérabilités. Mais maintenir un SBOM précis n’est pas une tâche simple et rapide. Voici ce qu’il faut garder à l’esprit lors de la construction d’un SBOM.
Considérez la sécurité des logiciels comme le mouvement et le désir de manger plus propre et plus sain. Dans nos efforts pour ce faire, nous voulons savoir d’où vient notre nourriture. Nous voulons une liste claire des ingrédients.
De plus en plus, c’est aussi le critère d’utilisation des logiciels dans un environnement professionnel. Les chefs d’entreprise et les responsables informatiques veulent connaître les ingrédients avec lesquels ils travaillent pour faire fonctionner leurs systèmes. Entrez la nomenclature du logiciel ou SBOM.
Les SBOM sont utiles pour les équipes qui développent des logiciels, les organisations qui achètent des logiciels et les utilisateurs finaux qui exécutent réellement le logiciel. Par exemple, un SBOM permet aux développeurs qui s’appuient sur des composants open source et tiers de s’assurer que les composants sont à jour. Les acheteurs et les utilisateurs de logiciels peuvent utiliser les SBOM pour effectuer une analyse de vulnérabilité afin de déterminer le niveau de risque d’un produit.
L’idée d’un SBOM n’est pas nouvelle. Le Cyber Supply Chain Management and Transparency Act de 2014, qui n’a pas été adopté par le Congrès, proposait d’obliger les agences gouvernementales américaines à obtenir des SBOM pour tout nouveau produit logiciel qu’elles achètent.
Mais ces listes de documentation des composants d’un logiciel donné ont suscité beaucoup d’attention ces derniers temps – en particulier depuis qu’elles sont incluses dans les exigences du décret exécutif sur l’amélioration de la cybersécurité des nations, annoncé par la Maison Blanche en mai 2021. Cette commande, largement stimulée par l’attention portée à la violation de SolarWinds à la fin de 2020, a mis en évidence les dépendances logicielles, car plusieurs organisations ont été touchées après que des pirates ont ajouté du code malveillant dans le système Orion, ce qui a ensuite conduit à un partage généralisé du mauvais code.
Désormais, en raison du récent décret exécutif, les organisations qui fournissent des produits logiciels au gouvernement doivent fournir un SBOM pour chaque produit directement ou en le publiant sur un site Web public, selon le décret. Ce mandat est considéré comme une étape vers la garantie de la sécurité des produits logiciels et, espérons-le, comme une plus grande visibilité dans une chaîne d’approvisionnement logicielle.
Les ingrédients SBOM peuvent éventuellement pourrir
Répondre aux mandats de SBOM peut être une entreprise assez difficile pour les entreprises qui doivent se conformer aux exigences, car la construction et la maintenance d’un SBOM peuvent être un défi. Pourquoi? Les SBOM sont des enregistrements formels qui incluent les moindres détails et les relations de la chaîne d’approvisionnement de tous les différents composants que les organisations utilisent pour créer des produits logiciels. Pour certaines applications ou certains systèmes d’exploitation, cela peut être une entreprise complexe. La constitution de ce type de registre prend du temps, étant donné le volume considérable d’informations qui doivent être fournies et les multiples sources fournissant des intrants.
Une fois qu’un SBOM est développé, la tâche est loin d’être terminée. Un SBOM doit être mis à jour chaque fois qu’une modification est apportée à l’un des composants logiciels. Cela inclut les mises à jour de code, les correctifs de vulnérabilité, les nouvelles fonctionnalités et toute autre modification. Les soi-disant ingrédients d’un SBOM deviendront obsolètes si vous ne vous assurez pas qu’ils sont tenus à jour.
Parce que l’intégrité des informations est si importante, tout ce qui est inclus dans un SBOM doit être auditable. Cela inclut tous les numéros de version et les licences. Les données doivent être fournies par une source fiable et être vérifiables par un tiers.
Actuellement, ces mises à jour sont généralement effectuées manuellement. Et comme des changements peuvent survenir à tout moment, il s’agit d’un processus continu à forte intensité de main-d’œuvre. De plus, comme les changements doivent être suivis en temps réel pour que le SBOM soit efficace, c’est encore plus difficile.
Ajoutant à la complexité est le fait qu’il n’y a pas encore de normes définitives en place pour les SBOM. Au fur et à mesure que l’environnement d’une organisation change, elle doit créer de nouveaux SBOM. Cela signifie que le nombre de SBOM en place ne cesse de croître sans véritable réconciliation. Et cela, à son tour, augmente le défi de la maintenance.
Les SBOM dynamiques gardent les choses fraîches
La clé pour relever ces défis est de saisir l’idée que la création et la maintenance de SBOM doivent être un processus dynamique. Afin de garder ces ingrédients SBOM frais et pertinents, les entreprises doivent déployer des outils technologiques qui offrent la possibilité d’avoir un SBOM dynamique qui peut incorporer automatiquement des mises à jour chaque fois que des changements se produisent.
En général, les SBOM d’aujourd’hui sont des documents statiques qui n’intègrent pas automatiquement les mises à jour. Mais les SBOM de demain seront dynamiques. En fait, ce passage aux SBOM dynamiques deviendra éventuellement une exigence, en particulier pour les organisations qui créent et mettent à jour régulièrement de nombreux produits logiciels. Ceux qui construisent un SBOM et ne parviennent pas à aborder ce composant dynamique indispensable d’un SBOM ne réussiront pas. L’outil sera essentiellement inutile s’il n’est pas mis à jour
Les SBOM du futur seront également intégrés dans le cycle de vie de la sécurité des produits logiciels et seront produits automatiquement à des stades de développement prédéfinis. Ceci est extrêmement important, étant donné que de nombreux fournisseurs de logiciels ne savent même pas quelles vulnérabilités pourraient se trouver dans leurs produits logiciels et lesquelles sont exploitables.
Un SBOM dynamique peut vous garder en avance sur les menaces
Considérez la situation récente avec Log4j, un utilitaire de journalisation basé sur Java qui fait partie des services de journalisation Apache et l’un des nombreux frameworks de journalisation Java. En décembre 2021, des chercheurs en sécurité ont découvert une vulnérabilité de sécurité zero-day impliquant l’exécution de code arbitraire dans Log4j. Il a été caractérisé comme l’une des vulnérabilités les plus importantes et les plus critiques de ces dernières années.
Des vulnérabilités logicielles sont constamment découvertes, parfois au grand dam des entreprises qui développent les produits. Avec un peu de chance, ils sont découverts par des testeurs d’intrusion ou des pirates éthiques qui prennent des mesures pour divulguer les failles au développeur du logiciel, plutôt que par un cybercriminel qui exploite la vulnérabilité dans la nature.
Considérant que les vulnérabilités sont une réalité de la vie avec le développement de logiciels, il est pratiquement impossible d’identifier et de traiter toutes les vulnérabilités en temps opportun. C’est pourquoi l’intégration de la sécurité dans le cycle de vie du développement est si vitale, tout comme l’intégration des SBOM dans le cycle de vie du développement et leur production automatique à différents stades de développement.
La Cybersecurity and Infrastructure Security Agency (CISA) des États-Unis, qui fait partie du Département de la sécurité intérieure qui dirige les efforts nationaux pour gérer et réduire les risques pour les infrastructures cybernétiques et physiques, a déclaré que le SBOM est devenu un élément clé de la sécurité et de la fourniture de logiciels. gestion des risques de la chaîne.
Quiconque est impliqué dans la chaîne d’approvisionnement de logiciels, les producteurs, les acheteurs, les opérateurs doit comprendre le concept de SBOM et comment construire et maintenir ces ressources pour maximiser le temps et l’investissement dans l’outil.