Depuis les attaques réussies et très médiatisées contre des entreprises comme Solarwinds et Kaseya et des composants open source comme Log4j, la problématique la supply chain des logiciels est devenue importante. En livrant « son premier produit de gestion de la surface d'attaque (ASM) », Data Theorem, l’éditeur spécialisé dans la sécurité des applications veut résoudre ce point de tension. 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, le service 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). « Le marché de la gestion de la surface d'attaque (Attack Surface Management, ASM) commence à émerger parce que la manière de traiter avec les éditeurs et de contrôler le 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 éditeurs

Actuellement, pour lutter contre les menaces, la plupart des solutions de sécurité de la supply chain logicielle s'appuient sur la gestion des éditeurs 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 éditeurs 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 peut également améliorer 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 éditeurs 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 applications métiers », a encore expliqué le directeur des opérations de Data Theorem. « 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-t-il poursuivi. « La question est de savoir combien de temps il faut pour s'apercevoir du problème et comment l'atténuer », a-t-il encore déclaré. « Actuellement, aucun fournisseur n'est en mesure de proposer une solution parfaite », a reconnu M. Dooley.

« C’est la première fois cette année que l'industrie essaye vraiment d’apporter une réponse à ce problème de supply chain. 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 », a-t-il encore déclaré.