Sécurité des Librairies et Logiciels Open Source
trait de séparation
Devenue une pratique courante de nos jours, l’intérêt de l’utilisation de l’Open Source n’est plus à démontrer, ne serait-ce que par le gain de temps que cela amène. Il est souvent plus avantageux d’utiliser une librairie Open Source largement utilisée pour réaliser une fonction que de la recréer soi- même. Cette pratique s’est largement diffusée dans l’informatique générale, dans les logiciels commerciaux, mais aussi de plus en plus dans les applications industrielles et les logiciels critiques. Si la démarche apporte une vraie valeur ajoutée, elle conduit néanmoins à une réelle problématique : comment s’assurer de la qualité de ces librairies ? C’est pour aider ses clients à répondre à ces questions qu’ISIT vient de signer un partenariat avec la société WhiteSource, leader dans la gestion qualité des codes Open Source.
La genèse des librairies Open Source
Bon nombre des librairies Open Source sont des projets collaboratifs, souvent développés par plusieurs équipes réparties sur le globe et avec beaucoup de variantes dans leur développement et leurs évolutions. De plus, un certain nombre de librairies ou logiciels Open Source se basent eux-mêmes sur d’autres librairies Open Source, soit de manière explicite, soit enfouies sans qu’on en ait conscience. Enfin, contrairement à une idée répandue, Open Source ne signifie pas toujours gratuit et libre de droit. Ces librairies peuvent être soumises à des droits d’utilisation ou de licence particuliers qu’il est important, voire critique de connaitre.
Pour les équipes de développement et leurs responsables, il est donc devenu crucial d’être à même, non seulement de cartographier l’ensemble des librairies Open Source utilisées, mais également d’en connaitre les failles et vulnérabilités.
Pour les équipes de développement et leurs responsables, il est donc devenu crucial d’être à même, non seulement de cartographier l’ensemble des librairies Open Source utilisées, mais également d’en connaitre les failles et vulnérabilités.
Maitriser son logiciel
La première étape est de faire l’inventaire de l’ensemble des librairies implémentées dans les produits que l’on développe. Même si on démarre le développement de son nouveau logiciel de zéro, le nombre de libraires qui seront potentiellement utilisées peut être important, sans compter la possibilité qu’elles-mêmes contiennent aussi des composants Open Source. Il est donc très difficile, voire impossible d’en faire l’inventaire et surtout de le maintenir à jour manuellement. Au-delà d’un certain seuil de taille de code, il devient donc quasi impératif d’utiliser des outils qui vont faire cet inventaire automatiquement et y attacheront les droits de licences associés. Il sera alors déjà possible de vérifier si on s’y conforme et s’ils sont acceptables pour le produit que l’on va réaliser. De plus en plus dans les applications industrielles, le client final exige des informations concrètes et avérées des droits et obligations attachés au logiciel dont il fait l’acquisition.
Comment s’assurer de la Qualité des Logiciels Open Source ?
Une fois cet inventaire réalisé, comment évaluer la qualité de ces composants Open Source ? Comment connaitre les failles et les vulnérabilités qu’elles contiennent ? Et si faille il y a, y est-on réellement exposé ?
Une première stratégie pourrait être d’effectuer sur celles-ci les mêmes types de tests que sur le code que l’on développe : Analyse statique, campagne de tests unitaires/fonctionnels et bien d’autres. Si en théorie cela est possible, en pratique cette tâche peut se révéler très chronophage, excessivement coûteuse voire impossible. Alors que faire ?
Il s’avère qu’il existe en fait différentes bases de données listant les failles et les vulnérabilités pour une très grande majorité de logiciels et des librairies Open Source. Parmi les plus connues figure le Common Vulnerabilities and Exposure glossary ou CVE de la fondation MITRE (financée par le département US HomeLand Security Division). Le CVE utilise un protocole particulier, le SCAP (Security Content Automation Protocol) pour collecter les informations de sécurité et de failles des logiciels Open Source. Une fois collectées et validées, ces informations se voient dotée d’un identifiant unique et enregistrées dans la base de données publique CVE.
Une première stratégie pourrait être d’effectuer sur celles-ci les mêmes types de tests que sur le code que l’on développe : Analyse statique, campagne de tests unitaires/fonctionnels et bien d’autres. Si en théorie cela est possible, en pratique cette tâche peut se révéler très chronophage, excessivement coûteuse voire impossible. Alors que faire ?
Il s’avère qu’il existe en fait différentes bases de données listant les failles et les vulnérabilités pour une très grande majorité de logiciels et des librairies Open Source. Parmi les plus connues figure le Common Vulnerabilities and Exposure glossary ou CVE de la fondation MITRE (financée par le département US HomeLand Security Division). Le CVE utilise un protocole particulier, le SCAP (Security Content Automation Protocol) pour collecter les informations de sécurité et de failles des logiciels Open Source. Une fois collectées et validées, ces informations se voient dotée d’un identifiant unique et enregistrées dans la base de données publique CVE.
Dès lors le NVD (National Vulnerability Database) récupère ces vulnérabilités publiées dans le CVE pour en faire une analyse de sécurité très détaillée pour notamment déterminer le CVSS (Severity Score) du CVE. Ces résultats sont ensuite publiés dans la base NVD.
La bonne stratégie est donc, et ce pour chaque logiciel et librairie Open Source utilisé, d’aller consulter ces différentes bases de données pour récupérer la liste des failles connues et d’en calculer le risque pour son propre produit. Néanmoins, si les bases CVE et NVD sont des références, elles ne contiennent malheureusement pas toutes les failles des logiciels Open Source. Cela peut arriver si l’équipe ou la société qui détecte une faille ne contacte pas une des 93 entités CNA (CVE Numbering Authority) pour le signaler ou si le CNA estime qu’il n’est pas pertinent de l’enregistrer. De ce fait pour que cette veille technique sur les vulnérabilités soit efficace, il faut non seulement analyser les CVE mais il faut également se connecter aux bases de données des projets Open Source eux-mêmes afin d’avoir un état des lieux précis. A titre d’exemple, WhiteSource a quantifié dans son rapport Annual Report on the State of Open Source Vulnerabilities Management publié en 2018 que seulement 86% environ des vulnérabilités connues des logiciels Open Source sont référencées dans le CVE, les 14% restants étant listés dans d’autres bases de données que celle de MITRE. De manière plus précise, 30% des vulnérabilités du langage JavaScript et 20% des failles du langage Ruby ne seraient pas répertoriées dans le CVE mais dans des bases tierces.
De par leur nature, les logiciels Open Source sont communautaires, et même s’il y a un « responsable » initial du projet, leur développement est souvent distribué : Il y a donc un flot continu d’évolutions et de correctifs. Toutes ces modifications, alertes sur les défauts ou vulnérabilités, trouvées ou corrigées, étant elles aussi répertoriées sur des serveurs différents, il devient alors très difficile de connaitre avec précision la qualité de la version qu’on utilise.
Il est donc évident que mener une telle veille technique manuellement n’est pas possible, ne serait-ce qu’en raison du nombre important de composants Open Source à vérifier, et que cette tâche doit être automatisée par des outils
La bonne stratégie est donc, et ce pour chaque logiciel et librairie Open Source utilisé, d’aller consulter ces différentes bases de données pour récupérer la liste des failles connues et d’en calculer le risque pour son propre produit. Néanmoins, si les bases CVE et NVD sont des références, elles ne contiennent malheureusement pas toutes les failles des logiciels Open Source. Cela peut arriver si l’équipe ou la société qui détecte une faille ne contacte pas une des 93 entités CNA (CVE Numbering Authority) pour le signaler ou si le CNA estime qu’il n’est pas pertinent de l’enregistrer. De ce fait pour que cette veille technique sur les vulnérabilités soit efficace, il faut non seulement analyser les CVE mais il faut également se connecter aux bases de données des projets Open Source eux-mêmes afin d’avoir un état des lieux précis. A titre d’exemple, WhiteSource a quantifié dans son rapport Annual Report on the State of Open Source Vulnerabilities Management publié en 2018 que seulement 86% environ des vulnérabilités connues des logiciels Open Source sont référencées dans le CVE, les 14% restants étant listés dans d’autres bases de données que celle de MITRE. De manière plus précise, 30% des vulnérabilités du langage JavaScript et 20% des failles du langage Ruby ne seraient pas répertoriées dans le CVE mais dans des bases tierces.
De par leur nature, les logiciels Open Source sont communautaires, et même s’il y a un « responsable » initial du projet, leur développement est souvent distribué : Il y a donc un flot continu d’évolutions et de correctifs. Toutes ces modifications, alertes sur les défauts ou vulnérabilités, trouvées ou corrigées, étant elles aussi répertoriées sur des serveurs différents, il devient alors très difficile de connaitre avec précision la qualité de la version qu’on utilise.
Il est donc évident que mener une telle veille technique manuellement n’est pas possible, ne serait-ce qu’en raison du nombre important de composants Open Source à vérifier, et que cette tâche doit être automatisée par des outils
La solution WhiteSource
Partenaire ISIT, WhiteSource offre la seule solution du marché « tout-en-un », permettant de gérer et de contrôler la qualité des composants Open Source que vous utilisez comme briques logicielles pour concevoir vos applications. WhiteSource analyse automatiquement vos codes pour y détecter les librairies Open Source, et effectue un monitoring en temps réel de la qualité de ces libraires en termes de défauts et de vulnérabilités connues sur ces librairies.
WhiteSource surveille en permanence vos composants Open Source à chaque étape du cycle de vie du développement logiciel, et ce même après leur publication, sur la base du dernier rapport d'inventaire. Une fois intégré à votre projet, il fonctionne de manière continue et automatique, en gardant un œil attentif sur vos composants Open Source.
WhiteSource surveille en permanence vos composants Open Source à chaque étape du cycle de vie du développement logiciel, et ce même après leur publication, sur la base du dernier rapport d'inventaire. Une fois intégré à votre projet, il fonctionne de manière continue et automatique, en gardant un œil attentif sur vos composants Open Source.
Intégré sous forme de plugin dans l’environnement de développement, WhiteSource calcule la signature digitale de chaque librairie Open Source présente dans le code utilisateur. Cette signature est alors comparée à l’ensemble des signatures de toutes les librairies Open Source existantes à travers les bases de données des composants Open Source. WhiteSource ne rapatrie aucun code utilisateur sur ses bases de données, il ne fait que comparer la signature digitale des librairies Open Source utilisées dans le code. Les bases de données de WhiteSource regroupent les références de la plus grande majorité de librairies Open Source au monde, soit plus de 200 langages de programmation ainsi que l’ensemble des distributions Linux. Quelle que soit l’origine du projet Open Source dont les librairies que vous utilisez sont issues, WhiteSource les connaitra.
