Non, un logiciel open source n'est pas forcément plus sécurisé

Publié le 03 juillet 2022 à 12h30

open source logiciel fotolia_cropped_2738x2739

On entend la phrase magique depuis un bon moment déjà : « un logiciel open source sera par définition plus sécurisé qu'un logiciel propriétaire ». Et si cette maxime pouvait se vérifier il y a une dizaine d'années, ce n'est malheureusement plus forcément le cas aujourd'hui.

Il y a encore quelques années, les logiciels libres (free software) ou open source présentaient bel et bien un avantage structurel en matière de sécurité informatique pour une raison simple : ils permettent la capacité de modifier le code afin de garantir la possibilité d'obtenir un correctif en cas d'exposition à une vulnérabilité dans sa sécurité. Cependant, en une dizaine d'années, la créativité des pirates et la prolifération des cibles potentielles ont modifié cet état de fait, et aujourd'hui, les logiciels open source ne bénéficient d'aucune garantie de sécurité.

La chaîne d'approvisionnement logicielle se fait de plus en plus complexe

Aujourd'hui, les composants et bibliothèques open source tiers sont présents dans l'immense majorité des programmes informatiques et des applications. Ils permettent notamment aux développeurs d'ajouter diverses fonctionnalités à ces logiciels. Cependant, il serait illusoire de considérer la pratique sans risque : en effet, Snyk et la Fondation Linux ont pu publier un rapport nommé The State of Open Source Security il y a quelques jours qui présente une dépendance et des vulnérabilités indéniables. Ce rapport, alimenté par une enquête auprès de plus de 550 développeurs et professionnels de la cybersécurité au premier trimestre 2022, permet ainsi de prendre la pleine mesure des failles liées à l'utilisation de l'open source.

Ainsi, un projet moyen de développement applicatif rencontre 49 vulnérabilités en moyenne, tandis que 80 dépendances directes à du code open source ont été relevées. D'autre part, 49 % des organisations interrogées dans le cadre de cette enquête affirment ne pas avoir de politique de sécurité open source. Le problème principal vient du fait que de nombreux développeurs logiciels assemblent du code ajoutant des composants open source déjà existants à leur code unique, ce qui crée à terme de nombreux problèmes de sécurité.

Sur le même sujet :

Qu'est-ce que Log4Shell, la vulnérabilité qui enflamme Internet ?

Des failles de plus en plus nombreuses, et de plus en plus difficiles à régler

La durée nécessaire pour corriger les failles dans le domaine open source a plus que doublé en l'espace de seulement trois ans. S'il fallait 49 jours en moyenne en 2018, il faut désormais compter sur 110 jours en 2021 pour corriger une faille liée au code open source. Par ailleurs, il est désormais beaucoup plus difficile de maintenir de la visibilité sur l'ensemble des composants open source qui forment un logiciel, et ces dépendances créent de véritables risques de sécurité qui se vérifient ces dernières années. Les principaux intéressés sont d'ailleurs plus de 25 % à indiquer être inquiets quant à l'impact de cette dépendance open source sur la sécurité de leur service.

Pour tenter d'endiguer le problème, qui grandit chaque jour, Snyk et la Fondation Linux recommandent ainsi aux entreprises de définir et de déployer une véritable politique de sécurité open source, mais aussi d'utiliser l'automatisation afin d'adapter la réponse aux potentielles attaques.

Sur le même sujet :
147,9 millions de dollars : le prix pour des logiciels open source sécurisés

Source : Snyk, Fondation Linux

Par Benoit Bayle

Geekonoclaste permanent, je m'intéresse autant aux jeux vidéo (avec une petite faiblesse particulière pour les JRPG) qu'à l'high-tech. Je cherche à la fois l'originalité et l'inventivité, que ce soit derrière une manette ou à l'écrit sur mon clavier

Articles de Benoit Bayle

Logiciels

Propriété intellectuelle

Actualités High-Tech

Vous êtes un utilisateur de Google Actualités ou de WhatsApp ?
Suivez-nous pour ne rien rater de l'actu tech !

Commentaires (0)

Rejoignez la communauté Clubic

Rejoignez la communauté des passionnés de nouvelles technologies. Venez partager votre passion et débattre de l’actualité avec nos membres qui s’entraident et partagent leur expertise quotidiennement.

Commentaires (10)

jvachez

C’est même tout le contraire, le code source aide grandement à détecter des failles de sécurité.

Et comme les gens trainent souvent à appliquer les mises à jour c’est encore plus simple.

dredd

Et donc à les colmater aussi. C’est plus complexe que ça quoi.

Sacré JVachez. Monsieur « il n’y a pas d’antivirus sur Linux donc vous êtes à la merci des virus »

Werehog

Il n’y a pas forcément du tout blanc ou du tout noir avec l’open source. La seule chose qui importe c’est la réactivité. Il y a de très mauvais projets open source et de très bons logiciels fermés. Il faut juste que les failles puissent être signalées facilement et corrigées rapidement.
Bon par contre le carnaval des dépendances parce que c’est gratuit donc on se sert sans compter, c’est effectivement un problème. C’est juste la conséquence logique de la médiocrité technique qui s’installe dans les entreprises. Les plus jeunes brassent à la pelle des techno qu’ils ne maîtrisent pas, ni même les grands principes de sécurité (entre autres) que cela implique…

wackyseb

Même pas besoin de reverse ingeniering avec l’open source. On a direct accès au code source pour trouver les failles et les exploiter.
Et en plus des tas de personnes ne mettent jamais à jour leurs logiciels.

Au moins en code fermé, c’est plus compliqué de trouver la faille.

Apres Il n’y a pas de solution miracle. Ce que l’homme fait, un autre homme saura le défaire.
Il faut juste un peu de patience.

stratos

je ne suis pas dev, mais la diversité des projets, il y a juste à voir la quantité de distrib linux n’aide pas forcément à maintenir tout ça a jour et colmater tout ca. Il y a un noyau commun entre différentes distrib mais le reste change.
le gros problème de l’open source que je vois de l’extérieur, c’est chacun son projet , il y a quelque gros projet open source type firefox,vlc., notepad… mais sinon c’est très diverse.
Et les soft open source, ok on a accès au code, mais vu le nombre de soft je ne pense pas qu’il y a toujours des dev ext au projet pour relire tout le code à chaque modification. Apres une journée de boulot, ils ont peut-être autre chose à faire.

MattS32

Il commence à y avoir des mesures pour ça, comme le SBOM. L’idée est de fournir avec tous les logiciels une liste précise de toutes les dépendances, pour pouvoir rapidement détecter ce qui est impacté par une faille. Ça commence à devenir obligatoire sur certains marchés, par exemple pour tous les logiciels utilisés par une agence du gouvernement fédéral américain.

Jissou06

Bon par contre le carnaval des dépendances parce que c’est gratuit donc on se sert sans compte

Tout à fait. Mais ce n"est pas spécifique à l’openSource
Nombre de projet d’ampleur ClosedSource utilisent des bibliothèques, dépendances OpenSource (nodeJs et autres) et ne sont pas sécurisés non plus.
Au moins le monde (fondation Linux…) ont le mérite de soulever le problème pour mieux y repondre

Francis7

« Use it at your own risk ! » and « Have a lot of fun! ». Your SuSE Team.
Cela ne m’a jamais causé de souci. Alors que des copains me voyaient comme un extra-terrestre dans les années 90.
En tant que particulier, ce sont des considérations qui nous dépassent.
J’ai toujours adoré Linux, hors formation initiale. Mais dans le milieu pro, ils doivent être vachement occupés.
Même Microsoft se fait pirater ses serveurs et stations de travail sous Linux.

benbart

{Un admin Système linux parle}

En effet, un code libre n’a jamais était plus sécurisé, c’est loin d’être nouveau.
Et ça na JAMAIS était le faire valoir du libre.

A la base le logiciel libre, ça na pas été fait pour la sécurité, mais tel qu’un projet de société !

Le paradigme qui se dégage d’un projet libre, c’est auditer, modifier, diffuser du code, la ou un logiciel aux sources fermé ça l’interdit …

C’est dans ce sens qu’il faut le lire … donc c’est extrêmement biaisé de se croire protéger quand on utilise un outils libre…

Par ailleurs, des failles dans des logiciels proprio’ c’est très souvent opaque au niveau de la transparence et de la résolution des problème, et bien souvent ça enlève beaucoup de moyens à un SI de contourner un problème ou une faille.

Au taff, on traite de plus en plus de CVE, et la le logiciel libre est intéressent, c’est qu’on peux directement savoir s’il ont est sujet aux CVE en question, et il y a très souvent des correctifs qui viennent rapidement, et on peux payer un service de maintient du le logiciel libre, parce qu’un logiciel libre n’est pas toujours 100% gratuit et philanthropique, voire bénévole. (Red Hat, Oracle, blah blah blah)

Par contre, jean-kevin qui git clone tout les trois jour un projet libre bling-bling plus maintenu après les trois semaines de hype, la en effet il y a un soucis de sécurité …

Donc, non le libre ne favorise pas la sécurité, mais ça viens avec des outils d’audit et une lecture sceptique sur le code libre, la ou un projet propriétaire t’enlève tout outils d’audit et autres ou patchage ou modification du programme.

Petite subtilité, Quant on parle de CVE, c’est qu’elles sont publié, et souvent ça viens par vague sur une techno’ en particulier, et souvent à la suite de l’audit dans une boite ou autres. ( CF. log4j et plus largement Java il y a quelques mois ).

Dernière petite chose et non des moindre, histoire d’abolir le chiisme entre proprio’ et libristes, c’est la qualité du code qui fait le développeur, c’est pas ses outils ! il en va de même pour l’administrateur système.

( ps : les problèmes de distribution de packages/logiciels corrompu ( NPM/PHP par exemple ) sont pas lier aux sources ouverte/fermé, mais c’est un soucis générale, lier à tous les environnements )

A mon humble avis :
Ils y a maintenant des galaxies de projets libre, et les temps d’audit on drastiquement diminué, car ça na pas de taux horaire favorable à un employeur. Il y a déjà un soucis sur ce point.

C’est le farewest dans le libre, parce que c’est libre, je vois de plus en plus de développeurs qui utilisent des outils sans les comprendre dans leur ensemble, de même pour les administrateurs, je m’inclue dedans car, j’ai pas encore suffisamment d’expérience sur tel ou tel framework, je me suis donc orienté vers outils avec le minimum de middleware, un enfer à géré sur Foreman/Satellite/Katello pour l’exemple.

Il serait intéressant de :

Factoriser au max les outils, évitant les dépendances « contrib » de faible confiance.
Conventionner(ou normer) les interactions entre les outils.
Afficher clairement les dépendances dans les README, en 2022 ça n’est toujours pas le cas, je suis toujours obliger de vérifier la qualité du maintient d’un outils à chaque fois … c’est fatigant, et par moment je le fait même plus quand il est 15h59 un vendredi…
Vérifier les taux de tickets et merge resquest appliqué, ça justifie de la qualité du maintient d’un outils en quantité au minimum.
LIRE, LIRE et encore RTFM !!!

benbart

L’offuscation ça na jamais marché !

La preuve il y toujours autant de logiciels pirates