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