Pourquoi votre organisation a besoin d'une nomenclature logicielle

janvier 9, 2022 Par admin 0
Pourquoi votre organisation a besoin d'une nomenclature logicielle

Crédit d'image: metamorworks/Getty Images

Écoutez les DSI, les CTO et d'autres cadres supérieurs et cadres sur les données et les stratégies d'IA au Sommet sur l'avenir du travail ce 12 janvier 2022. En savoir plus

La récente vulnérabilité Log4j a exposé des problèmes systémiques dans la façon dont les entreprises et la communauté au grand, auditez leur logiciel.

Les premières indications montrent que la vulnérabilité Log4j était en train d'être militarisée et exploitée quelques jours avant l'annonce de la nouvelle sur son existence. Les organisations devaient prendre des mesures immédiatement pour trouver toutes les instances de la vulnérabilité dans les bibliothèques liées, mais la plupart n'avaient pas d'aperçu clair de l'endroit où ces instances existaient dans leurs systèmes. Les propres recherches de Google ont montré que plus de 8% de tous les packages sur Maven Central ont une version vulnérable de Log4j dans leurs dépendances, mais de ce groupe seulement un cinquième l'a déclaré directement. Cela signifie qu'environ 28 000 packages sur Maven Central sont affectés par ces bogues sans jamais déclarer ou utiliser directement Log4j.

Trouver toutes les instances de dépendances vulnérables et confirmer les niveaux de correctifs peut être une tâche ardue, même pour les logiciels que vous contrôlez et développez entièrement en interne. L'identifier chez vos fournisseurs peut être encore plus difficile. Souvent, ces fournisseurs ont une idée tout aussi floue de leurs propres dépendances.

Comme tout autre actif informatique tel que serveurs, ordinateurs portables ou applications installées, disposer d'un inventaire précis de vos logiciels et de vos dépendances (directes et transitives) est un contrôle de sécurité essentiel, et sans doute le plus fondamental, que vous puissiez appliquer. Les entreprises ne peuvent pas sécuriser ce dont elles ne sont pas conscientes. Comment les entreprises commencent-elles à prendre le contrôle de la complexité croissante des dépendances ? En auditant et en automatisant les graphes de dépendances, en commençant par les dépendances directes et en passant par les dépendances transitives, souvent appelées nomenclature logicielle (SBOM).

Bien qu'il y ait des nuances dans la discussion sur ce qu'un SBOM devrait être et contenir, pour les besoins de cet article, nous nous référerons simplement de manière informelle à un SBOM en tant que manifeste de tous les composants et bibliothèques fournis avec une demande, ainsi que leurs licences. Cela inclut les outils et les bibliothèques liées. Si vous fournissez une image Docker, elle doit également inclure la liste de tous les packages installés.

Devenir sérieux à propos de votre chaîne d'approvisionnement de logiciels

Malheureusement, le L'écosystème pour générer ces cartes de dépendances souffre souvent d'un manque d'outillage suffisant. Alors que les outils disponibles pour analyser les dépendances des vulnérabilités évoluent et s'améliorent rapidement, le domaine en est encore à ses balbutiements. Snyk, Anchore et d'autres outils offrent une visibilité incroyable sur les dépendances de votre application, mais peu de langages fournissent des outils natifs pour générer des cartes visuelles complètes. À titre d'exemple, examinons un langage plus ancien (Java) et un langage plus récent (Go) qui a bénéficié du temps et de l'expérience nécessaires pour développer un écosystème de packages moderne.

En Java, les développeurs peuvent utiliser des outils comme jdeps (introduit dans le JDK 8) ou Maven Dependency Analyzer, tandis que Golang, malgré sa modernité, a eu du mal très tôt à déterminer sa propre dépendance histoire de gestion et a plutôt permis à des outils comme Dep (obsolètes et archivés) de combler les lacunes avant de finalement s'installer sur son propre système de modules. Dans les deux cas, les dépendances directes sont généralement faciles à énumérer, mais une liste complète et complète des dépendances directes et transitives peut être difficile à générer sans outils supplémentaires.

    Pour les mainteneurs open source, Google a lancé un projet très utile appelé Open Source Insights pour l'audit de projets hébergés sur NPM, PyPI ou Github, ou des emplacements similaires. Il y a déjà une quantité importante de travail et de recherche appliquée dans ce domaine, mais il est clair qu'il reste encore beaucoup à faire.

  1. Bien qu'il soit essentiel que les applications elles-mêmes soient auditées pour les dépendances et les vulnérabilités, ce n'est que le début de l'histoire. Tout comme un inventaire d'actifs ou un rapport de vulnérabilité ne peut que vous dire ce qui existe, un SBOM n'est qu'un manifeste de packages et de dépendances. Ces dépendances doivent être auditées pour leur santé relative au-delà des vulnérabilités qui pourraient être signalées. Par exemple, une dépendance peut ne pas répondre aux qualifications pour être signalée au National Institute of Standards and Technology (NIST) et peut ne pas avoir d'exposition aux vulnérabilités communes (CVE) attribuée pour une raison quelconque, qu'il s'agisse d'un problème d'abandonware ou d'un produit entièrement interne. c'est relativement peu scruté. D'autres raisons pour lesquelles il peut ne pas être signalé incluent la propriété ou la maintenance de la bibliothèque ayant été transférée à un mauvais acteur, des mauvais acteurs modifiant intentionnellement des versions, des packages obsolètes et vulnérables dans le conteneur Docker exécutant l'application et/ou des hôtes exécutant d'anciens noyaux avec des noyaux connus et critiques. CVE.

    Les responsables de la sécurité de l'organisation sont chargés d'étudier et de réfléchir en profondeur aux problèmes de la chaîne d'approvisionnement logicielle qui pourraient affecter leurs produits ou leur entreprise, et tout commence par la collecte d'un inventaire précis des dépendances dans le SBOM.

  2. Génération d'un SBOM

    La génération d'un SBOM peut être un défi technique en soi, mais n'oubliez pas que les organisations sont faites de personnes et de processus. Comprendre et évangéliser la nécessité d'un tel travail est d'une importance cruciale pour obtenir l'adhésion. Comme mentionné ci-dessus, les responsables de la sécurité dans les organisations doivent commencer par dresser un inventaire de tous leurs logiciels, conteneurs et packages ou applications de fournisseurs tiers. Une fois le premier niveau d'inventaire terminé, l'étape suivante consiste à déterminer les dépendances directes et enfin les dépendances transitives. Ce processus doit ressembler beaucoup à tout autre processus de détection, tel que la journalisation des événements ou l'inventaire des actifs.

    Lorsque vous évangélisez un SBOM auprès de votre organisation, tenez compte des avantages suivants:

    Un complet, jusqu'à- date, et un inventaire précis de vos dépendances logicielles réduit considérablement le temps de résolution lorsque des vulnérabilités dans des packages tels que Log4j sont découvertes.

Un manifeste généré au cours du processus CI/CD fournit également un retour instantané sur les nouvelles dépendances et peut empêcher l'inclusion de nouveaux composants vulnérables dans votre logiciel en appliquant des politiques au moment de la construction.

)

On dit souvent que ce qui est mesuré s'améliore. Garder un œil sur vos dépendances encourage l'hygiène en supprimant les dépendances inutiles et en supprimant les anciennes.

  • Ce encourage l'uniformité de la gestion des versions des logiciels, ce qui permet aux équipes d'ingénierie et de sécurité d'économiser du temps et de l'argent.

  • Selon la Maison Blanche, cela deviendra bientôt une exigence de conformité pour de nombreuses organisations.

    Comme la complexité de nos piles logicielles continue d'augmenter et les chaînes d'approvisionnement deviennent des cibles de plus en plus tentantes et viables pour les attaquants, les techniques et les outils tels que la gestion des dépendances et les SBOM doivent devenir des éléments essentiels de notre stratégie de sécurité globale. Et les responsables de la sécurité ont la responsabilité de communiquer ces avantages de ces outils à leurs organisations.

    Bren Briggs est directeur du DevOps et de la cybersécurité chez Hypergiant.

      VentureBeat

      La mission de VentureBeat est d'être une place de ville numérique permettant aux décideurs techniques d'acquérir des connaissances sur technologie de transformation et transaction. Notre site fournit des informations essentielles sur les technologies et les stratégies de données pour vous guider dans la gestion de vos organisations. Nous vous invitons à devenir membre de notre communauté, pour accéder à :

      informations à jour sur les sujets qui vous intéressent

    nos newsletters

  • contenu de leader d'opinion et accès à prix réduit à nos événements prisés, tels que Transformer 2021: En savoir plus
  • fonctionnalités de mise en réseau, et plus

  • Devenir membre