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