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

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.

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 »

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…

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.

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.

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.

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

« 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.

{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 !!!

L’offuscation ça na jamais marché !

La preuve il y toujours autant de logiciels pirates