Les 10 principaux risques liés aux logiciels open source

Dans le cadre d'une initiative visant à mieux informer les équipes de cybersécurité sur les problèmes pouvant compromettre les chaînes logistiques logicielles, Endor Labs, fournisseur de plateformes de gestion des logiciels open source, a publié un rapport identifiant les 10 principaux risques liés aux logiciels open source pour 2023. L'objectif principal est de sensibiliser davantage aux problèmes de sécurité des applications qui découlent de la manière dont les logiciels open source sont développés. Les risques répertoriés sont les suivants :

Vulnérabilités connues : une version d'un composant logiciel peut contenir un code vulnérable introduit accidentellement par ses développeurs.  Lorsque les détails d'une vulnérabilité sont rendus publics, il n'existe pas toujours de correctif immédiatement disponible.

Logiciel non géré : un composant logiciel peut ne plus être développé activement. Les correctifs pour les bugs fonctionnels et non fonctionnels ne sont alors pas fournis en temps utile ou pas fournis du tout.

Attaques par confusion de nom : les pirates peuvent créer des composants dont le nom ressemble aux noms de composants système ou open source légitimes, une technique également appelée « typo-squatting ». Ils peuvent également tenter d'imiter des auteurs de confiance (détournement de marque ou brand-jacking) ou jouer avec des modèles de dénomination courants dans différentes langues ou écosystèmes (combo-squatting).

Compromission du package légitime : les pirates peuvent compromettre les ressources faisant partie d'un projet légitime existant ou d'une infrastructure de distribution associée pour injecter du code malveillant dans des composants logiciels.

Logiciel obsolète : un projet peut utiliser une ancienne version obsolète d'un composant logiciel, même si une version plus récente et plus sécurisée existe.

Dépendances non suivies : les développeurs peuvent ne pas être conscients d'une dépendance à un composant qui fait partie d'un autre module en amont qu'ils ont utilisé.

Risques de licence : un composant logiciel ou un projet peut ne pas avoir de licence du tout, ou comporter une licence incompatible avec l'utilisation prévue ou dont les exigences ne sont pas ou ne peuvent pas être satisfaites.

Logiciel immature : un projet open source peut ne pas appliquer les bonnes pratiques de développement, par exemple, être dépourvu d'un schéma standard de gestion des versions, d'une suite de tests de régression, de directives d'examen ou de documentation.

Modifications non approuvées : un composant logiciel peut être modifié sans que les développeurs puissent remarquer, examiner ou approuver ces modifications, car le lien de téléchargement pointe vers une ressource non gérée, une ressource gérée mais modifiée de manière malveillante, ou en raison d'un transfert de données non sécurisé.

Origine inconnue : les détails concernant le code source, le processus de création ou le processus de distribution d'un composant logiciel peuvent être inconnus ou non vérifiables.

Alors que les entreprises accélèrent leurs efforts de sécurisation des chaînes logistiques logicielles après une série de violations très médiatisées, elles ont besoin d'une meilleure visibilité sur les risques opérationnels potentiels liés à une dépendance accrue aux logiciels open source. Il ne s'agit pas d'utiliser moins de logiciels open source, mais de prévenir les risques de cybersécurité liés que de nombreux développeurs n’apprécient pas toujours. Une analyse récente d'Endor Labs portant sur près de 2 000 progiciels a ainsi révélé que 95 % de toutes les vulnérabilités des applications sont imputables à une dépendance transitive créée lorsqu’un développeur utilise un composant open source.

Quelle que soit la cause profonde des risques de cybersécurité, il incombe aux équipes en charge de les atténuer. Le problème réside dans le fossé historique qui existe entre les équipes de cybersécurité et les développeurs d'applications, d'où le défi majeur que représente l'évaluation de ces risques. De fait, il n'est pas possible pour les équipes de cybersécurité de réaliser une évaluation sans savoir au préalable sur quoi elles doivent se concentrer.