Acronyme de Software Bill of Materials, le SBOM décrit les composants logiciels utilisés dans un logiciel ou un système. Les SBOM visent à réduire les risques et à améliorer transparence et sécurité autour des applications produites par l’entreprise. Voici 3 conseils sur leur création.
Les développeurs et les professionnels de la sécurité ont encore en tête les dommages causés par la vulnérabilité Log4j identifiée en décembre 2021. Dans les organisations, les nombreuses attaques qui ont suivi – sans parler des nuits blanches passées à essayer de corriger les vulnérabilités – ont fait prendre conscience du risque que représentent les composants open-source et de la manière dont les chaînes d’approvisionnement logicielles étaient souvent très exposées.
Ce sentiment de vulnérabilité a conduit de nombreuses organisations à prendre des mesures concrètes. Ainsi, les équipes de développement ont commencé à collaborer plus étroitement avec les équipes chargées de la cybersécurité afin de renforcer leurs chaînes d’approvisionnement à l’aide de nomenclatures logicielles (Software Bill Of Materials ou SBOM). En fait, l’année dernière, les organisations ont augmenté de 30 % la création et la maintenance des SBOM. L’objectif est d’aider les organisations à se protéger contre les risques introduits par l’utilisation de logiciels libres et l’intégration de codes open-source en fournissant une liste des composants – les librairies – qui constituent le logiciel final. À l’instar d’une liste d’ingrédients pour un gâteau, les SBOM offrent une visibilité sur tous les « ingrédients », open-source et commerciaux, qui composent un logiciel.
Mais le chemin à parcourir est encore long pour de nombreuses organisations, car elles n’ont tout simplement pas la maturité et/ou les ressources nécessaires pour mettre en œuvre l’utilisation à grande échelle des SBOM. Cela dit, il s’agit d’une étape essentielle pour garantir la sécurité de votre organisation. Dans cette optique, voici trois conseils clés à l’intention de toute organisation désireuse de commencer ou d’améliorer sa mise en œuvre des SBOM.
Disposer de capacités de remédiation en temps réel
L’économie est aujourd’hui alimentée par des logiciels libres, mais le projet de développement d’une application moyenne contient près de cinquante vulnérabilités réparties sur quatre-vingts dépendances directes (selon un rapport Snyk). Pour ne pas arranger les choses, les dépendances indirectes sont beaucoup plus difficiles à suivre – chaque bibliothèque tierce utilisée dans un projet apporte des couches de code supplémentaires que les équipes de développement doivent désormais suivre. Cela peut prendre des semaines, voire des mois pour remédier manuellement à ces problèmes. Pour le résoudre, une solution SBOM bien conçue devrait non seulement identifier les vulnérabilités, mais aussi y remédier en temps réel. Les SBOM sont là pour permettre aux développeurs de comprendre les éléments constitutifs des bibliothèques partagées qui composent les applications et les systèmes d’exploitation d’une organisation. Mais pour être vraiment efficace, la solution doit aller plus loin en remédiant à ce qui est identifié. Avec des millions de bibliothèques open-source utilisées, les capacités de remédiation s’avèrent être une nécessité.
S’appuyer sur les données des endpoints
Supposons que les équipes informatiques et de sécurité soient informées de l’existence d’une vulnérabilité open-source dans la chaîne d’approvisionnement logicielle. La première étape consiste à trouver l’emplacement de cette faille zero-day sur l’ensemble de ses endpoints. Une étude récente a montré que 68 % des organisations dans le monde ont déjà subi une ou plusieurs attaques sur leurs endpoints qui ont compromis des données ou leur infrastructure informatique. Les endpoints sont les actifs qui ont un impact immédiat sur les utilisateurs finaux, de sorte que lorsqu’un SBOM est créé, l’organisation doit être en mesure d’analyser des fichiers spécifiques sur ces terminaux.
Pour les organisations, il faut alors se concentrer sur la recherche des dommages sur tous les actifs individuels et examiner individuellement le contenu des fichiers présents dans l’environnement informatique en se posant les bonnes questions. Combien de terminaux présentent cette vulnérabilité spécifique ? Connaissez-vous tous les appareils présents sur votre réseau ? Quel est l’état d’avancement du nettoyage et de la découverte ?
Les deux vulnérabilités découvertes dans la bibliothèque OpenSSL en novembre 2022 illustrent parfaitement l’impact considérable qu’une seule vulnérabilité peut avoir sur les millions de endpoints qui utilisent la plateforme. En exploitant les données relatives aux endpoints pour analyser la composition des logiciels, les organisations seront en mesure d’identifier cette vulnérabilité et d’autres similaires de la chaîne d’approvisionnement logicielle.
Garantir le plus haut niveau de visibilité
Une visibilité granulaire et en temps réel est une exigence clé pour bénéficier d’un SBOM efficace, car il est impossible de protéger ce que l’on ne connaît pas. Le SBOM doit contenir une liste exhaustive de tous les paquets et de toutes les bibliothèques partagées utilisés dans chaque application, ainsi que leur numéro de version. De cette manière, si une vulnérabilité est publiée pour un paquet spécifique, il est possible de mettre à jour ce paquet, de le supprimer ou de contacter le vendeur pour voir si un nouveau correctif est disponible.
En disposant d’une telle base de connaissances dynamique, il est envisageable de garder une longueur d’avance sur ceux qui cherchent à exploiter une vulnérabilité de ce type. Par exemple, lors de la découverte de la vulnérabilité de Log4j, de nombreux chercheurs en sécurité essayaient aveuglément d’exploiter la vulnérabilité dans leurs propres laboratoires. Ils ont rapidement découvert que de nombreux fournisseurs n’avaient même pas signalé avoir été touchés. Avec un SBOM, cette approche à l’aveugle n’aurait pas lieu d’être car les chercheurs auraient eu une visibilité sur l’endroit exact où enquêter de façon plus détaillée.
Toutefois, les exploits de bibliothèques partagées et de chaînes d’approvisionnement logicielles deviennent de plus en plus courants car les entreprises continuent de s’appuyer sur des composants open-source pour créer rapidement du code. Bien que les SBOM soient un élément essentiel d’une stratégie de sécurité de la chaîne d’approvisionnement logicielle, la création et la maintenance d’un tel outil incombent principalement à l’équipe de développement. En tant que développeur, il est donc nécessaire d’apprendre à utiliser au mieux un SBOM car il offre une visibilité qui peut faire la différence entre un incident opérationnel mineur et une perturbation complète de l’activité avec des conséquences à long terme.
Dans les années à venir, les risques liés à la chaîne d’approvisionnement logicielle continueront d’être sous les feux de la rampe. Pour tout acteur de cette chaîne, il est impératif d’utiliser des outils d’analyse de la composition des logiciels (SCA), en particulier le SBOM, afin que l’organisation puisse identifier où se trouve la prochaine vulnérabilité OpenSSL ou Log4j avant qu’elle ne se propage.
___________________
par Matt Psencik, Director of Endpoint Security chez Tanium
puis