Christian Hindre
Comment oublier Heartbleed : il y a quelques années, cette vulnérabilité présente dans la bibliothèque de cryptographie open source OpenSSL a soulevé un véritable vent de panique dans l'industrie des logiciels et au sein des entreprises du monde entier. À l'époque, les éditeurs (et donc leurs clients) en savaient trop peu sur les composants open source utilisés dans leurs propres produits pour déterminer si leurs logiciels étaient vulnérables.
Aujourd'hui, la question est de savoir s'ils ont su en tirer des enseignements ?
Malheureusement, la réponse est « non !». Pour ne pas être victime du prochain Heartbleed, les entreprises devront donc mettre en place les processus et fonctions d'automatisation nécessaires afin d'être en mesure d'analyser, de suivre et de gérer les composants open source au sein de leurs produits. Elles découvriront ainsi lesquels sont vulnérables, et quels clients sont exposés. Il leur faudra également mettre en place des systèmes et des outils d'automatisation afin de corriger ces failles, et s'assurer de la sécurité des logiciels qu'elles développent et fournissent à leurs clients. Le risque de mettre leur chaîne d'approvisionnement en danger sera alors limité.
Le contexte actuel
Imaginez-vous consulter votre flux d'actualités et y voir apparaître une multitude de publications au sujet d'une nouvelle faille au sein d'un composant open source. Généralement, les événements se succèdent de façon assez standard : dans un premier temps, la nouvelle se propage lentement, puis les mentions et retweets se multiplient. Viennent alors des questionnements quant au sérieux du problème (« cette faille peut-elle réellement être exploitée ? ») ; enfin, on pointe certains responsables du doigt, ou on se lance dans des analyses de code, à postériori. Pendant ce temps, vous recevez les premières interrogations de la part de votre patron ou des responsables des produits : « Cette nouvelle nous concerne-t-elle ? », « Que faisons-nous en interne ou vis-à-vis de nos clients ? », « Sommes-nous déjà victimes de piratages » ?
Il y a 10 ou 20 ans, les professionnels l'ingénierie savaient ce que contenaient leurs produits. Il leur suffisait de jeter un œil aux boîtiers des bibliothèques logicielles dont ils avaient acquis les licences, tandis que les outils téléchargés ou le code issu d'un ouvrage célèbre n'étaient présents qu'en quantités limitées. Lent au départ, le changement au niveau du modèle de développement s'est ensuite opéré du jour au lendemain : nous sommes passés de logiciels essentiellement conçus en interne et avec peu de bibliothèques commerciales à des projets basés au moins à 50 % sur des composants open source récupérés en téléchargement (et pas toujours depuis des emplacements bien définis dans l'arbre des sources). Pourtant, il est impossible de répondre à la question « Sommes-nous affectés par cette faille ? » sans une liste des dépendances ou une bonne nomenclature.
Contrairement à ce que l'on pourrait penser, aujourd'hui encore, et malgré l'épisode Heartbleed, la grande majorité des éditeurs auraient beaucoup de mal à fournir de telles listes. Ainsi, selon les résultats de travaux de recherche, la plupart n'en sont pas capables, et chez les autres, le pourcentage moyen de composants connus n'est que de 4 % ! Cela signifie que 24 composants sur 25 sont utilisés et fournis aux utilisateurs alors qu'ils sont inconnus et mal gérés.
Une analyse rapide
Pour savoir où vous en êtes, le plus simple est de vérifier que vous êtes capable de créer une telle nomenclature, et de déterminer de quand date sa dernière mise à jour. Si le résultat est le fruit du reporting effectué spontanément par vos développeurs, alors cette liste ne représente certainement qu'un faible pourcentage de la réalité. Prenez des échantillons du code base pour vérifier si les numéros des versions indiqués sont encore valides. Effectuez une rapide analyse des noms des bibliothèques ; recherchez des chaînes relatives aux droits d'auteurs, licences et fichiers COPYING ; passez en revue les extensions de fichiers vraisemblablement tiers (JAR ou DLL, par exemple).
Même une analyse rapide vous permettra de découvrir un grand nombre d'éléments tiers précédemment ignorés.
Pour être encore mieux fixé, recherchez la chaîne « OpenSSL » : vous trouverez assurément plusieurs copies d'instances précédemment inconnues d'OpenSSL embarquées dans des composants open source commerciaux. Les inclusions de fichiers source et binaires seront également repérées.
Ces tests autonomes peuvent rapidement vous montrer si votre nomenclature est incomplète ou obsolète. Bien sûr, il y a des découvertes plus réjouissantes, mais beaucoup d'autres entreprises du milieu des logiciels sont dans votre cas.
Différents scénarios
Dans certains scénarios, vous trouverez des composants open source possiblement affectés par des failles divulguées. Par exemple, lorsque des éléments sont intégrés en tant que composants de niveau supérieur, souvent dans des fichiers ou des répertoires avec des noms transparents. Ceux-ci sont plus faciles à identifier en raison de leur visibilité, mais ne représentent pas l'ensemble du tableau. Les éditeurs peuvent également s'intéresser à leurs sous-composants. Cette tâche plus complexe est souvent négligée, même dans le cas d'une faille aussi bien connue que Heartbleed. En effet, les versions de ces composants ayant déjà été compilées et liées à des packages plus larges sont presque invisibles pour les développeurs moyens cherchant à établir une liste complète des dépendances. Enfin, les responsables du code base devront analyser les fichiers source restant afin de repérer des chaînes coupées et collées, remaniées ou réorganisées à partir d'un package open source plus global. Cette dernière phase peut être impossible à réaliser en jetant simplement un coup d'œil au code base.
Une fois la nomenclature créée, cette dernière devra être étudiée pour vérifier qu'aucun autre composant avec des failles connues ne soit présent. Attendez-vous à trouver vulnérabilités, en particulier lors du premier cycle d'analyse. Certaines seront même simples à exploiter ; d'autres moins. Il est fréquent que les éditeurs établissent également une hiérarchie des failles trouvées. Leurs solutions sont alors d'effectuer des mises à niveau vers les versions les plus récentes, d'appliquer des correctifs, d'interdire les accès, et dans certains cas, de supprimer le composant et les fonctionnalités affectées.
Parfois, une vulnérabilité aura été introduite à cause d'un sous-composant d'un composant plus large issu de votre chaîne d'approvisionnement. Si vous n'êtes pas trop malchanceux, vos fournisseurs auront déjà créé et mis à disposition les correctifs adéquats...
Processus de journalisation des défauts
Familiarisez-vous avec le processus de journalisation des défauts pour vos composants open source et commerciaux. Il s'agit en effet d'une part essentielle du cycle de vie d'une vulnérabilité.
Une fois qu'une nouvelle version de votre produit est mise à disposition, l'entretien d'une nomenclature valide et la vérification de cette liste à la recherche de failles connues doivent se poursuivre tant que ce logiciel est à la fois développé et utilisé. Ce doit également être le cas pour toutes les versions utilisées par votre communauté d'utilisateurs. En effet, il se peut qu'un grand nombre d'entre eux continuent à se servir de versions obsolètes de votre logiciel, quelle que soit celle adoptée par votre équipe de développement.
Tant que l'industrie du logiciel n'aura pas mis en place des processus similaires à ceux détaillés ci-dessus, elle restera prise au dépourvu face à des failles telles que « Heartbleed ».
À propos de Flexera Software
Flexera Software aide les éditeurs de logiciels et les entreprises à optimiser l'utilisation et la sécurité de leurs applications, renforçant la valeur qu'elles produisent. Nos solutions de licences logicielles, de conformité, de sécurité et d'installation des logiciels sont essentielles pour assurer la conformité continue aux licences, les investissements en logiciels optimisés, et pour pérenniser des entreprises contre les risques et les coûts de la technologie en constante évolution. Leader du marché mondial depuis plus de 25 ans, plus de 80 000 clients se tournent vers Flexera Software pour trouver une source fiable et neutre de connaissances et d'expertise, et pour l'automatisation et l'intelligence intégrées dans nos produits.
flexerasoftware.fr
Aujourd'hui, la question est de savoir s'ils ont su en tirer des enseignements ?
Malheureusement, la réponse est « non !». Pour ne pas être victime du prochain Heartbleed, les entreprises devront donc mettre en place les processus et fonctions d'automatisation nécessaires afin d'être en mesure d'analyser, de suivre et de gérer les composants open source au sein de leurs produits. Elles découvriront ainsi lesquels sont vulnérables, et quels clients sont exposés. Il leur faudra également mettre en place des systèmes et des outils d'automatisation afin de corriger ces failles, et s'assurer de la sécurité des logiciels qu'elles développent et fournissent à leurs clients. Le risque de mettre leur chaîne d'approvisionnement en danger sera alors limité.
Le contexte actuel
Imaginez-vous consulter votre flux d'actualités et y voir apparaître une multitude de publications au sujet d'une nouvelle faille au sein d'un composant open source. Généralement, les événements se succèdent de façon assez standard : dans un premier temps, la nouvelle se propage lentement, puis les mentions et retweets se multiplient. Viennent alors des questionnements quant au sérieux du problème (« cette faille peut-elle réellement être exploitée ? ») ; enfin, on pointe certains responsables du doigt, ou on se lance dans des analyses de code, à postériori. Pendant ce temps, vous recevez les premières interrogations de la part de votre patron ou des responsables des produits : « Cette nouvelle nous concerne-t-elle ? », « Que faisons-nous en interne ou vis-à-vis de nos clients ? », « Sommes-nous déjà victimes de piratages » ?
Il y a 10 ou 20 ans, les professionnels l'ingénierie savaient ce que contenaient leurs produits. Il leur suffisait de jeter un œil aux boîtiers des bibliothèques logicielles dont ils avaient acquis les licences, tandis que les outils téléchargés ou le code issu d'un ouvrage célèbre n'étaient présents qu'en quantités limitées. Lent au départ, le changement au niveau du modèle de développement s'est ensuite opéré du jour au lendemain : nous sommes passés de logiciels essentiellement conçus en interne et avec peu de bibliothèques commerciales à des projets basés au moins à 50 % sur des composants open source récupérés en téléchargement (et pas toujours depuis des emplacements bien définis dans l'arbre des sources). Pourtant, il est impossible de répondre à la question « Sommes-nous affectés par cette faille ? » sans une liste des dépendances ou une bonne nomenclature.
Contrairement à ce que l'on pourrait penser, aujourd'hui encore, et malgré l'épisode Heartbleed, la grande majorité des éditeurs auraient beaucoup de mal à fournir de telles listes. Ainsi, selon les résultats de travaux de recherche, la plupart n'en sont pas capables, et chez les autres, le pourcentage moyen de composants connus n'est que de 4 % ! Cela signifie que 24 composants sur 25 sont utilisés et fournis aux utilisateurs alors qu'ils sont inconnus et mal gérés.
Une analyse rapide
Pour savoir où vous en êtes, le plus simple est de vérifier que vous êtes capable de créer une telle nomenclature, et de déterminer de quand date sa dernière mise à jour. Si le résultat est le fruit du reporting effectué spontanément par vos développeurs, alors cette liste ne représente certainement qu'un faible pourcentage de la réalité. Prenez des échantillons du code base pour vérifier si les numéros des versions indiqués sont encore valides. Effectuez une rapide analyse des noms des bibliothèques ; recherchez des chaînes relatives aux droits d'auteurs, licences et fichiers COPYING ; passez en revue les extensions de fichiers vraisemblablement tiers (JAR ou DLL, par exemple).
Même une analyse rapide vous permettra de découvrir un grand nombre d'éléments tiers précédemment ignorés.
Pour être encore mieux fixé, recherchez la chaîne « OpenSSL » : vous trouverez assurément plusieurs copies d'instances précédemment inconnues d'OpenSSL embarquées dans des composants open source commerciaux. Les inclusions de fichiers source et binaires seront également repérées.
Ces tests autonomes peuvent rapidement vous montrer si votre nomenclature est incomplète ou obsolète. Bien sûr, il y a des découvertes plus réjouissantes, mais beaucoup d'autres entreprises du milieu des logiciels sont dans votre cas.
Différents scénarios
Dans certains scénarios, vous trouverez des composants open source possiblement affectés par des failles divulguées. Par exemple, lorsque des éléments sont intégrés en tant que composants de niveau supérieur, souvent dans des fichiers ou des répertoires avec des noms transparents. Ceux-ci sont plus faciles à identifier en raison de leur visibilité, mais ne représentent pas l'ensemble du tableau. Les éditeurs peuvent également s'intéresser à leurs sous-composants. Cette tâche plus complexe est souvent négligée, même dans le cas d'une faille aussi bien connue que Heartbleed. En effet, les versions de ces composants ayant déjà été compilées et liées à des packages plus larges sont presque invisibles pour les développeurs moyens cherchant à établir une liste complète des dépendances. Enfin, les responsables du code base devront analyser les fichiers source restant afin de repérer des chaînes coupées et collées, remaniées ou réorganisées à partir d'un package open source plus global. Cette dernière phase peut être impossible à réaliser en jetant simplement un coup d'œil au code base.
Une fois la nomenclature créée, cette dernière devra être étudiée pour vérifier qu'aucun autre composant avec des failles connues ne soit présent. Attendez-vous à trouver vulnérabilités, en particulier lors du premier cycle d'analyse. Certaines seront même simples à exploiter ; d'autres moins. Il est fréquent que les éditeurs établissent également une hiérarchie des failles trouvées. Leurs solutions sont alors d'effectuer des mises à niveau vers les versions les plus récentes, d'appliquer des correctifs, d'interdire les accès, et dans certains cas, de supprimer le composant et les fonctionnalités affectées.
Parfois, une vulnérabilité aura été introduite à cause d'un sous-composant d'un composant plus large issu de votre chaîne d'approvisionnement. Si vous n'êtes pas trop malchanceux, vos fournisseurs auront déjà créé et mis à disposition les correctifs adéquats...
Processus de journalisation des défauts
Familiarisez-vous avec le processus de journalisation des défauts pour vos composants open source et commerciaux. Il s'agit en effet d'une part essentielle du cycle de vie d'une vulnérabilité.
Une fois qu'une nouvelle version de votre produit est mise à disposition, l'entretien d'une nomenclature valide et la vérification de cette liste à la recherche de failles connues doivent se poursuivre tant que ce logiciel est à la fois développé et utilisé. Ce doit également être le cas pour toutes les versions utilisées par votre communauté d'utilisateurs. En effet, il se peut qu'un grand nombre d'entre eux continuent à se servir de versions obsolètes de votre logiciel, quelle que soit celle adoptée par votre équipe de développement.
Tant que l'industrie du logiciel n'aura pas mis en place des processus similaires à ceux détaillés ci-dessus, elle restera prise au dépourvu face à des failles telles que « Heartbleed ».
À propos de Flexera Software
Flexera Software aide les éditeurs de logiciels et les entreprises à optimiser l'utilisation et la sécurité de leurs applications, renforçant la valeur qu'elles produisent. Nos solutions de licences logicielles, de conformité, de sécurité et d'installation des logiciels sont essentielles pour assurer la conformité continue aux licences, les investissements en logiciels optimisés, et pour pérenniser des entreprises contre les risques et les coûts de la technologie en constante évolution. Leader du marché mondial depuis plus de 25 ans, plus de 80 000 clients se tournent vers Flexera Software pour trouver une source fiable et neutre de connaissances et d'expertise, et pour l'automatisation et l'intelligence intégrées dans nos produits.
flexerasoftware.fr
Les médias du groupe Finyear
Lisez gratuitement :
FINYEAR
Le quotidien Finyear :
- Finyear Quotidien
Sa newsletter quotidienne :
- Finyear Newsletter
Recevez chaque matin par mail la newsletter Finyear, une sélection quotidienne des meilleures infos et expertises en Finance innovation & Digital transformation.
Ses 4 lettres mensuelles digitales :
- Le Directeur Financier
- Le Trésorier
- Le Credit Manager
- The Chief Digital Officer
Finyear magazine trimestriel digital :
- Finyear Magazine
Un seul formulaire d'abonnement pour choisir de recevoir un ou plusieurs médias Finyear
BLOCKCHAIN DAILY NEWS
Le quotidien Blockchain Daily News :
- Blockchain Daily News
Sa newsletter quotidienne :
- Blockchain Daily News Newsletter
Recevez chaque matin par mail la newsletter Blockchain daily News, une sélection quotidienne des meilleures infos et expertises en Blockchain révolution.
Sa lettre mensuelle digitale :
- The Chief Blockchain Officer
FINYEAR
Le quotidien Finyear :
- Finyear Quotidien
Sa newsletter quotidienne :
- Finyear Newsletter
Recevez chaque matin par mail la newsletter Finyear, une sélection quotidienne des meilleures infos et expertises en Finance innovation & Digital transformation.
Ses 4 lettres mensuelles digitales :
- Le Directeur Financier
- Le Trésorier
- Le Credit Manager
- The Chief Digital Officer
Finyear magazine trimestriel digital :
- Finyear Magazine
Un seul formulaire d'abonnement pour choisir de recevoir un ou plusieurs médias Finyear
BLOCKCHAIN DAILY NEWS
Le quotidien Blockchain Daily News :
- Blockchain Daily News
Sa newsletter quotidienne :
- Blockchain Daily News Newsletter
Recevez chaque matin par mail la newsletter Blockchain daily News, une sélection quotidienne des meilleures infos et expertises en Blockchain révolution.
Sa lettre mensuelle digitale :
- The Chief Blockchain Officer