En avril 2023, la CISA a publié un nouveau guide commun sur la sécurité des logiciels appelé Changer l’équilibre des risques liés à la cybersécurité : sécurité dès la conception et principes par défaut. Le guide a été rédigé avec la coopération de 9 agences différentes, dont la NSA, l'Australian Cyber Security Center (ACSC) et l'Office fédéral allemand pour la sécurité de l'information (BSI), entre autres. Le fait que plusieurs agences du monde entier aient coopéré à la préparation d’un guide sur la cybersécurité devrait être un témoignage fort de l’importance que revêt actuellement le sujet de la cybersécurité dans le monde entier.
Jen Easterly, directrice de CISA, a partagé ses réflexions sur le thème de la cybersécurité dans un récent discours qu'elle a prononcé devant les étudiants et les professeurs de l'Université Carnegie Mellon de Pittsburgh. Selon le directeur de la CISA, ces principes directeurs devraient aider à guider l'industrie mondiale du logiciel dans les années à venir :
- Le fardeau de la sécurité ne doit jamais incomber uniquement au client. Les fabricants de logiciels doivent assumer la responsabilité de leurs produits et de leur code.
- Les fabricants de technologies devraient adopter une transparence radicale comme engagement à rendre compte de leurs produits.
- Les fabricants de technologies devraient se concentrer sur la création de produits sûrs, en développant des produits qui sont à la fois sécurisés par conception et sécurisés par défaut.
Le guide CISA reprend ces principes de base et les développe, notamment une liste complète de suggestions pratiques que les fabricants de logiciels peuvent suivre pour commercialiser des produits plus sécurisés.
Il est intéressant de noter qu'un grand nombre de suggestions explicites sont basées sur Cadre SSDF du NIST mais formulé d'une manière plus pratique et moins volontaire.
L'une des suggestions du guide, directement liée à une transparence radicale, est que les fabricants de logiciels incluent la production d'un SBOM dans leur SDLC pour offrir une visibilité sur les composants de leur logiciel.
Mais est-ce vraiment suffisant de créer un SBOM et même de le publier ? Que peut réellement faire un producteur ou un consommateur de logiciels avec un fichier SBOM JSON ou XML ?
Dans cet article, nous examinerons les utilisations qu'un SBOM peut apporter aujourd'hui à un producteur de logiciels, les informations qui peuvent être ajoutées à un SBOM pour l'enrichir et la business intelligence qui peut être obtenue en examinant de tels documents enrichis. Nous examinerons rapidement l'aspect conformité de l'utilisation d'un SBOM et déterminerons où se situe votre responsabilité en tant que producteur de logiciels, agrégateur de logiciels ou responsable de la maintenance open source. Nous terminerons en parlant de la gestion des risques et de la manière dont les principes de sécurité dès la conception et de sécurité par défaut de la CISA s'articulent avec la conformité réglementaire en matière de cybersécurité et une gestion éclairée des risques.
Tous les SBOM n'ont pas été créés égaux
Il existe aujourd'hui de nombreux outils disponibles pour la création de SBOM, des solutions open source aux solutions propriétaires, une personne ou une entreprise souhaitant inclure la création de SBOM dans son SOP pourrait facilement le faire. On pouvait choisir entre les différents Normes celui le plus adapté à leurs besoins, mais même dans ce cas, vous pourriez être confronté à beaucoup trop d'outils pour prendre une décision éclairée. Alors, que pourriez-vous rechercher de plus pour choisir le bon Génération SBOM un outil pour vous ?
Tout d’abord, vérifiez quelles informations sont incluses ou omises dans la création du SBOM. Une nomenclature comprenant des outils et du code faisant partie du processus de développement mais ne faisant pas partie du produit lui-même contiendrait probablement de nombreuses informations redondantes qu'il est très difficile de « nettoyer » du fichier résultant pour vous permettre de conserver uniquement les informations les plus pertinentes. De même, les outils ou le code qui ne sont pas inclus ou volontairement omis manqueront manifestement lorsque vous souhaitez rechercher des vulnérabilités, par exemple.
La liste des ingrédients logiciels et des dépendances, en elle-même, n’a pratiquement aucun sens. Cela ne sert à rien au-delà de ce que vous pouvez choisir d’en faire. L'utilisation la plus répandue des SBOM aujourd'hui consiste à analyser les composants logiciels pour obtenir une liste des vulnérabilités susceptibles d'affecter votre produit.
Il est important de se rappeler qu'environ 95 % des vulnérabilités que vous découvrez ne sont pas exploitables dans votre produit. L’astuce consiste à trouver ces 5 % insaisissables, à élaborer un plan de travail et à commencer à traiter ces vulnérabilités exploitables. Comment distinguer ce qui est exploitable de ce qui ne l’est pas ? C'est la grande question qui empêche les responsables de la sécurité et de l'ingénierie de dormir la nuit. Une suggestion actuelle consiste à utiliser une solution appelée VEXER – un Vulnerability Exploitability eXchange, une forme d'avis de sécurité dont le but est de communiquer l'exploitabilité des composants présentant des vulnérabilités connues dans le contexte du produit dans lequel ils sont utilisés. Cela laisse encore une grande partie du travail de tamisage de la botte de foin d'informations sur les vulnérabilités et de recherche des vulnérabilités exploitables, principalement à l'équipe d'ingénierie. Après tout, qui connaît mieux son produit que ceux qui l’ont codé ?
Cependant, vous pouvez faire d'autres choses, en particulier lorsqu'il s'agit de vulnérabilités héritées provenant d'images parentes de votre image Docker ou de dépendances situées très en arrière dans votre chaîne de dépendances. Utiliser des outils open source comme image parent vous pouvez déterminer quelles vulnérabilités accompagnaient l'image parent et lesquelles étaient le résultat direct de votre code. Cela devrait éliminer un bassin potentiellement important de vulnérabilités et faciliter le travail de tri. Utiliser divers conseils sur différentes vulnérabilités est également une bonne idée, car une fois que vous avez déterminé qu'une vulnérabilité n'est pas exploitable, il est logique d'en informer les autres membres de votre équipe ou vos utilisateurs afin de ne pas continuer à vérifier la même vulnérabilité dans chaque version. de votre produit où vous n'avez même pas modifié le module dans lequel il a été trouvé. Il est également conseillé de suivre vos dépendances open source et tierces afin qu'une fois qu'ils ont trouvé et corrigé les vulnérabilités exploitables, vous puissiez mettre à jour ce code dans votre produit pour faire assurez-vous que vous êtes également protégé contre ce problème potentiel particulier.
Que pouvez-vous ajouter de plus par rapport à un SBOM ?
Comme indiqué ci-dessus, l’une des utilisations les plus courantes des SBOM aujourd’hui est la liste de contrôle pour l’analyse des vulnérabilités. En utilisant diverses bases de données disponibles gratuitement comme la NVD (National Vulnerability Database), vous pouvez analyser une liste de composants, similaire à celle fournie par un SBOM, et voir quelles vulnérabilités elle contient. Une fois que vous avez une liste de vulnérabilités, vous pouvez la classer par gravité, vérifier si certaines disposent de correctifs existants, etc.
Une autre couche d’informations qu’il est utile d’avoir sur vos composants est leur licence. De nombreux composants open source sont accompagnés d’une licence qui n’est pas compatible avec une utilisation commerciale. Il est important de vous assurer que tous vos composants open source, même ceux que vous n'avez pas inclus vous-même mais qui ont été inclus par un autre composant, sont compatibles avec tout ce que vous essayez de créer en termes de licence.
Une dernière suggestion est de suivre les compteurs de sécurité open source pour vos dépendances telles que Tableau de bord OpenSSF. Disposer d'une mesure objective relativement simple de la santé de la cybersécurité des bibliothèques open source pourrait s'avérer d'une grande aide pour décider quelles bibliothèques inclure ou exclure de votre produit. Ces scores, combinés à la gravité des vulnérabilités, sont un bon moyen de vous aider à classer les vulnérabilités sur lesquelles vous souhaitez travailler en premier.
La gestion des risques comme exercice de business intelligence
Il existe plusieurs risques de sécurité pour tout producteur de logiciels de nos jours. Entre les logiciels malveillants, les mineurs de cryptomonnaies, les voleurs de mots de passe et les ransomwares, il est étonnant que les fabricants se sentent en sécurité lorsqu'ils commercialisent quoi que ce soit. Personne ne peut tout gérer en même temps, c’est pourquoi les entreprises créent des modèles de menace et tentent de gérer leurs risques en fonction de ce qu’elles considèrent comme leur maillon le plus faible. La première étape la plus simple consiste à vous assurer que votre code et votre processus de développement sont conformes à toutes les réglementations et bonnes pratiques en vigueur. SSDF du Nist et OpenSSF SLSA sont un bon point de départ, ainsi que les exigences américaines pour des choses comme un SBOM. Le respect des réglementations et des meilleures pratiques pourrait au moins promettre une relative sécurité face aux litiges en vertu de la loi. Safe Harbor programme. Mais ce n'est qu'un début.
Le guide CISA encourage les fabricants à aborder la construction de leurs produits en pensant d'abord à la sécurité. Une certaine sécurité « renforcée » une fois le produit terminé ne peut pas atténuer certaines faiblesses fondamentales qui font partie de l'architecture du produit. Selon le guide, les produits sécurisés dès la conception sont ceux pour lesquels la sécurité des clients est un objectif commercial essentiel, et pas seulement une fonctionnalité technique. Les fabricants sont également encouragés à adopter transparence radicale et responsabilité. Cela signifie, entre autres choses, veiller à ce que les avis de vulnérabilité et les vulnérabilités et expositions communes associées (CVE) les dossiers sont complets et exacts. Cela signifie également que les composants du code, ses dépendances et ses vulnérabilités sont encouragés à être partagés afin de montrer aux utilisateurs et aux clients que le fabricant est au moins conscient des problèmes potentiels du produit.
Selon Wikipedia, Business Intelligence (BI) comprend les stratégies et les technologies utilisées par les entreprises pour l'analyse des données et gestion des informations commerciales. Comme vous pouvez l'imaginer, collecter un SBOM pour chaque build ainsi que le rapport de vulnérabilité, les informations de licence et les avis qui détaillent les vulnérabilités qui sont et ne sont pas exploitables – cela représente beaucoup d'informations. Le nombre de points d'information augmente lorsque vous tenez compte de la durée de vie d'un produit logiciel typique et du fait que vous souhaitez disposer de ces informations pour tout code ou outil tiers que vous utilisez ainsi que pour les packages open source que vous incluez, directement ou de manière transitoire. Afin de donner un sens à tout cela d'une manière qui soit utilisable par les pouvoirs en place en matière de sécurité de l'organisation (probablement le RSSI et les personnes qui en dépendent), vous avez besoin d'un système, d'une plate-forme unique. qui vous permet d'organiser toutes ces informations, de les rechercher efficacement et de les présenter dans des rapports utiles en cas de besoin. Pour ne donner qu'un exemple de l'importance d'une plateforme de BI pour une plateforme de cybersécurité, imaginez le Log4J drame de l'année dernière. Ne serait-il pas génial de rechercher cette « nouvelle » menace dans tous vos produits, y compris les dépendances et les outils tiers, en quelques touches ? Que diriez-vous de vérifier la présence d’un nouveau CVE menaçant qui vient de sortir ? Ou préparer un rapport sur la manière dont le nombre global de vulnérabilités de votre entreprise diminue progressivement au fil du temps (ou du moins n'augmente pas). C'est le genre d'informations utiles que seul un système BI associé à une plateforme de collecte enrichie en cybersécurité SBOM peut offrir.
Ce n'est qu'une fois que vous disposerez de toutes les informations pertinentes que vous pourrez véritablement évaluer votre risque, à la fois dans votre code actuel, dans vos dépendances et en choisissant d'inclure ou d'omettre un outil ou un code tiers de votre produit. Lorsqu'elle est exécutée en continu, vous pouvez également utiliser cette évaluation des risques pour contrôler les builds et arrêter leur production ou leur livraison si une activité suspecte est découverte.
Regarder vers l'avenir
La technologie ne cesse de progresser. Si autrefois les projets de code monolithiques hébergés sur des serveurs situés dans les bureaux de l'organisation étaient la norme, c'est aujourd'hui l'architecture de microservices multi-cloud et les LLM qui ouvrent la voie. Les SBOM doivent continuer à progresser pour pouvoir prendre en charge toute architecture complexe ou infrastructure logicielle utilisée pour conserver leur pertinence et leur utilité. CycloneDX de l'OWASP, par exemple, travaille déjà à inclure Transparence du ML dans leur format SBOM. Le même format veille également à inclure des fonctionnalités VEX et une API de partage SBOM lors de la planification de l'avenir. Je prédis que de plus en plus de plateformes comme celle créée par Scribe sera créé pour l'accumulation et le partage d'informations liées à la sécurité, y compris les SBOM, à la fois pour des raisons réglementaires et pour l'avantage et la valeur que ces informations enrichies présentent pour les organisations qui les utilisent correctement.
La plate-forme Scribe est sur le point de publier un nouvel outil BI dans le cadre de la plate-forme de sécurité existante avec toutes les fonctionnalités que j'ai suggérées et bien plus encore. Je vous encourage à Essaie, voyez l’utilité de ces informations accumulées au fil du temps et voyez à quoi vous pouvez utiliser ces informations. Que vous choisissiez ou non d'intégrer la plateforme Scribe dans votre SDLC, la course à un écosystème plus sécurisé et à un SBOM plus complet et plus utile est loin d'être terminée. Il est préférable de s'engager dans la voie de la transparence dès maintenant plutôt que de se voir imposer une transparence radicale par la réglementation ou la pression du marché.
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.
articles similaires
