Les dépendances open source sont devenues une source croissante de risques pour les organisations de toutes formes et de toutes tailles. log4j, xz Utilitaires et d’autres histoires très médiatisées ont mis en évidence des faiblesses systématiques dans l’écosystème, que les acteurs malveillants sont de plus en plus capables d’exploiter. Mais peu de gens pensaient qu’Apple serait un jour touché. Après tout, c’est le fournisseur qui examine minutieusement toutes les applications autorisées sur son App Store. Du moins, c’était le cas jusqu’au 1er juillet, lorsque Les chercheurs en sécurité ont abandonné une autre bombe open source : de nouvelles vulnérabilités critiques dans un gestionnaire de dépendances populaire utilisé dans plus de trois millions d'applications macOS et iOS.

Les bugs ont été corrigés, mais personne ne sait s'ils ont déjà été exploités dans des attaques secrètes contre la chaîne d'approvisionnement. Cela soulève une question de plus en plus courante : comment résoudre un problème comme celui de l'open source ?

Qu'est-il arrivé?

Les vulnérabilités ont été découvertes dans CocoaPods, un référentiel pour les projets Swift et Objective-C open source dont dépendent des millions d'applications Apple. Il contient plus de 100,000 XNUMX bibliothèques externes (ou « pods »), utilisées par certaines des applications les plus populaires au monde, notamment Airbnb, Instagram et Uber. Selon EVA Information Security, les vulnérabilités sont les suivantes :

CVE-2024-38368 : Un défaut de conception dans le serveur CocoaPods permet à n'importe quel utilisateur de revendiquer un pod qui n'a pas de propriétaire identifié sans aucune vérification nécessaire. Il existe aujourd'hui des milliers de ces pods sans propriétaire. Selon Endor Labs, cela signifie qu'un acteur malveillant aurait pu enregistrer un compte CocoaPods, revendiquer un pod et commencer à distribuer des logiciels malveillants comme s'il était un mainteneur de confiance. Le score CVSS est de 9.3.

CVE-2024-38367:Le serveur CocoaPods fait confiance à un en-tête de requête auquel il ne devrait pas faire confiance, ce qui permet à un attaquant de contourner le flux de validation des e-mails pour empêcher les prises de contrôle de compte. Cela aurait pu conduire des acteurs malveillants à détourner des comptes d'utilisateurs existants et à remplacer les pods associés par des versions malveillantes ou compromises. Son score CVSS est de 8.2.

CVE-2024-38366 : Cette vulnérabilité est due à une vulnérabilité dans un gem Ruby appelé « rfc-822 », une bibliothèque open source sur laquelle le logiciel serveur CocoaPods s'appuie pour valider les adresses e-mail. Les acteurs malveillants auraient pu l'exploiter pour exécuter du code à distance sur le serveur Trunk. Son score CVSS est de 10.0.

What Happens Next?

La bonne nouvelle est que les bugs ont été corrigés en octobre dernier. Mais des interrogations subsistent quant à savoir s'ils ont pu être exploités au cours de la dernière décennie, compte tenu du nombre de pods exposés et de la durée de leur exposition (plus de 10 ans). Si tel avait été le cas, la complexité de la chaîne d'approvisionnement en logiciels aurait fourni aux acteurs de la menace une couverture suffisante.

« Bien qu’il n’existe aucune preuve directe de l’exploitation de l’une de ces vulnérabilités dans la nature, la preuve de l’absence n’est pas une absence de preuve », prévient EVA.

C'est pourquoi le fournisseur recommande à tous les développeurs concernés (ceux qui utilisent CocoaPods avant octobre 2023) de sécuriser leur code en suivant les étapes suivantes :

  • Gardez les fichiers « podfile.lock » synchronisés avec tous les développeurs CocoaPods afin que tout le monde utilise la même version des packages. Cela signifie que si une nouvelle mise à jour nuisible est effectuée, les développeurs ne la mettront pas automatiquement à jour.
  • Pour les pods développés en interne et hébergés uniquement dans CocoaPods pour la distribution, les développeurs doivent effectuer une validation CRC (somme de contrôle) par rapport à celui téléchargé à partir du serveur de jonction CocoaPods pour garantir qu'il est identique à celui développé en interne.
  • Mettre en œuvre un examen de sécurité approfondi de tout code tiers utilisé dans les applications
  • Vérifiez les dépendances de CocoaPods et vérifiez que vous n’utilisez pas un pod orphelin.
  • Utilisez uniquement des dépendances tierces qui sont activement maintenues et dont la propriété est claire.
  • Effectuez des analyses périodiques du code de sécurité pour détecter les secrets et les codes malveillants sur toutes les bibliothèques externes, en particulier CocoaPods.

The Bigger Picture

Les développeurs continuent de s'appuyer sur des composants open source car ils constituent un moyen rapide, économique et simple de réduire les délais de développement. Mais les risques deviennent trop importants pour être ignorés. Selon ISMS.online Rapport sur l’état de la sécurité de l’information 2024, les trois quarts (75 %) des organisations ont été touchées par un incident de sécurité causé par un fournisseur tiers. Et près de la moitié (45 %) ont subi plusieurs incidents au cours de l'année écoulée.

« Les logiciels open source, étant accessibles au public, peuvent contenir des vulnérabilités non découvertes ou non corrigées que des acteurs malveillants pourraient exploiter. Cette situation est aggravée par le manque de support dédié dans de nombreux projets open source, ce qui rend difficile l'obtention d'une assistance ou de mises à jour en temps opportun lorsque des problèmes surviennent », explique Rich Hildyard, responsable des produits logiciels et de la distribution chez MOBSTR, spécialiste de la sécurité mobile.

« Un autre risque important est lié aux licences. Le non-respect des licences open source peut entraîner des complications juridiques, en particulier lorsque les licences comportent des exigences spécifiques à respecter. »

Hildyard met également en garde contre les projets qui pourraient être abandonnés par leurs responsables.

« Lorsque cela se produit, les utilisateurs se retrouvent sans mises à jour ou correctifs essentiels, ce qui peut mettre en péril la stabilité et la sécurité de leurs systèmes », explique-t-il à ISMS.online. « Les problèmes de compatibilité constituent également une menace, car les mises à jour des dépendances open source peuvent parfois introduire des modifications ou des conflits avec d’autres composants logiciels, perturbant ainsi la fonctionnalité globale. »

Boris Cipot, ingénieur en sécurité senior chez Synopsys Software Integrity Group, explique que la complexité et le volume considérable des dépendances directes et transitives compliquent la tâche des RSSI qui doivent gérer et suivre les vulnérabilités qui ont un impact sur plusieurs projets. Même s'ils y parviennent, la mise à jour des correctifs peut être retardée en raison de problèmes de compatibilité et/ou d'exigences de test, explique-t-il à ISMS.online.

Atténuer les risques liés à l'open source grâce à la norme ISO 27001

Il est toutefois possible d'atténuer le risque d'un autre Log4Shell ou CocoaPods. Il soutient qu'une surveillance continue des composants open source, notamment par des outils d'analyse de la composition logicielle (SCA), pour identifier et gérer automatiquement les composants open source et leurs dépendances, sera utile. Cipot recommande également aux équipes de sécurité de suivre la norme ISO 27001.

« La norme ISO/IEC 27001 est une norme internationale relative aux systèmes de gestion de la sécurité de l’information (SMSI) qui propose une approche systématique de la gestion des informations sensibles de l’entreprise et de la garantie de leur sécurité », explique-t-il. « Cette norme peut également aider les organisations à atténuer les risques associés à l’utilisation de logiciels open source en créant un cadre structuré qui aborde divers risques, améliorant ainsi la sécurité globale de l’information. »

Il apporte une valeur particulière avec :

  • Évaluation et traitement des risques : y compris l'évaluation des risques liés à l'utilisation de logiciels open source, tels que les vulnérabilités, le manque de support ou les problèmes de licence, et la mise en œuvre de mesures pour atténuer ces risques
  • Gestion des actifs : la tenue d'un inventaire des actifs informationnels, y compris les logiciels open source, permet d'identifier et de gérer les aspects de sécurité du logiciel, en garantissant que tous les composants sont à jour et sécurisés
  • Contrôle d'accès : pour garantir que seul le personnel autorisé peut utiliser ou modifier des logiciels open source, empêchant ainsi les modifications non autorisées qui pourraient introduire des vulnérabilités
  • Politiques et procédures de sécurité : elles peuvent inclure des directives pour l'utilisation, la surveillance et la mise à jour des logiciels open source
  • Relations avec les fournisseurs : s'assurer que les fournisseurs de logiciels open source tiers adhèrent aux normes et pratiques de sécurité conformes à celles de l'organisation
  • Gestion des correctifs : pour garantir que toutes les vulnérabilités de sécurité dans les logiciels open source soient rapidement identifiées et traitées
  • Gestion des incidents : processus défini pour gérer les incidents de sécurité, notamment la détection et la réponse aux vulnérabilités ou aux violations associées aux logiciels open source, la minimisation des dommages et la récupération rapide
  • Conformité aux exigences légales : la norme aide les organisations à se conformer aux exigences légales, réglementaires et contractuelles, notamment en adhérant aux licences open source et en garantissant que l'utilisation de logiciels open source ne viole pas les lois sur la propriété intellectuelle
  • Amélioration continue : Promouvoir une culture d'amélioration continue, où l'efficacité des contrôles de sécurité, y compris ceux liés aux logiciels open source, est régulièrement revue et améliorée
  • Formation et sensibilisation : Pour garantir que les employés comprennent les risques associés aux logiciels open source et les mesures mises en place pour atténuer ces risques

Aujourd’hui, l’open source est partout, ce qui fait des améliorations de sécurité une responsabilité partagée entre tous les utilisateurs, mainteneurs, contributeurs et bailleurs de fonds.

« Les RSSI doivent favoriser les relations au sein de la communauté et participer aux efforts collaboratifs visant à améliorer les pratiques de sécurité dans toute la chaîne d’approvisionnement », conclut Cipot. En attendant, un changement de culture peut être nécessaire dans de nombreuses organisations utilisatrices. Les risques liés à l’open source ne sont pas les mêmes que ceux découlant du code propriétaire. Plus tôt les RSSI accepteront et apprendront à gérer ce fait, mieux ce sera.