Composants Open Source : retour sur investissement en minimisant les risques

Comment accroître les bénéfices de l’Open Source dans le cycle de développement d’application tout en réduisant les risques induits ?

C’est un scénario que de nombreux développeurs Java ont déjà rencontré et qu’ils redoutent. En vous connectant à votre messagerie, vous découvrez des messages de panique du Directeur de la sécurité, du Directeur des Etudes ou du Directeur commercial. Un composant Open Source fréquemment utilisé contient  une faille de sécurité susceptible d’exposer vos applications clients à une attaque. Pire, cette vulnérabilité a été identifiée depuis quelques semaines, mais votre entreprise n’était pas informée.

Les questions et les accusations volent. « Pourquoi utilisons-nous des composants Open source dans nos applications critiques ? ». « Pourquoi ne pas supprimer ce composant et le remplacer par un autre, plus sûr ? ». « Avez-vous une idée de l’impact de cette faille si cette information est connue de nos clients ou  investisseurs ? ». « Qu’allez-vous faire pour régler ce problème et vous assurer que cela ne se reproduise pas ? ».

Comment répondriez-vous à ces questions? Que seriez-vous en mesure de faire dans une situation comparable ? Il est probable qu’il ne serait pas simple d’identifier où exactement vous avez utilisé ce composant corrompu pendant le développement de l’application. Une fois cette recherche faite, vous aurez à  modifier, tester et redéployer la nouvelle version de l’application. Ce processus peut prendre des jours, voire des semaines.

Pour éviter ce genre de scenario, les équipes de développement doivent disposer de nouvelles solutions pour gérer le risque relatif aux composants Open source sans ralentir le processus de développement. Il est bon de savoir que des stratégies adaptées, associées à de nouveaux outils, peuvent permettre aux développeurs Java de profiter des apports des composants Open Source tout en préservant le niveau de sécurité et de fiabilité requis par les applications d’entreprise. Mais avant de discuter de cela, arrêtons-nous un instant sur l’usage des composants Open Source et les challenges associés.

Croissance et risques de l’Open Source : Gartner estime que d’ici à 2012, 90% des plus grandes entreprises mondiales (Global 2000 entreprises) intègreront des logiciels Opens source (OSS) dans leur portefeuille d’applications métiers critiques. Et en 2016, ce nombre s’accroitra jusqu’à 99%. Il va sans dire que l’usage de l’Open Source grimpe. Les développeurs Java connaissent déjà la flexibilité incomparable, la facilité de modifier le code et d’optimiser les performances qu’offre l’Open Source. En d’autres termes, l’usage de composants Open Source dans le développement d’applications permet aux entreprises de produire des logiciels de qualité, plus rapidement et pour un coût réduit. Cela étant, la plupart des développeurs Java n’ont pas les moyens de contrôler la sélection, la gestion et la distribution de composants Open Source  qui peuvent exposer votre entreprise à des risques imprévus, techniques ou de conformité, incluant potentiellement des menaces significatives  sur la qualité, la stabilité, la performance, la sécurité et la propriété intellectuelle de vos logiciels.

Le “Central Repository”, le référentiel de référence des  projets Open Source majeurs, contient plus de 300 000 artifacts Java. Il est accédé par les développeurs près de 4 milliards de fois par an. C’est l’un des sites Web les plus visités de l’Internet aujourd’hui. En tant qu’administrateur du « Central Repository », Sonatype peut accéder, extraire et partager les informations d’usage de composants Open Source de plus de 40 000 organisations à travers le monde. Sonatype a découvert que de nombreux développeurs téléchargent des composants Open Source sans disposer véritablement de moyens pour surveiller ou contrôler leur usage. Une étude réalisée en 2011 auprès de 1600 développeurs, team leaders et architectes révèle que 87% des entreprises ne contrôlent pas l’usage des composants Open Source.

Gérer le risque dans le cycle de développement des applications : Pour gérer l’utilisation et le risque de l’Open source tout au long du cycle de développement, les entreprises doivent mettre en œuvre des standards pour les développements basés sur l’Open source. Les développeurs Java ont besoin d’outils pour gérer le risque et maximiser la valeur de ces composants Open Source. Ces outils sont disponibles dès à présent et peuvent aider les entreprises à obtenir le meilleur retour sur investissement, réduire le risque de l’Open Source dans les phases de conception, de développement, d'intégration, de test et de mise en production.

Choisir les meilleurs composants : En premier lieu, vous devez avoir un moyen de sélectionner les composants de façon à ce que seuls les meilleurs soient utilisés dans vos applicatifs. De façon évidente, avec plus de 300 000 composants disponibles dans le « Central Repository » il est difficile d’être certain d’utiliser les meilleurs composants, d’autant que la plupart sont continuellement mis à jour. Sur 12 389 artifacts Open Source mis à jour en 2010, 63% l’ont été 2 ou 3 fois et 30% 4 fois ou plus. 58% des répondants à l’enquête de Sonatype ont indiqué avoir cherché des informations sur le Web quant à la mise à jour des composants Open Source et 28% n’ont pas trouvé de sources fiables. Cependant, il existe des outils destinés à améliorer la qualité des composants Open Source dès le départ, en vous aidant à choisir les meilleurs composants à partir de votre IDE. Vous pouvez même chercher les composants par catégorie, type de licence, ou en utilisant les informations de qualité et de sécurité. Vous pouvez également vous abonner à des alertes sur les mises à jour de composants, pour vous assurer que des composants imparfaits ne sont pas intégrés accidentellement à vos applications.

Identifier les failles de sécurité : Il n’est pas rare que des vulnérabilités soient découvertes dans des composants Open Source populaires. Même lorsque des alertes de sécurité sont diffusées et facilement accessibles sur Internet, elles sont très souvent ignorées. En mars 2009, l’équipe du United States Computer Emergency Readiness et le National Institute of Standards and Technology (US-CERT/NIST) ont diffusé une alerte de sécurité concernant l’API de cryptographie Java « Legion of the Bouncy Castle » indiquant son extrême vulnérabilité à une attaque distante. En janvier 2011, presque 2 ans plus tard, 1 651 organisations différentes ont téléchargé la version vulnérable de ce composant. Cet exemple n’est malheureusement pas isolé ! Vous pouvez faire plus que simplement parcourir le Web ou vous reposer sur le bouche à oreille pour vous tenir informer des failles de sécurité. En fait, il est possible de gérer l’utilisation des composants Open Source de façon proactive tout au long du processus de conception et de développement. Recherchez des outils qui vous permettent d’analyser la qualité, les informations de licence et de sécurité à partir de votre environnement de développement, pendant la phase de conception. Ceux-ci vous alerteront des failles de sécurité et détecteront les composants défaillants pendant le développement et même bien après la mise en production.

Rationnaliser la gestion des dépendances : L’utilisation de composants Open Source rend la construction d’application plus rapide et plus simple. Mais pour chaque composant inclus, ce sont souvent des dizaines d’autres composants dépendants. La gestion des dépendances peut rapidement devenir un processus manuel couteux et consommateur de temps. Mettre en œuvre un contrôle de l’usage de l’Open Source et de la gestion des dépendances peut aider à minimiser les impacts en matière de qualité, sécurité et licences Open Source qui pourraient découler d’un usage sauvage de composants Open Source. Pour sécuriser la gestion des dépendances, il est nécessaire de mettre en œuvre des outils qui surveillent de façon proactive l’intégralité de l’arbre des dépendances, y compris les dépendances transitives (composants qui dépendent d’autres composants). Ils permettent d’identifier exactement quels composants sont utilisés dans vos applications en les scannant et en produisant des rapports détaillés de l’arbre des dépendances. Il est alors facile de pointer les composants ayant des vulnérabilités connues, le type de licence et le niveau de qualité, qu’ils soient au premier niveau de l’arborescence ou au dernier.

La question des licences : Le développement Java, basé sur les composants, introduit des problèmes de licence qui doivent être adressés de façon à éviter des questions de compatibilité pouvant entrainer des pénalités légales et financières. Cependant, comme de nombreux projets Open Source ne soumettent pas toujours des informations correctes sur les licences au « Central Repository », il devient difficile de déterminer les termes de la licence des composants. De plus, en raison des multiples dépendances inhérentes aux développements Java, les composants explicitement intégrés dans vos applications dépendent souvent de dizaines de composants additionnels pour lesquels vous devez vérifier les licences. Il est absolument indispensable de mettre en œuvre  et de faire appliquer une politique de gestion de licences pour vous assurer que seuls des composants aux licences validées sont intégrés dans vos applications.

Un contrôle de l’Open Source à chaque étape : Afin d’assurer l’intégrité de vos composants à toutes les étapes de la chaîne de développement, recherchez des outils qui fournissent une vue à chaque étape du processus de développement. Il existe des solutions qui aident à gérer les composants Open Source de façon efficace, non intrusive et sans modifier vos processus existants.

  • Phase de conception : Améliorez votre recherche initiale de composants avec des outils qui classent les composants par catégorie, licence, qualité et attributs de sécurité.
  • Phase de développement : Mettez en œuvre des outils qui vous notifieront en cas de problèmes de sécurité ou de licences pendant le développement. Ils vous aideront également à gérer les versions multiples d’un même composant.
  • Phase d’intégration : Utilisez des outils qui vous permettent de combiner des données pour vous permettre de surveiller et gérer la consommation de composants Open Source. Vous serez en mesure d’identifier des problèmes potentiels de qualité, sécurité ou de licence. Des outils appropriés vous indiqueront combien de versions différentes et lesquelles de chaque composant ont été téléchargées, vous préciseront où ses composants ont été utilisés, vous faciliteront la gestion des dépendances et vous alerteront des vulnérabilités.
  • Phase de tests : Regardez les outils qui vous permettront d’utiliser les informations relatives à la qualité, les licences et la sécurité dans vos critères d’acceptation de tests. Il existe des outils qui fournissent la nomenclature des applications pendant la phase de tests, et notamment une arborescence complète des dépendances. Ceci vous évitera de laisser passer des vulnérabilités connues ou des licences non désirées.
  • Phase de production : Eliminez les processus manuels fastidieux et source d’erreur en utilisant des outils qui vont scanner les applications et générer des rapports complets sur les composants et les arborescences de dépendances. Ces outils devront bien évidement être en mesure d’adresser les problèmes de sécurité récemment découvert dans des composants utilisés en production.

En mettant en œuvre une politique de l’Open Source et des outils de gestion adaptés, vous allez pouvoir gérer le risque tout en bénéficiant des avantages des composants Open source dans votre processus de développement. Vous serez surtout plus serein quant aux problèmes qui pourraient survenir. Si le scénario que nous décrivions au début de cet article vous arrive, vous serez totalement préparé à l’affronter. Vous serez en mesure de produire un rapport indiquant où le composant incriminé est utilisé. Vous pourrez aisément récréer un environnement pour corriger le problème, tester et redéployer une version corrective en quelques heures et non semaines.

Traduction libre d'un article de Larry Roshfeld publié sur le site SYS-CON Media

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.