Cela fait plus de trois ans que Log4Shell, une vulnérabilité critique dans une bibliothèque open source peu connue, a été découverte. Avec un score CVSS de 10, sa relative omniprésence et sa facilité d'exploitation en ont fait l'une des failles logicielles les plus graves de la décennie. Mais même des années après sa correction, plus d'un téléchargement sur dix de cet utilitaire populaire concerne des versions vulnérables. Il y a clairement quelque chose qui cloche quelque part.
Un nouveau rapport du Linux Foundation fournit des informations utiles sur les défis systémiques auxquels sont confrontés l'écosystème open source et ses utilisateurs. Malheureusement, il n'existe pas de solutions simples, mais les utilisateurs finaux peuvent au moins atténuer certains des risques les plus courants grâce aux meilleures pratiques du secteur.
Une étude de cas catastrophique
Les composants logiciels open source sont partout : même les développeurs de code propriétaire s'appuient sur eux pour accélérer les processus DevOps. une estimation96 % de toutes les bases de code contiennent des composants open source et les trois quarts contiennent des vulnérabilités open source à haut risque. Étant donné que l'approche sept mille milliards des composants ont été téléchargés en 2024, ce qui présente un risque potentiel énorme pour les systèmes du monde entier.
Log4j est une excellente étude de cas sur ce qui peut mal se passer. Il met en évidence un défi majeur en matière de visibilité dans la mesure où les logiciels ne contiennent pas seulement des « dépendances directes » – c'est-à-dire des composants open source auxquels un programme fait explicitement référence – mais aussi des dépendances transitives. Ces dernières ne sont pas importées directement dans un projet mais sont utilisées indirectement par un composant logiciel. En fait, ce sont des dépendances de dépendances directes. Google a expliqué à l'époque, c'était la raison pour laquelle tant d'instances Log4j n'étaient pas découvertes.
« Plus la vulnérabilité est profonde dans une chaîne de dépendance, plus il faut d’étapes pour la corriger », a-t-il noté.
Brian Fox, directeur technique de Sonatype, explique que la « mauvaise gestion des dépendances » dans les entreprises est une source majeure de risque de cybersécurité open source.
« Log4j est un bon exemple. Nous avons constaté que 13 % des téléchargements de Log4j concernaient des versions vulnérables, et ce, trois ans après la mise à jour de Log4Shell », explique-t-il à ISMS.online. « Ce problème n’est pas propre à Log4j non plus : nous avons calculé qu’au cours de l’année dernière, 95 % des composants vulnérables téléchargés avaient déjà une version corrigée. »
Toutefois, les risques liés à l'open source ne se limitent pas aux vulnérabilités potentielles apparaissant dans des composants difficiles à trouver. Les acteurs malveillants implantent également activement des logiciels malveillants dans certains composants open source, dans l'espoir qu'ils seront téléchargés. Sonatype a découvert 512,847 2024 packages malveillants dans les principaux écosystèmes open source en 156, soit une augmentation annuelle de XNUMX %.
Défis systémiques
Log4j n'était que la pointe de l'iceberg à bien des égards, comme le révèle un nouveau rapport sur Linux. Il met en évidence plusieurs défis majeurs à l'échelle de l'industrie liés aux projets open source :
Technologie héritée : De nombreux développeurs continuent de s'appuyer sur Python 2, même si Python 3 a été introduit en 2008. Cela crée des problèmes d'incompatibilité avec les versions antérieures et des logiciels pour lesquels les correctifs ne sont plus disponibles. Les anciennes versions de logiciels persistent également dans les écosystèmes, car leurs remplaçants contiennent souvent de nouvelles fonctionnalités, ce qui les rend moins attrayants pour les utilisateurs.
Un manque de schéma de dénomination standardisé : Les conventions de dénomination des composants logiciels sont « uniques, individualisées et incohérentes », ce qui limite les initiatives visant à améliorer la sécurité et la transparence.
Un bassin limité de contributeurs :
« Certains projets OSS largement utilisés sont gérés par une seule personne. En examinant les 50 principaux projets non-npm, 17 % des projets avaient un développeur et 40 % avaient un ou deux développeurs qui représentaient au moins 80 % des commits », explique David Wheeler, directeur de la sécurité de la chaîne d'approvisionnement open source d'OpenSSF, à ISMS.online.
« Un projet avec un seul développeur présente un risque plus élevé d’abandon ultérieur. De plus, il présente un risque plus élevé de négligence ou d’insertion de code malveillant, car il peut manquer de mises à jour régulières ou de révisions par les pairs. »
Bibliothèques spécifiques au cloud : Cela pourrait créer des dépendances vis-à-vis des fournisseurs de cloud, d’éventuels angles morts en matière de sécurité et un verrouillage des fournisseurs.
« Le principal enseignement à tirer est que l’open source continue de prendre de l’importance pour les logiciels qui alimentent l’infrastructure cloud », explique Fox de Sonatype. « L’utilisation de l’open source a connu une croissance en forme de crosse de hockey, et cette tendance ne fera que se poursuivre. Dans le même temps, nous n’avons pas constaté que le soutien, financier ou autre, aux mainteneurs de l’open source augmentait au même rythme que cette consommation. »
Langages non sécurisés en mémoire:L'adoption du langage Rust, qui protège la mémoire, augmente, mais de nombreux développeurs privilégient toujours C et C++, qui contiennent souvent des vulnérabilités en matière de sécurité de la mémoire.
Comment ISO 27001 peut vous aider
As Notes d'Hervé Béraud, contributeur de Red Hat, nous aurions dû voir Log4Shell arriver car l'utilitaire lui-même (Log4j) n'avait pas subi d'audits de sécurité réguliers et n'était maintenu que par une petite équipe de bénévoles, un risque souligné ci-dessus. Il soutient que les développeurs doivent réfléchir plus attentivement aux composants open source qu'ils utilisent en posant des questions sur le retour sur investissement, les coûts de maintenance, la conformité légale, la compatibilité, l'adaptabilité et, bien sûr, s'ils sont régulièrement testés pour détecter les vulnérabilités.
Les experts recommandent également des outils d’analyse de la composition logicielle (SCA) pour améliorer la visibilité sur les composants open source. Ces outils aident les organisations à maintenir un programme d’évaluation et de correctifs continus. Mieux encore, envisagez une approche plus globale qui couvre également la gestion des risques dans les logiciels propriétaires. La norme ISO 27001 fournit un cadre structuré pour aider les organisations à améliorer leur posture de sécurité open source.
Cela comprend de l’aide pour :
- Évaluations et atténuations des risques pour les logiciels open source, y compris les vulnérabilités ou le manque de support
- Maintenir un inventaire des logiciels open source pour garantir que tous les composants sont à jour et sécurisés
- Contrôles d'accès pour que seuls les membres autorisés de l'équipe puissent utiliser ou modifier des logiciels open source
- Politiques et procédures de sécurité sur l'utilisation, la surveillance et la mise à jour des composants
- Gestion des relations avec les fournisseurs pour garantir que les fournisseurs de logiciels open source adhèrent aux normes et pratiques de sécurité
- Gestion continue des correctifs pour remédier aux vulnérabilités de sécurité des logiciels open source
- Processus de gestion des incidents, y compris la détection et la réponse aux vulnérabilités ou aux violations provenant de l'open source
- Promotion d'une culture d'amélioration continue pour renforcer l'efficacité des contrôles de sécurité
- Formation et sensibilisation des collaborateurs pour comprendre les risques liés aux logiciels open source
Il y a encore beaucoup à faire, notamment des programmes gouvernementaux de chasse aux bugs, des efforts de sensibilisation et des financements communautaires de la part des géants de la technologie et d'autres grandes entreprises utilisatrices de logiciels open source. Ce problème ne sera pas résolu du jour au lendemain, mais au moins les choses ont commencé à tourner.
