Pas mal de code présent dans les librairies open source déborde d’erreurs. La plupart des développeurs estiment en effet à tort que ce code est sûr, et n’accordent donc guère d’attention à le tester et à le passer en revue. La… règle est dès lors d’attendre le prochain abus (exploit) qui peut avoir de graves conséquences.
L”open source’ (code source ouvert) est sûr car le code peut être visionné et amélioré par tout un chacun, selon le mythe. Le problème, c’est que personne ne le fait. Les développeurs estiment en bloc que d’autres l’ont déjà fait avant eux. Les projets faisant la part belle à de nombreux logiciels open source, sont aux prises avec un manque de personnel et de budget, ce qui fait que plus encore qu’avec les logiciels ‘fermés’, les tests manquent ici à l’appel. Les entreprises qui éditent du software intégrant des éléments open source, ne consacrent aucune attention au suivi de ceux-ci. Voilà ce que déclare Jake Kouns, chief information security officer chez Risk Based Security, à IDG News Service.
Heartbleed, Shellshock et POODLE sont 3 exemples significatifs d’échecs. La raison pour laquelle on leur a accordé beaucoup d’attention, c’est que ces bugs ont été baptisés d’appellations évocatrices et que les médias s’y sont intéressés de très près. Il existe pourtant bien d’autres exemples de bugs dans des libraires comme OpenSSL, LibTIFF, libpng, OpenJPEG, FFmpeg, Libav, etc. Ce code est intégré à des milliers de produits qui constituent la base de l’infrastructure d’internet.
Il manque une vue d’ensemble de l’utilisation de l’open source
Un problème supplémentaire, c’est que les éditeurs de logiciels utilisant le code open source n’ont souvent pas une bonne vision des composants de tiers qu’ils utilisent dans leur software. Ils n’ont pas non plus une vue sur les failles décelées, et encore moins sur le fait de savoir si celles-ci ont été correctement corrigées (patchées). Carsten Eiram, chief research officer chez Risk Based Security, cite Adobe Systems et Google comme des exceptions positives à la règle. Les deux entreprises distinguent en effet les menaces et agissent en vue de détecter pro-activement les bugs dans le code.
Un avantage des problèmes largement étendus causés par Heartbleed et POODLE, c’est que les chercheurs en sécurité disposent à présent d’un modèle avec lequel ils peuvent attirer une grande attention sur ce genre de problèmes via les médias. Les éditeurs de logiciels n’aiment pas être soudainement confrontés à une inflexion des budgets au profit d’équipes qui doivent au pied levé rechercher les éléments dans lesquels des bugs ont été détectés. Ils sont aussi plutôt enclins à tester pro-activement le software de tiers qu’ils utilisent dans leurs produits ou, à tout le moins, à mieux enregistrer où les éléments de tiers sont appliqués dans leurs logiciels. La plupart considèrent malheureusement encore Heartbleed, Shellshock et POODLE comme des cas isolés plutôt que faisant partie d’une tendance, comme le craint Chris Eng, vice president research chez Veracode.
Source: Automatiseringsgids
