Depuis les attaques réussies et très médiatisées contre des entreprises comme Solarwinds et Kaseya et des offres open source comme Log4j, les chaînes d'approvisionnement des logiciels sont devenues une cible de choix pour les cyberattaquants. En livrant « le premier produit de gestion de la surface d'attaque (ASM) », comme l’affirme Data Theorem, l’éditeur spécialisé dans la sécurité des applications logicielles veut résoudre le problème. Appelée Supply Chain Secure, la solution SaaS permet de lutter contre les menaces pouvant peser sur l'ensemble de la pile d'applications, depuis les API, les services cloud, les SDK, jusqu’aux logiciels open-source.

Selon Data Theorem, son offre est capable de contrer les menaces grâce à une analyse continue de l'exécution et à une découverte dynamique de l'inventaire, qui va au-delà de l'analyse statique traditionnelle du code source et de l'utilisation d'une nomenclature logicielle (Software Bill of Materials, SBOM). « Un marché de la gestion de la surface d'attaque (Attack Surface Management, ASM) commence à émerger parce que la manière de traiter avec les fournisseurs de logiciels, le contrôle des fournisseurs et du code source des tiers est insuffisante », a expliqué Doug Dooley, directeur des opérations de Data Theorem. « C’est ce qu’ont montré les problèmes à l’origine des attaques Solarwinds, Log4j et Spring4Shell », a-t-il ajouté. « Nous prenons en compte un élément qui, jusqu'à présent, n’était pas intégré à la gestion de la surface d'attaque », a encore déclaré Doug Dooley.

Découverte continue d'applications tierces et suivi des fournisseurs

Actuellement, pour lutter contre les menaces, la plupart des solutions de sécurité de la chaîne logistique logicielle s'appuient sur la gestion des fournisseurs ou l'analyse de la composition des logiciels. Cette approche souffre toutefois d’une lacune, car elle n'a souvent pas accès aux logiciels mobiles, du web, du cloud et métiers, pas plus qu’elle n’a accès aux API de tiers. Supply Chain Secure cherche à combler ce déficit en offrant une découverte continue des applications tierces et un suivi dynamique des fournisseurs tiers. Le produit peut automatiquement classer les actifs sous des fournisseurs connus, laisser les clients ajouter de nouveaux fournisseurs, classer les actifs individuels sous n'importe quel fournisseur, et alerter quand les violations de politiques et les taux élevés d'intégration de fournisseurs tiers dans des applications clés augmentent.

La solution améliore aussi la précision des nomenclatures logicielles SBOM utilisées pour identifier les composants tiers dans une application. C’est pourquoi elle ingère les nomenclatures logicielles fournies par les fournisseurs et les compare à un SBOM généré par Supply Chain Secure sur la base d'une analyse d'exécution d'une application. « En général, le SBOM du fournisseur est inexact ou l'a été à un moment donné, de sorte qu'il y a un écart entre la documentation du fournisseur et ce qui est réellement en production », a encore expliqué M. Dooley. « Les clients sont toujours choqués de voir à quel point leur documentation est différente de ce qu'un attaquant peut voir sur Internet », a-t-il ajouté.

Des perturbations durables

« Tout le monde utilise des logiciels tiers pour construire ses logiciels métiers. Par conséquent, les perturbations de la chaîne d'approvisionnement vont se poursuivre, et nous avons besoin d'une meilleure technologie pour y faire face. Il ne sera jamais possible d’y mettre fin », a encore expliqué le directeur des opérations de Data Theorem. « La question est de savoir combien de temps il faut pour s'apercevoir du problème et comment l'atténuer ». Selui lui, aucun fournisseur n'est actuellement en mesure de proposer une solution parfaite. « C’est la première fois cette année que l'industrie essaye vraiment d’apporter une réponse à ce problème de chaîne d'approvisionnement. Il faudra plusieurs fournisseurs et plusieurs clients intelligents pour résoudre ce problème dans les années à venir », a-t-il ajouté. « Les clients sont pris à la gorge : Ils se battent pour avoir des solutions parce qu'ils savent que la faille Log4j était vraiment très dommageable, mais malheureusement, cette situation va perdurer jusqu'à ce que l’on fasse des progrès en automatisation de la découverte de ces problèmes dans la chaîne d'approvisionnement logicielle ».