La tentation de se décharger sur le libre
Amazon a demandé aux développeurs pourquoi ils faisaient appel à des bibliothèques libres. La première raison invoquée a été la sécurité, pour 70% des réponses.
On en comprend aisément la logique : le développement sécurisé, ce n’est pas évident et ce n’est une priorité de personne. Si quelqu’un d’autre pouvait s’en charger, ce serait quand même mieux.
Adopter des bibliothèques commerciales, c’est tentant, mais c’est cher, et on risque d’être coincé avec un fournisseur.
Le candidat idéal, c’est le logiciel libre. L’ouverture du code est censée améliorer la sécurité, par application de la loi de Linus qui dit que « given enough eyeballs, all bugs are shallow ».
En intégrant une bibliothèque libre, le développeur prend une assurance de sécurité à moindre frais, en faisant confiance à tous ces gens qui scrutent le code à longueur de journée, qui détectent les problèmes et qui les corrigent.
Qui lit le code open source ?
Le raisonnement ne tient cependant que si le code est réellement lu, et si les problèmes sont réellement remontés et s’ils sont bien corrigés.
On peut d’ailleurs se demander qui fait ce travail ingrat. Ce n’est pas moi en tout cas. Il m’arrive fréquemment de consulter du code source, soit pour savoir si ce que je souhaite faire avec le logiciel est possible, soit pour comprendre pourquoi ce que je configure ne fonctionne pas.
La plupart du temps, le code n’est pas documenté, ou alors très parcellairement. Il est aussi mal écrit, mais c’est le propre du code source. Quand je relis ce que j’ai codé moi-même il n’y a pas trois mois, je me demande quel idiot a pu faire les choses si salement.
Donc non, c’est rarement un plaisir de relire du code. Il y a des moments de grâce où on s’émerveille devant l’élégance des algorithmes, mais c’est tellement rare que quand cela arrive, on a les larmes qui montent aux yeux.
La réalité, c’est que le code n’est pratiquement pas lu. Il l’est par nécessité et dans ce cas, on remonte les bugs les plus flagrants (et ceux qui nous impactent). Personne ne fait de revue de code avec production d’un commentaire argumenté.
Cette histoire d’eyeballs, c’est du marketing intelligent, mais dans la vraie vie, ça n’existe pas.
Malgré tout, les développeurs libres doivent bien produire du code sécurisé
Personne ne relit le code, et surtout pas à la recherche de vulnérabilités, mais on doit bien pouvoir faire confiance aux développeurs des bibliothèques libres pour faire du travail sérieux et sécurisé. C’est pour ça qu’on les paye, non ?
Ah non, c’est vrai, on ne paye pas leur production, et seuls la moitié d’entre eux sont rémunérés par des sociétés comme Redhat, Microsoft ou Google.
Alors justement, s’ils travaillent pour la gloire, c’est que ce sont des passionnés qui ont à cœur de faire du code parfait, exempt de bugs et de vulnérabilités.
Une récente étude de la fondation Linux nous dit que non. Les développements du libre déclarent ne passer que 2,27% de leur temps sur des questions de sécurité. Ils affirment leur désintérêt par des remarques sur le thème : « la sécurité c’est une corvée pour moi qui consacre mon temps à développer de si belles applications ».
D’ailleurs si on leur demande la part idéale de leur temps qu’ils sont prêts à passer à sécuriser leur code, ils arrivent quand même au chiffre bien supérieur de 2,33%. C’est-à-dire : la même chose.
(certains d’entre vous se demandent si le second chiffre après la virgule de 2,27% et 2,33% est important. La réponse est oui, évidemment oui, et il est même crucial).
Se mettre en capacité de patcher vite
Le verdict est tombé : s’appuyer sur une bibliothèque libre en pensant adresser toutes les problématiques de sécurité est une illusion.
Mais cela n’invalide évidemment pas de recours à de telle bibliothèques, qui conservent leurs avantages en termes de gain de temps, de qualité, d’actualité, de coût, etc.
Il faut cependant être conscient que dès qu’une vulnérabilité est décelée, des attaquants lancent des opérations à grande échelle pour tenter de l’exploiter.
Cela implique plusieurs choses :
• se donner les moyens d’être informé très rapidement de la découverte de la vulnérabilité
• pouvoir empêcher son exploitation, par exemple en agissant au niveau du parefeu applicatif (WAF) ou en désactivant des fonctionnalités
• être capable de mettre à jour la bibliothèque incriminée dès la disponibilité du correctif
Moyennant ces actions, le niveau de sécurité est maintenu.
Et n’oubliez pas pendant votre temps libre de regarder le code source des bibliothèques que vous utilisez à la recherche de vulnérabilités !
Auteur : Marc (Directeur technique)
Related Posts
La tentation de se décharger sur le libre
Amazon a demandé aux développeurs pourquoi ils faisaient appel à des bibliothèques libres. La première raison invoquée a été la sécurité, pour 70% des réponses.
On en comprend aisément la logique : le développement sécurisé, ce n’est pas évident et ce n’est une priorité de personne. Si quelqu’un d’autre pouvait s’en charger, ce serait quand même mieux.
Adopter des bibliothèques commerciales, c’est tentant, mais c’est cher, et on risque d’être coincé avec un fournisseur.
Le candidat idéal, c’est le logiciel libre. L’ouverture du code est censée améliorer la sécurité, par application de la loi de Linus qui dit que « given enough eyeballs, all bugs are shallow ».
En intégrant une bibliothèque libre, le développeur prend une assurance de sécurité à moindre frais, en faisant confiance à tous ces gens qui scrutent le code à longueur de journée, qui détectent les problèmes et qui les corrigent.
Qui lit le code open source ?
Le raisonnement ne tient cependant que si le code est réellement lu, et si les problèmes sont réellement remontés et s’ils sont bien corrigés.
On peut d’ailleurs se demander qui fait ce travail ingrat. Ce n’est pas moi en tout cas. Il m’arrive fréquemment de consulter du code source, soit pour savoir si ce que je souhaite faire avec le logiciel est possible, soit pour comprendre pourquoi ce que je configure ne fonctionne pas.
La plupart du temps, le code n’est pas documenté, ou alors très parcellairement. Il est aussi mal écrit, mais c’est le propre du code source. Quand je relis ce que j’ai codé moi-même il n’y a pas trois mois, je me demande quel idiot a pu faire les choses si salement.
Donc non, c’est rarement un plaisir de relire du code. Il y a des moments de grâce où on s’émerveille devant l’élégance des algorithmes, mais c’est tellement rare que quand cela arrive, on a les larmes qui montent aux yeux.
La réalité, c’est que le code n’est pratiquement pas lu. Il l’est par nécessité et dans ce cas, on remonte les bugs les plus flagrants (et ceux qui nous impactent). Personne ne fait de revue de code avec production d’un commentaire argumenté.
Cette histoire d’eyeballs, c’est du marketing intelligent, mais dans la vraie vie, ça n’existe pas.
Malgré tout, les développeurs libres doivent bien produire du code sécurisé
Personne ne relit le code, et surtout pas à la recherche de vulnérabilités, mais on doit bien pouvoir faire confiance aux développeurs des bibliothèques libres pour faire du travail sérieux et sécurisé. C’est pour ça qu’on les paye, non ?
Ah non, c’est vrai, on ne paye pas leur production, et seuls la moitié d’entre eux sont rémunérés par des sociétés comme Redhat, Microsoft ou Google.
Alors justement, s’ils travaillent pour la gloire, c’est que ce sont des passionnés qui ont à cœur de faire du code parfait, exempt de bugs et de vulnérabilités.
Une récente étude de la fondation Linux nous dit que non. Les développements du libre déclarent ne passer que 2,27% de leur temps sur des questions de sécurité. Ils affirment leur désintérêt par des remarques sur le thème : « la sécurité c’est une corvée pour moi qui consacre mon temps à développer de si belles applications ».
D’ailleurs si on leur demande la part idéale de leur temps qu’ils sont prêts à passer à sécuriser leur code, ils arrivent quand même au chiffre bien supérieur de 2,33%. C’est-à-dire : la même chose.
(certains d’entre vous se demandent si le second chiffre après la virgule de 2,27% et 2,33% est important. La réponse est oui, évidemment oui, et il est même crucial).
Se mettre en capacité de patcher vite
Le verdict est tombé : s’appuyer sur une bibliothèque libre en pensant adresser toutes les problématiques de sécurité est une illusion.
Mais cela n’invalide évidemment pas de recours à de telle bibliothèques, qui conservent leurs avantages en termes de gain de temps, de qualité, d’actualité, de coût, etc.
Il faut cependant être conscient que dès qu’une vulnérabilité est décelée, des attaquants lancent des opérations à grande échelle pour tenter de l’exploiter.
Cela implique plusieurs choses :
• se donner les moyens d’être informé très rapidement de la découverte de la vulnérabilité
• pouvoir empêcher son exploitation, par exemple en agissant au niveau du parefeu applicatif (WAF) ou en désactivant des fonctionnalités
• être capable de mettre à jour la bibliothèque incriminée dès la disponibilité du correctif
Moyennant ces actions, le niveau de sécurité est maintenu.
Et n’oubliez pas pendant votre temps libre de regarder le code source des bibliothèques que vous utilisez à la recherche de vulnérabilités !
Auteur : Marc (Directeur technique)
Related Posts
