Le logiciel dirige le monde. Il permet aux avions de voler, aux hôpitaux de fonctionner et garantit que le système financier mondial ne manque jamais un rythme. Mais de plus en plus, ces applications sont construites à l’aide de composants de code open source provenant de diverses sources disparates. La complexité est la nouvelle norme, qu'il s'agisse de logiciels propriétaires ou d'applications maison sur mesure. Et la complexité est l’ennemie de la sécurité.
Les relations complexes entre les composants et la facilité avec laquelle les acteurs malveillants peuvent insérer des logiciels malveillants dans le code en amont devraient être une source de préoccupation pour les responsables de la sécurité. Les signaux d’alarme se sont multipliés ces dernières années. Il est temps de trouver un moyen efficace de gérer la chaîne d'approvisionnement des logiciels risque.
Comment fonctionne la chaîne d'approvisionnement logicielle
Les chaînes d'approvisionnement sont les voies critiques par lesquelles les matières premières et les composants sont acheminés avant d'être assemblés, vendus et utilisés. Dans le monde numérique, ces composants sont souvent mieux considérés comme des services fournis du fournisseur au client. Comme nous discuté dans un article précédent, ces fournisseurs de services constituent une cible d’attaque de plus en plus populaire, car les acteurs malveillants peuvent générer un bon retour sur investissement. Attaquez un sous-traitant de processus métier ou un géant des services informatiques, et ils auront la possibilité de voler des données et/ou d’extorquer un pool potentiellement important de clients en aval.
Une chaîne d'approvisionnement logicielle est similaire, mais dans ce cas, le système comprend les composants, les bibliothèques de codes, les outils et les processus nécessaires à la création de logiciels. En compromettant un seul composant, voire une application entière, les attaquants peuvent potentiellement avoir un impact sur tout développeur ou organisation utilisant ce logiciel/composant.
Où est le risque ?
Les logiciels dirigent peut-être le monde, mais que faut-il exactement faire pour créer les applications qui alimentent tout, des plates-formes de commerce électronique aux systèmes ERP critiques pour les entreprises ? Il s'agit de plus en plus de composants open source. UN Rapport Sonatype estime qu'au cours de la seule année 2022, les développeurs ont effectué 3.1 XNUMX milliards de demandes pour de tels composants à partir des quatre principaux écosystèmes open source : Java, JavaScript, Python et .NET. L'avantage est qu'en téléchargeant ces packages prédéfinis, les développeurs peuvent accélérer la mise sur le marché et aider l'entreprise à répondre plus rapidement à l'évolution rapide de la demande du marché. C'est revendiqué que 80 % du code des applications modernes provient de logiciels open source préexistants.
Le défi est que ces composants – ou « dépendances » open source – contiennent souvent des vulnérabilités. Selon Sonatype, 1.2 milliard de dépendances vulnérables ont été téléchargées chaque mois l'année dernière. S’ils sont téléchargés involontairement, ils pourraient présenter le risque d’être exploités ultérieurement par des acteurs malveillants. Selon le Linux Foundation, un projet de développement d'application moyen contient 49 vulnérabilités réparties dans 80 dépendances directes.
Pire encore, les dépendances indirectes ou transitives, qui, selon Sonatype, représentent six vulnérabilités sur sept dans les projets. Ces dépendances sont plus difficiles à suivre, car il s'agit en fait des bibliothèques et des packages que les dépendances directes appellent, en d'autres termes, les dépendances des dépendances. Par conséquent, il n’est pas immédiatement évident qu’une application particulière les utilise. Cela peut masquer les vulnérabilités sous une couche supplémentaire d’obscurcissement.
Un bon exemple est le tristement célèbre Vulnérabilités Log4j. Log4j est un outil de journalisation peu connu mais populaire utilisé par plus de 35,000 10.0 progiciels Java. Un correctif pour une vulnérabilité critique (CVSSS 2021) de l'outil a été publié fin décembre 4. Mais en raison de son utilisation généralisée dans l'écosystème open source Java, il était extrêmement difficile pour de nombreuses organisations de trouver et de corriger définitivement toutes les instances de LogXNUMXj. dans leur environnement. Selon Google, la plupart des packages Java concernés étaient vulnérables car Log4j était une dépendance transitive difficile à trouver.
"Plus la vulnérabilité est profonde dans une chaîne de dépendance, plus il faudra d'étapes pour la corriger", ajoute-t-il.
Malheureusement, les acteurs malveillants n’ont pas perdu de temps pour exploiter le bug. Selon Verizon, un tiers (32 %) des analyses de vulnérabilité dans les systèmes exposés l'année dernière ont eu lieu au cours des 30 premiers jours suivant sa publication.
Outre le défi de trouver et de corriger les vulnérabilités des composants open source, les organisations sont confrontées au problème supplémentaire des packages malveillants publiés dans des référentiels open source par les acteurs malveillants. Sonatype affirme avoir enregistré une augmentation annuelle de 633 % de ces forfaits en 2022, à plus de 88,000 XNUMX cas connus.
Une autre menace : les logiciels propriétaires
Cependant, les risques liés à la chaîne d’approvisionnement en logiciels ne se limitent pas à l’open source. Les produits commerciaux propriétaires peuvent contenir des vulnérabilités que les attaques pourraient exploiter et le sont régulièrement. Ils peuvent également inclure un buggy composants et outils open source, comme Log4j. En fait, très peu de codes existants aujourd’hui peuvent véritablement être décrits comme « propriétaires », selon Steve Poole, directeur de la défense des développeurs de Sonatype.
« En conséquence, les consommateurs d’applications apparemment propriétaires ont un faux sentiment de sécurité et peuvent donc être vulnérables sans le savoir », explique-t-il à ISMS.online.
Dans le cadre d'attaques plus sophistiquées, comme la campagne SolarWinds, les acteurs malveillants peuvent même compromettre l'environnement informatique du fournisseur et insérer des logiciels malveillants dans des mises à jour logicielles légitimes. Cela a permis aux agents de l’État russe de compromettre plusieurs départements du gouvernement américain.
« Tout type de logiciel peut être compromis. Le principal problème est une confiance implicite injustifiée dans ce logiciel », affirme Udo Schneider, évangéliste de la sécurité Europe chez Trend Micro.
Samuel Barfoot, chef d'équipe de sécurité chez Checkmarx, affirme que la maturité de l'éditeur de logiciels et l'accréditation ISO sont essentielles.
"Bien que le logiciel lui-même ne soit pas conçu pour causer des dommages, s'il est infiltré, il peut être utilisé pour divulguer des informations", a-t-il déclaré à ISMS.online. « Lorsqu'elles migrent vers le cloud, les organisations sont également confrontées à des risques liés aux contrôles des fournisseurs, au support, aux sauvegardes et à la disponibilité du système en cas de piratage ou de panne. La maturité du fournisseur est cruciale pour atténuer ces risques grâce à la préparation et aux provisions.
La visibilité est la première étape vers la gestion des risques
Qu'il s'agisse de code propriétaire ou open source, les organisations souhaitant atténuer les risques dans la chaîne d'approvisionnement logicielle doivent d'abord avoir un aperçu des « mauvais » composants et sous-composants, selon Schneider de Trend Micro. Ceci peut être réalisé en demandant une nomenclature logicielle (SBOM).
« Un SBOM pour un artefact logiciel (bibliothèque, exécutable ou même conteneur) contient un graphe de dépendances où sont répertoriés tous les (sous-)composants logiciels utilisés, y compris un numéro de version exact. Les SBOM peuvent être générés directement à partir de la source dans un Pipeline CI / CD ou plus tard sur des artefacts « morts » comme des exécutables ou même des conteneurs », explique-t-il.
« Ceci est particulièrement utile pour les logiciels propriétaires pour lesquels le fournisseur ne fournit généralement pas de SBOM. Dans les juridictions/secteurs verticaux où les fournisseurs doivent fournir un SBOM, ceux-ci peuvent être vérifiés en permanence par rapport aux vulnérabilités connues, fournissant ainsi une base à jour pour d'éventuelles actions.
Poole de Sonatype ajoute que les organisations devraient également évaluer la posture de sécurité des fournisseurs, en accordant une attention particulière à la qualité de leurs processus de reporting des vulnérabilités.
Pour les composants open source, les organisations devraient exécuter un programme d'évaluation continue des composants open source, en appliquant rapidement des correctifs/mises à jour si nécessaire pour éviter une exploitation rapide, affirme-t-il. Les outils d'analyse de la composition logicielle (SCA) peuvent également aider en découvrant le contenu des produits ou des composants.
« Cependant, la sophistication de l'outil SCA doit égaler et dépasser celle des mauvais acteurs, sinon l'organisation sera confrontée au risque réel d'une attaque via un vecteur non détecté », prévient-il.
« Enfin, impliquez les développeurs en leur expliquant comment se produisent les cyberattaques modernes et quels sont les principes de codage sécurisé, et apprenez-leur leurs responsabilités au début de la chaîne d'approvisionnement logicielle : leurs choix et actions immédiats ont des conséquences.
Commencez avec un SMSI
Schneider de Trend Micro affirme qu'un système de gestion de la sécurité de l'information (ISMS) peut être un excellent moyen d’atténuer les risques liés à la chaîne d’approvisionnement logicielle de manière continue.
« En introduisant les données des outils SBOM, enrichies de données de distribution, dans un SMSI, il est possible de mieux évaluer et documenter la posture de sécurité et donc le risque global de l'ensemble du système, dont le logiciel n'est qu'une partie », explique-t-il. "Lorsqu'il est utilisé comme base pour atténuer les risques et documenter les actions prises, cela offre en principe une bien meilleure sécurité que le suivi manuel des actifs logiciels."
Une liste de contrôle pour gérer les risques de la chaîne d’approvisionnement logicielle :
- Demander un SBOM
- Évaluer les fournisseurs de logiciels propriétaires (en particulier leurs rapports de vulnérabilité)
- Utilisez les outils SCA pour mieux comprendre les composants logiciels
- Recherchez en permanence les vulnérabilités et corrigez-les rapidement
- Sensibiliser les développeurs à l’importance de la sécurité dès la conception
- Envisagez d'introduire les données SBOM dans un SMSI pour une gestion globale des risques
Découvrez comment la solution ISMS.online permet une approche simple, sécurisée et durable de la gestion des risques de la chaîne d'approvisionnement et de la gestion de l'information avec la norme ISO 27001 et plus de 100 autres cadres mondiaux.
