Avec l’utilisation croissante de composants tiers et la longueur des chaînes d’approvisionnement en logiciels, les attaquants peuvent désormais compromettre plusieurs progiciels simultanément via un seul exploit. En réponse à ce nouveau vecteur d'attaque, davantage d'équipes de développement et DevOps, ainsi que de professionnels de la sécurité, cherchent à intégrer une nomenclature logicielle (SBOM).
La chaîne d'approvisionnement logicielle comprend tout ce qui est utilisé pour créer l'application, depuis le code unique que les ingénieurs écrivent jusqu'aux outils de développement qu'ils utilisent, en passant par tous les composants tiers (propriétaires et open source) dans la base de code. Même si les développeurs assument la responsabilité de leur propre code, un SBOM suit les informations nécessaires pour assurer la sécurité de chaque composant tiers. Ceci comprend:
- D'où il provient
- La version spécifique utilisée
- Toutes les vulnérabilités connues et l'état des correctifs
- Où et quand il est utilisé dans l'application
- Informations sur la licence
Et toute autre information de sécurité pertinente.
En comprenant chaque ligne de code entrant dans le produit final, les organisations peuvent démontrer des pratiques de développement sécurisées et fournir des assurances à leurs clients.
Les SBOM étant de plus en plus utilisés, le cabinet de recherche et de conseil en informatique Gartner a récemment publié « Innovation Insight for SBOMs», un rapport décrivant le concept, ses avantages, les différentes normes utilisées et des recommandations pour les organisations mettant en œuvre des SBOM.
Comme de nombreuses personnes n'ont pas accès au rapport complet de Gartner, nous présentons certaines des principales conclusions ainsi que notre propre point de vue sur ce que les organisations doivent prendre en compte pour une utilisation réussie du SBOM. Mais d'abord, parlons de l'état actuel de attaques de la chaîne d'approvisionnement logicielle.
Les risques croissants pour les chaînes d’approvisionnement en logiciels
Même si les progiciels tentent de se différencier de la concurrence et de se concentrer sur ce qui les différencie, il y aura toujours un certain chevauchement en termes de fonctionnalités de base. Par exemple, chaque organisation devra chiffrer les données des utilisateurs, et la plupart devront envisager de les synchroniser sur plusieurs appareils.
Même si les développeurs pourraient consacrer beaucoup de temps et d’efforts à écrire du code pour exécuter ces fonctions générales, il est beaucoup plus facile d’incorporer des composants prêts à l’emploi déjà utilisés. Qu'il soit acheté ou open source, le code tiers simplifie le processus de développement et réduit considérablement les délais de mise sur le marché.
Cependant, cela introduit également des vulnérabilités. Aujourd’hui, les logiciels sont aussi sécurisés que le maillon le plus faible de la chaîne d’approvisionnement. Les attaquants exploitent ce fait, ciblant de plus en plus les composants couramment utilisés ou obsolètes dans la chaîne d’approvisionnement logicielle.
Un rapport récent n'a détecté que 216 attaques contre la chaîne d'approvisionnement logicielle entre février 2015 et juin 2019. Ce nombre a grimpé de manière significative pour atteindre 929 attaques entre juillet 2019 et mai 2020, suivi d'une explosion avec plus de 12,000 2021 attaques contre la chaîne d'approvisionnement logicielle en 650, sur un an. augmentation de XNUMX%.
Enquête Forrester sur 530 décideurs en cybersécurité ont constaté que 33 % des attaques externes proviennent désormais de services tiers ou de vulnérabilités logicielles.
Compte tenu de la récente accélération des attaques, il n’est pas surprenant que le gouvernement américain ait pris des mesures sécurité de la chaîne logistique logicielle une nouvelle priorité. Cela inclut la publication du Cadre de développement logiciel sécurisé (SSDF) et un septembre 2022 Mémo de l'OMB fixer des priorités d’investissement en matière de cybersécurité pour l’exercice 2024, toutes deux accordant une grande attention à l’atténuation des risques liés à la chaîne d’approvisionnement.
Avec des attaques qui montent en flèche, des exemples célèbres dans l'actualité (par exemple, SolarWinds, Log4J, etc.) et le gouvernement américain qui tire la sonnette d'alarme, les organisations doivent accroître la visibilité de leur chaîne d'approvisionnement en logiciels et maintenir une nomenclature logicielle complète pour chacun d'entre eux. leurs produits.
Les SBOM à la rescousse ! Augmenter la visibilité, la confiance et la sécurité dans les chaînes d'approvisionnement logicielles
La nécessité est mère de l’invention, et une menace aussi importante que les attaques contre la chaîne d’approvisionnement nécessite certainement une solution. Heureusement, l’invention des SBOM signifie que nous disposons désormais des outils nécessaires pour riposter, garantissant que seuls des composants sécurisés et fiables figurent dans la base de code.
SBOM est basé sur les nomenclatures physiques (BOM) que l'on trouve couramment dans la fabrication ou la construction. Par exemple, les constructeurs automobiles utilisent une nomenclature pour inventorier chaque composant utilisé dans chaque véhicule, qu'il ait été construit par le constructeur OEM ou par un tiers. Si un problème survient avec une pièce particulière, les nomenclatures permettent aux constructeurs d'identifier chaque véhicule concerné et d'en informer le propriétaire.
Les SBOM sont l'équivalent de l'industrie du logiciel. Agir comme un inventaire pour chaque composant logiciel présent dans chaque produit. Si un composant présente une vulnérabilité, les organisations peuvent rapidement déterminer les utilisateurs concernés et élaborer des plans pour informer et atténuer le risque.
Avec des piles logicielles complexes intégrant un grand nombre de composants open source et tiers, il peut être difficile de suivre tous les risques auxquels un produit est exposé. Les SBOM permettent aux équipes de développement, DevOps et de sécurité, et même aux clients, de comprendre ce risque, en cherchant rapidement si une vulnérabilité nouvellement identifiée les affecte.
Les SBOM aident également à :
- Prévenir l'empoisonnement des licences : lorsque des composants open source ouvrent votre propriété intellectuelle, exposant votre produit à la vue de tous.
- Identifiez les risques dans le code existant : décomposez les bases de code existantes pour identifier chaque bibliothèque tierce, référentiels open source, outils de développement, etc. afin de déterminer les composants potentiellement obsolètes ou tout autre risque présent.
Avec de nombreux avantages offerts, les SBOM connaissent une adoption significative. Cependant, un récent (ici) ont constaté que si 76 % des organisations ont un certain degré de « préparation au SBOM », seules 47 % utilisaient activement les SBOM en 2021. Ce chiffre devrait atteindre plus des trois quarts des organisations en 2022 (78 %) et près de 90 % des organisations. l'année suivante.
Rapport Innovation Insight de Gartner pour les SBOM – Résumé de haut niveau
Le rapport Innovation Insight 2022 de Gartner sur les SBOM offre des informations essentielles sur l'importance et la mise en œuvre de la nomenclature logicielle :
« Les nomenclatures logicielles améliorent la visibilité, la transparence, la sécurité et l'intégrité du code propriétaire et open source dans les chaînes d'approvisionnement logicielles. Pour bénéficier de ces avantages, les responsables de l'ingénierie logicielle doivent intégrer les SBOM tout au long du cycle de vie de la livraison des logiciels.
Les organisations ont souvent du mal à maintenir la visibilité des dépendances propriétaires et open source, ce qui génère d'importantes risques liés à la sécurité de la chaîne d'approvisionnement logicielle et les problèmes potentiels de conformité. En effet, ils manquent d’outils adéquats ou ne parviennent pas à mettre en œuvre des pratiques et des normes de développement sécurisées.
Avec un SBOM, les développeurs peuvent découvrir et compiler des détails de sécurité sur chaque élément de code tiers de leur progiciel. L’augmentation des attaques contre la chaîne d’approvisionnement logicielle démontre l’incapacité de traiter le code open source ou commercial comme une « boîte noire » hermétique et sécurisée.
Sans savoir ce qu'il y a à l'intérieur de la « boîte », vous ne pourrez jamais vraiment comprendre les risques auxquels votre logiciel est exposé. Par conséquent, la meilleure solution consiste à suivre méticuleusement chaque « case » que vous utilisez pour vérifier les vulnérabilités connues.
Gartner recommande à chaque organisation :
- Générer un SBOM pour chaque progiciel qu'ils produisent
- Vérifier les SBOM pour tous les logiciels consommés (qu'ils soient open source ou commerciaux)
- Réévaluer en permanence les données SBOM pour comprendre les nouveaux risques de sécurité (avant et après le déploiement)
Compte tenu du paysage de plus en plus menaçant de la chaîne d’approvisionnement logicielle, Gartner prédit que 60 % des organisations qui créent ou achètent des logiciels pour leurs infrastructures critiques imposeront des SBOM. C'est le triple du chiffre actuel (20 %) en 2022.
« Les SBOM sont un outil essentiel dans votre boîte à outils de sécurité et de conformité. Ils aident à vérifier en permanence l’intégrité des logiciels et à alerter les parties prenantes des vulnérabilités de sécurité et des violations des politiques.
Comment tout cela vous affecte-t-il ?
Alors, qu’est-ce que tout cela signifie pour vous et votre organisation ? Gartner recommande aux organisations :
- Utiliser les SBOM pour suivre les dépendances tout au long de la chaîne d'approvisionnement logicielle, en tenant compte de chaque composant du cycle de vie du développement logiciel
- Automatisez la génération de SBOM à l'aide d'outils permettant d'analyser et de vérifier systématiquement vos produits
- Répondez rapidement à tout composant concerné trouvé dans la chaîne d’approvisionnement logicielle
- Mettre à jour les SBOM avec chaque nouvel artefact logiciel, c'est-à-dire créer des SBOM pendant le processus de construction plutôt qu'au début d'un projet.
- Réutilisez uniquement les modules avec des SBOM vérifiés et sécurisés
- Implémentez un processus SBOM basé sur des normes basées sur des formats largement pris en charge, tels que Software Package Data Exchange (SPDX), Software Identification (SWID) ou CycloneDX.
- Assurez-vous que tous les fournisseurs de logiciels commerciaux avec lesquels vous travaillez utilisent également les SBOM avec une approche basée sur des normes.
- Partager les SBOM et les données de provenance avec les parties prenantes, en les informant des composants affectés et des données liées aux risques
Les SBOM sont des outils essentiels pour la sécurité des logiciels modernes. Mais pour améliorer la situation dans l’ensemble du secteur, ils doivent être rendus accessibles à l’intérieur et à l’extérieur de l’organisation. Le partage de données de vulnérabilité sous la forme d'un SBOM augmente également la confiance des parties prenantes, en leur faisant savoir qu'aucune vulnérabilité connue n'est présente dans le logiciel qu'elles utilisent.
Scribe Security propose une plateforme de gestion SBOM hébergée avec des capacités de partage. Aider les organisations à garantir l’intégrité des conteneurs et à fournir des informations exploitables sur les logiciels qu’elles produisent. Commencez gratuitement en vous inscrivant pour un accès anticipé au Plateforme de scribe.
Scribe Security reprend le rapport de Gartner : la transparence et les preuves sont essentielles
At Scribe Sécurité, nous pensons que les SBOM sont essentiels à la protection des progiciels modernes construits sur des chaînes d'approvisionnement en expansion. Les SBOM documentent de manière exhaustive le processus de développement pour garantir une visibilité de bout en bout sur l’ensemble de la chaîne d’approvisionnement. Notre plateforme allie visibilité d'une SBOM et transparence, grâce à des fonctionnalités de partage entre équipes et organisations.
Scribe fournit une plateforme où les producteurs et les consommateurs de logiciels peuvent se réunir pour partager des attestations sur la fiabilité de divers progiciels ou composants logiciels. Nous utilisons des techniques cryptographiques pour collecter des signatures numériques qui suivent les modifications au cours du développement. Ces signatures assurent une base probante garantissant la validité et la sécurité de la chaîne d'approvisionnement d'un logiciel.
Même les petites opérations qui n’envisagent pas de générer des SBOM pour le moment peuvent bénéficier d’une compréhension du processus. Scribe propose des analyses continues, même si vous disposez d'une version stable en production, afin que vous puissiez rechercher de nouvelles vulnérabilités et identifier les tendances tout au long de votre cycle de vie de développement logiciel.
Résumé
Face à l’incroyable croissance des attaques contre la chaîne d’approvisionnement logicielle, les organisations doivent envisager de nouvelles méthodes pour garantir la sécurité des produits logiciels qu’elles créent et des produits logiciels qu’elles utilisent.
La première étape consiste à générer une nomenclature logicielle détaillant tous les composants présents dans les bases de code du progiciel. Comprendre ce qui est en cours d'exécution permet aux organisations de garder une longueur d'avance sur les vulnérabilités et de partager l'intégrité des versions d'applications.
Le récent rapport de Gartner sur les SBOM résume bien la situation :
« Les SBOM aident les organisations à déterminer si elles sont sensibles aux vulnérabilités de sécurité précédemment identifiées dans les composants logiciels. Ces composants peuvent être des bibliothèques de logiciels développés en interne, achetés commercialement ou open source. Les SBOM génèrent et vérifient des informations sur la provenance du code et les relations entre les composants, ce qui aide les équipes d'ingénierie logicielle à détecter les attaques malveillantes pendant le développement (par exemple, l'injection de code) et le déploiement (par exemple, la falsification binaire).
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.