Plate-forme d’ evaluation des risques li es a l

heig-vd Annee 2015 - 2016

Travail de Bachelor

Plate-forme d’evaluation des risques

lies a l’utilisation de composants

open source

Etudiant: Parfait Noubissi Encadreur: Olivier Liechti

23 decembre 2016

Plate-forme d’evaluation des risques lies a l’utilisation de composants open source

Table des matieres

I Resume I

II Cahier des charges 1

1 Introduction 2

2 Risques 3

2.1 Aspects legaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Aspects lies a la securite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Aspects lies a la qualite du logiciel . . . . . . . . . . . . . . . . . . . . . . 4

2.4 Strategie de mitigation des risques . . . . . . . . . . . . . . . . . . . . . . . 6

2.5 Techniques et outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Specifications fonctionnelles 9

3.1 Cas d’usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Scenario et presentation de l’interface homme-machine . . . . . . . . . . . 10

4 Architecture 18

4.1 Architecture de haut niveau . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2 Roles des composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2.1 Agent d’indexation . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.2 Modele de donnees et moteur de stockage . . . . . . . . . . . . . . . 23

4.2.3 Application et interface homme-machine . . . . . . . . . . . . . . . 23

4.2.4 Controleur de l’application . . . . . . . . . . . . . . . . . . . . . . . 23

4.2.5 Exploration des donnees via Kibana . . . . . . . . . . . . . . . . . 23

4.2.6 Github . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2.7 NPM (Node Package Manager) . . . . . . . . . . . . . . . . . . . . 24

4.3 Infrastructure de developpement et d’execution . . . . . . . . . . . . . . . 24

4.4 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5 Implementation 27

5.1 Agent d’indexation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2 Elasticsearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.3 Interface Homme Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.3.1 Cas particulier de D3.js . . . . . . . . . . . . . . . . . . . . . . . . 33

5.4 Extraction des donnees via l’API . . . . . . . . . . . . . . . . . . . . . . . 34

6 Erreurs connues 36

1 NOUBISSI Parfait


7 Conclusion 36

7.1 Roadmap pour l’evolution de la plate-forme . . . . . . . . . . . . . . . . . 37

7.1.1 Securite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.1.2 Qualite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.1.3 Autres plate-forme . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

A Installation manuel 39

B Bibliographie 42

2 NOUBISSI Parfait


I Resume

La plupart des applications modernes s’appuient sur des composants open source,

qu’il s’agisse de frameworks ou de librairies. Beaucoup de ces composants utilisent eux-

memes d’autres composants open source. On peut donc representer ces relations sous la

forme d’un graphe de dependances. En outre, toutes les plate-formes de developpement

integrent desormais la notion de gestionnaire de composants (package manager). Maven,

npm, nuget sont des exemples d’outils qui prennent en charge le cycle de vie des com-

posants logiciels reutilisables (publication, indexation, recherche). Ils sont devenus des

elements incontournables du developpement logiciel et sont massivement utilises. Pour

un developpeur, trouver une librairie qui delivre un service, declarer une dependance sur

cette librairie, la recuperer et commencer a l’utiliser est devenu tres simple. Cette sim-

plicite n’est malheureusement pas sans risque. En effet, si on prend du recul, plusieurs

questions se posent au niveau legal, securitaire et qualitatif. On pense par exemple

aux problemes de licences ou aux vulnerabilites qui doivent etre considerees.

Aujourd’hui, beaucoup de developpeurs et d’entreprises sous-estiment cette

problematique et n’en sont pas reellement conscients. L’objectif de ce travail de

bachelor est de developper une plate-forme qui contribuera d’une part a une prise de

conscience, et qui d’autre part permettra de traiter certains des problemes identifies.

I NOUBISSI Parfait


II Cahier des charges

Le but du travail de bachelor est de developper une plate-forme pour aider

les equipes de developpement a gerer les risques lies a l’utilisation de compo-

sants open source. Gerer les risques, cela veut d’abord dire les identifier et les evaluer de

maniere quantitative. L’objectif est de fournir un tableau de bord et des indicateurs

qui aideront les developpeurs a mesurer leur degre d’exposition et a identi-

fier les actions correctives. La plate-forme sera composee de plusieurs sous-systemes,

repartis dans une structure en couches :

— Au niveau inferieur, des agents (crawlers) auront la responsabilite d’extraire des in-

formations dans les depots de composants cibles npm. Ces agents devront egalement

extraire des donnees d’autres sources(e.g. Base de donnees publiques des licences).

— Au niveau intermediaire, les donnees recuperees par les agents seront stockees dans

une base de donnees specialisee (Elasticsearch). Il conviendra donc de definir un

modele pour representer les composants, leurs metadonnees et les relations de

dependances.

— Finalement, au niveau superieur, une interface utilisateur devra permettre aux

utilisateur d’explorer les donnees et de soumettre des requetes. Cette interface

utilisateur devra etre simple a utiliser et devra presenter l’information de maniere

textuelle et graphique.

1 NOUBISSI Parfait


1 Introduction

Le developpement des applications a ete simplifie de facon considerable ces dernieres

annees, grace a l’utilisation des langages de haut niveau. En effet, les langages, tels que Py-

thon, Javascript, Ruby, etc, ont transforme la facon de developper les applications avec

la notion modularite. La modularite permet la reutilisation du code ecrit pour un autre

projet(par nous ou par une autre personne ), ce qui peut faciliter de facon considerable le

developpement. La plupart des frameworks npm, ( maven, nuget, etc ) offrent la possibilite

aux utilisateurs ayant ecrit un module pour leur propre application et qu’ils estiment utile

pour les autres, de publier le code source de leur module sur un depot public : on parle

de ”open source”. En effet, un logiciel est open source lorsqu’il offre un certain nombre

de libertes :

— L’acces au code source ;

— Le droit d’executer ;

— Le droit de modifier le code et de l’adapter ;

— Le droit de partager les modifications que nous avons faites ;

Ainsi tous les modules sont libres d’acces et entierement realises par la communaute.

Ce qui en soit est une tres bonne chose. Cependant, les utilisateurs de la communaute

contribuant de facon benevole, ne sont en general pas responsables des defaillances des

modules qu’ils publient. Il faut egalement signaler que meme dans le domaine de l’open

source, il existe toujours des contraintes legales lorsqu’il s’agit de propriete intellectuelle.

Les developpeurs et les entreprises doivent alors prendre des precautions lorsqu’il s’agit

d’integrer les librairies open source dans leurs projets. L’idee du projet serait de mettre sur

pied une application permettant d’evaluer la securite, la qualite et la legalite d’une appli-

cation. Mais vue le temps imparti pour le travail de Bachelor, nous allons nous concentre

sur la mise sur pied d’une application permettant d’analyser la legalite de l’application.

Un utilisateur pourrait lancer l’application (avec une simple commande). Entrer le re-

pos Github de son application (sous la forme https://github.com/:username/:repos),

l’application devra telecharger, les donnees du projet, les analyser, et fournir un resultat

a l’utilisateur, sous forme textuelle et graphique. L’application devrait etre aussi ergono-

mique et facile a utiliser.

2 NOUBISSI Parfait


2 Risques

L’utilisation des librairies open-sources dans un projet professionnel peut avoir une

reel apport en terme de qualite, de securite, mais aussi en terme de vitesse d’execution.

En effet, le developpeur au lieu d’ecrire tous les modules ”from scratch” utilise du code

deja existant pour faire des modules difficiles ou rebarbatifs, ce qui est un gain de temps

considerable. Cependant, ce code est tres souvent ecrit par une tierce personne et n’offre

aucune garantie. Par consequent, c’est de la responsabilite du developpeur de prendre

toutes les precautions qui s’imposent afin d’assurer la qualite de son logiciel. Nous allons

dans les lignes qui suivent etudier les differents risques que posent les logiciels open-sources

sur le plan legal, securitaire, qualite, etc.

2.1 Aspects legaux

Le logiciel libre est en general synonyme de liberte. Cependant, beaucoup d’utilisa-

teurs/developpeurs pensent qu’un logiciel libre n’est pas soumis aux contraintes liees a

la propriete intellectuelle, ce qui est faux. En effet le code source d’une creation

logicielle est toujours protege. L’open-source est regi par deux grands groupes de

licences :

1. GPL (General Public License) : Les librairies GPL apportent un certain nombre de

contraintes a son utilisateur. Il existe deux grands types de licences GPL ; la licences

copyleft et la licence non-copyleft. La licence copyleft (tres courant) permet a

l’utilisateur de modifier et de distribuer la librairie s’il le souhaite, mais l’oblige a

continuer a appliquer la licence GPL du produit original a l’ensemble du produit

derive, meme si c’est du code proprietaire (tout le produit derive est ”contamine”).

La licence non-copyleft (peu courant) laisse toute la latitude au developpeur de

modifier et de distribuer, il doit toujours rendre public le code derive, mais cette

fois, si le developpeur integre ce code derive dans un code source proprietaire, il

n’est pas contraint de rendre le code proprietaire public (pas de contamination).

Lorsque l’utilisateur modifie un logiciel GPL, il accepte implicitement la licence

GPL et ses contraintes. Par exemple un developpeur qui modifie un code sous

licence GPL ne peut pas octroyer plus de droits a ses utilisateurs qu’il n’en a recu

de la version originale. D’autre part, le droit de modifier le code original n’est

accorde qu’a condition que la version derivee soit distribuee sous licence GPL.

2. BSD (Berkeley System Distribution) : contrairement a la licence GPL, la licence

BSD ne contient quasiment aucune contrainte. Le code sous licence BSD peut etre

integre dans un logiciel libre ou proprietaire.

Au vu de ces eclairages, on peut constater que le logiciel libre contient beaucoup de

contraintes dont on ignore generalement l’existence. Un bon logiciel devant toujours res-

3 NOUBISSI Parfait


pecter les contraintes legales, il est donc question ici de signaler a l’utilisateur d’etre

particulierement attentif a la licence des librairies qu’il utilise pour developper son ap-

plication car lorsqu’il utilise par exemple une librairie sous licence GPL copyleft, tout le

code issu est contamine, par consequent, il doit rendre le code source de l’ensemble de

son application publique sous peine de poursuites judiciaires. Nous pouvons citer le cas

BusyBox qui a poursuivit en juste Westinghouse Digital LLC en 2009 pour violation de

brevet. En effet, Westinghouse Digital LLC incluait plusieurs modules BusyBox dans leurs

televiseurs HD, qu’il distribuait sous une licence incompatible avec GPL. Le tribunal a

alors condamne Westinghouse a payer une amende de 150 000 $. En plus il a ete condamne

a donner tous les televiseurs valant plusieurs millions de dollars a des œuvres de charite.

2.2 Aspects lies a la securite

Dans le domaine informatique, le logiciel open source represente une partie importante

de l’ensemble des logiciels utilises quotidiennement. Ceci est particulierement interessant

pour l’utilisateur final, car ce dernier peut avoir des logiciels de qualite professionnel a un

prix derisoire ou nul. Cette quasi gratuite du logiciel libre n’est pas sans consequences.

Nous allons dans les lignes qui suivent evaluer les risques du logiciel open source du point

de vue de la securite.

— La relecture du code permet de detecter un grand nombre de trous de securite,

mais ne peut pas garantir que tous les trous seront detectes. De plus, rendre le

code source accessible presente quand meme des inconvenients. En effet, lorsque

le code source est publique, les hackers peuvent trouver des vulnerabilites et les

garder pour eux-memes, de facon a exploiter ces vulnerabilites pour leur interets

personnels. Ils peuvent alors exploiter ca pendant des mois, voir meme des

annees avant que cette vulnerabilite soit connue de la communaute et patchee.

Nous pouvons prendre pour exemple le cas de la vulnerabilite qui a touchee

openSSL. Elle a ete decouverte par le grand public en avril 2014, mais etait

active depuis 2011. Des personnes malveillantes ont probablement pu pendant

ces trois annees exploiter cette vulnerabilite a des fins malhonnetes. Le code

open source n’est pas toujours benefique pour la securite.

2.3 Aspects lies a la qualite du logiciel

Une des questions qui revient assez souvent lorsqu’on parle de logiciels open sources

c’est la qualite de ceux-ci. On se demande souvent (probablement avec raison) si un logiciel

fait de facon benevole peut avoir la meme qualite qu’un logiciel fait par des personnes

salariees. Il se trouve que malgre la volonte de la communaute, le logiciel libre presente

un certain nombre de risques que nous allons voir ici :

4 NOUBISSI Parfait


1. Fiabilite : Pour commencer, lorsqu’un projet atteint une certaine taille, le besoin

de finance devient tres important. Or le logiciel open source etant fait par des volon-

taires sans forcement de gros moyens financiers peut etre affecte. Les developpeurs

vont alors faire ce qu’ils peuvent avec les moyens de bord, ce qui peut donner au

final un produit sur lequel les tests n’ont pas ete faits correctement. De plus, la

langue par defaut du developpement logiciel est l’anglais. Dans certains cas il faut

traduire le logiciel vers la langue de l’utilisateur final. Ce processus demande un

reel investissement, car il faut des connaissances metier pour faire une bonne tra-

duction. Mais tres souvent cette partie de l’application est negligee. Ce qui peut

resulter au final a un logiciel de tres mauvaise qualite. Prenons par exemple un

logiciel de comptabilite dont l’interface graphique est ecrite en anglais. Pour le tra-

duire en francais, il faut la contribution d’un vrai comptable, car un informaticien

ne pourra pas traduire un tel logiciel sans une bonne connaissance du metier de

comptable. Par manque de moyen, les informaticiens peuvent se contenter d’utiliser

google traduction. Dans ce cas, meme si le logiciel a la base etait bien fait, on peut

resulter sur une application inutilisable par un comptable, ou pire encore, la tra-

duction peut deboucher sur une application incoherente, qui induit son utilisateur

en erreur. Pour finir, on constate qu’en general, les developpeurs du logiciel open

source declinent toute responsabilite sur le code qu’ils ecrivent. En cas de probleme

avec l’application, il revient a l’utilisateur d’assumer toutes les responsabilites. Par

exemple si le logiciel supprime les donnees tres importantes, l’utilisateur en est le

seul responsable, et non le developpeur.

2. Perennite : Lorsqu’on utilise un logiciel ou une librairie, surtout pour une en-

treprise, il est important que ce dernier puisse etre disponible pendant le plus de

temps possible. Cet aspect entre en compte lorsqu’il faut evaluer la qualite d’un lo-

giciel. Or pour le monde du logiciel libre, il est quasiment impossible de garantir cet

aspect du logiciel. En effet, beaucoup de logiciels libres sont finances par des entre-

prises. Celles-ci le font en fonction de leurs interets commerciaux. Si a un moment

donne l’entreprise ou le financier du logiciel ne trouve plus d’interets financiers sur

un logiciel, il/elle peut abandonner le financement et enterrer le projet. Lorsque

ceci arrive, le logiciel n’est plus mis a jours. Tres souvent c’est la fin du logiciel. En

cas d’erreur, il n’y a personne vers qui se tourner. Il peut arriver qu’un groupe de

personnes decident de forker le projet et de continuer a le developper, mais ce n’est

pas toujours le cas. Et meme si c’est le cas, il impossible de garantir que la nouvelle

version sera compatible avec l’ancienne. Une entreprise peut donc perdre du jours

au lendemain un element important de son appareil de production, ce qui peut

avoir des consequences importantes sur la productivite de cette derniere. Ainsi, si

une entreprise decide par exemple d’utiliser Ubuntu 10, meme si c’est une version

TLS (Long Term Support) au bout de 4 annees, il est impossible de continuer a

5 NOUBISSI Parfait


faire les mises a jour ce qui peut poser un probleme en terme de securite de qualite,

etc.

2.4 Strategie de mitigation des risques

Le logiciel libre peut etre une tres bonne alternative pour les particuliers et les entre-

prises. Mais comme nous venons de voir dans les points 2.1,2.2 et 2.3, il presente un grand

nombre de risques qu’il faut bien connaıtre avant de commencer a l’utiliser. Nous allons

dans les lignes qui suivent voir comment mitiger ces risques. Ce n’est pas une science

exacte, mais le fait d’analyser les avantages et les inconvenients d’un modele donne une

meilleure comprehension a l’utilisateur, ce dernier peut decider en toute conscience s’il

accepte de prendre le risque ou pas. Un certain nombre de mesures peuvent etre prises

pour mitiger ce probleme :

— Sur le plan legal : Les entreprises souhaitant utiliser les logiciels ou les librairies

open sources doivent mettre sur pied un ensemble de processus qui guident les

developpeurs (ou les utilisateurs) et les aident a se conformer aux licences open

source. L’une des premieres etapes qu’il faut aborder c’est la sensibilisation. Ainsi,

tous les developpeurs impliques dans le processus doivent suivre une formation

leur expliquant les differentes categories de licences open sources. Il est vrai qu’il

en existe une quantite importante de licences open source, mais sans forcement

expliquer de facon detaillee toutes les licences, il faut que chaque developpeur ai

connaissance des grands groupes de licences et les consequences possibles lorsque

ceux-ci ne sont pas utilises conformement a la licence open source. D’un autre

cote, il doit y avoir une personne de reference qu’ils peuvent contacter en cas de

doute. Finalement, il faut faire regulierement un audit des composants open source

de facon a faire un examen de conformite et des risques lies a l’utilisation de ces

logiciels. Pour eviter un audit subit et douloureux, il faut un audit proactif et

regulier.

— La securite est un element important des logiciels (ou des libraires). Il est donc a

juste titre important de prendre en compte les aspects securitaires pour le choix

d’une application open source. En effet, que ce soit pour l’entreprise ou pour un

particulier, l’utilisateur doit commencer par faire d’importantes recherches. Les

logiciels libre et gratuit n’ont pas de support comme les versions payantes. Ce-

pendant, les applications open sources dignes de ce nom ont une communaute

importante. Il faut donc que l’utilisateur fasse des recherches en amont : aller sur

forum chercher les commentaires des utilisateurs, car c’est grace a cela que l’utili-

sateur peut savoir si le programme est suffisamment securise ou non. Une fois que

le l’application est choisie et en tenant compte de tous les principes cites ci dessus,

il faut definir un ensemble d’actions qui doivent etre prises en cas de detection

6 NOUBISSI Parfait


d’une intrusion. En effet, malgre toutes les mesures de securite mises en place,

on ne peut pas garantir que le systeme est sur a 100 %, par consequent, il faut

etre pret a sauver les meubles. C’est a dire effectuer une suite d’operations d’ur-

gences (debrancher le cable de connexion reseau par exemple), avant d’informer

une personne responsable designee a l’avance.

— Mise a jour de l’application : Lorsqu’une nouvelle faille de securite est detectee,

la communaute s’efforce a mettre sur pied un patch pour fermer la breche. Il est

donc important au niveau de l’utilisateur d’appliquer le plus rapidement possible

les mises a jours de securite.

— Sensibiliser les utilisateurs : La sensibilisation est un element important pour la

securite. Il est donc question d’avoir au sein de l’entreprise des seances de forma-

tion des collaborateurs au cours desquelles ils sont sensibilises sur les enjeux de la

securite, et les premiers reflexes a prendre en cas d’attaque.

2.5 Techniques et outils

Selon une etude menee par Jeff Williams (vous pouvez voir ici : the-unfortunate-

reality-of-insecure-libraries ), 88 % du code dans les applications developpees de nos jours

vient de parties tierces. Ce qui veut dire que nous pouvons garantir seulement 12 % du

code que nous developpons. Le reste de code provenant de tierces parties doit donc etre

controle rigoureusement avant d’etre insere dans notre application. Il faut donc trouver les

strategies et les outils pour faciliter ce travail. Nous allons etudier d’une part la technique,

d’autre part les outils necessaires pour accomplir cette tache.

— Techniques : il existe plusieurs techniques d’analyse et de modelisation de risques.

Nous allons dans cette partie de notre travail nous interesser a celle de Microsoft.

On l’appelle Microsoft Threat Modeling Process. Il faut noter que le plus

important n’est pas la methode, mais le fait d’en avoir une qui soit suivie a l’echelle

de l’entreprise. La methode de Microsoft est simple a adopter par les intervenants

du processus de developpement (designers, developpeurs, examinateurs de code, et

bien sur l’equipe responsable de la securite). La modelisation est un element impor-

tant dans le processus de developpement d’applications. La methode de Microsoft

se resume en cinq etapes :

1. Identifier les objectifs de securite. Afin de permettre a tous les responsables de

l’equipe de developpement de bien les comprendre, il convient de les decomposer

en plusieurs categories.

— Identite

— Financier

— Confidentialite et reglementation.

— Garantie de disponibilite.

7 NOUBISSI Parfait

https://www.aspectsecurity.com/research-presentations/the-unfortunate-reality-of-insecure-libraries

https://www.aspectsecurity.com/research-presentations/the-unfortunate-reality-of-insecure-libraries


2. Enqueter les demandes ;

3. Decomposer les demandes ;

4. Identifier les menaces ;

5. Identifier les vulnerabilites

— Outils

1. Produits commerciaux. Il existe plusieurs outils permettant d’analyser le code

open source, blackduck et whitesource sont les plus interessants. Whitesource

est un produit commercial et dispose d’une version gratuite. Le produit est vrai-

ment tres bien fait il possede une tres belle interface graphique. L’application

se met a jour automatiquement en fonction de l’evolution des vulnerabilites. Il

peut aussi faire des recommandations. Blackduck est aussi un produits com-

mercial avec une version d’evaluation gratuite. Je n’ai pas eu le temps de le

tester. De ces deux produits commerciaux, whitesource semble avoir plus de

communaute que blackduck.

2. Produit open source : Pour les produits open source, j’ai trouve retirejs

et nsp. Retire est utilisable en ligne de commande, mais aussi dans un pro-

gramme. Alors que nsp semble seulement disponible en ligne de commande.

8 NOUBISSI Parfait


3 Specifications fonctionnelles

3.1 Cas d’usage

Pour montrer le fonctionnement de l’application sous un autre angle, nous allons uti-

liser un diagramme de sequences afin de montrer un exemple d’utilisation de l’application

dans lequel toutes les couches de l’application sont traversees. Il est vrai que certaines des

choses qui vont etre dites ici l’ont deja ete, mais l’idee ici c’est d’avoir une vision globale

et non des bouts d’explication comme dans les autres parties.

Figure 1 – Diagramme de sequence de l’application

Lorsque l’application demarre, il y a quatre containers qui tournent en permanence

(ElasticSearch, Kibana, Angularjs, controleur).

— L’utilisateur peut alors utiliser son navigateur et acceder a angularjs sur le port

4000.

— L’utilisateur entre alors son repos et soumet la requete.

— La requete est envoyee au Controleur de l’application.

9 NOUBISSI Parfait


— L’API envoie une reponse asynchrone, demarre le crawler et lui passe les donnees

de l’utilisateur(url du repos, le speed qui est le nombre de process qu’il veut pouvoir

lancer en meme temps, et la branche du repos).

— Le crawler va rechercher la package.json sur Github

— Il envoie le nombre ( POST ) de dependances aux controleur qui renvoie a son tour

au navigateur(Ce donnees est utilisees par le navigateur pour tracer la barre de

progression.)

— Le navigateur fait la mise a jour de l’interface graphique (le navigateur ajuste le

pourcentage de progression).

— Le crawler commence alors une boucle dans laquelle il va :

— Utiliser npm-remote-ls pour recuperer la liste des dependances transitives de

chaque module.

— Insere les donnees dans chaque fois qu’il recupere avec succes les dependances

d’une application, il envoi un message ok a l’interface graphique pour que celle-

ci mette a jours la barre de progression.

— Une fois ceci termine, il fait exactement la meme chose pour les licences.

— Lorsqu’il finit de traiter toutes les dependances, il envoie le graphe et les dependances

a la base de donnees pour le stockage a elasticSearch pour le sauvegarder et envoie

un message ”OK” a l’interface graphique.

— La barre de defilement disparait et un message est affiche a l’utilisateur pour lui

informer que les choses se sont bien passees.

— Une fois toutes ces donnees inserees correctement, le navigateur peut desormais

envoyer une requete au controleur pour recuperer les informations et les afficher.

3.2 Scenario et presentation de l’interface homme-machine

Dans cette section, nous allons faire une petite demonstration de ce que nous pouvons

esperer en utilisant cette application.

1. l’utilisateur ouvre le navigateur se connecte sur l’application sur le port 4000. Il va

arriver sur la page ”dashboard”. Lorsque l’application est lancee pour la premiere

fois elle ne contient aucune application.

10 NOUBISSI Parfait


Figure 2 – Page d’accueil de l’application(vide)

2. L’utilisateur clique sur le bouton ADD NEW APP et il obtient cette page a

partir de laquelle il peut inserer les donnees de l’application.

Figure 3 – Page d’insertion de donnees

3. Si l’utilisateur entre une url non conforme au format attendu

( https://github.com/:username/:repos), il recoit un message claire que lui

explique quel format il veut.

11 NOUBISSI Parfait


Figure 4 – Page d’insertion des donnees

4. L’utilisateur entre une ulr d’un repos Github correct et clique sur ”choose a branch”(la

branche master est choisie par defaut) :


12 NOUBISSI Parfait


Il s’agit de la liste de toutes les branches que compte ce repos Github.

5. L’utilisateur peut selectionner une branche et selectionner aussi le nombre de pro-

cessus qu’il souhaite pouvoir executer en parallele sur son application en choisissant

un nombre(1 a 50).


A tout moment, l’utilisateur peut annuler la l’action en clique sur le bouton ”Can-

cel”

6. L’utilisateur clique sur le bouton ”submit” : on peut voir une barre de progres-

sion qui indique l’etat d’avancement du chargement de l’application. Il affiche le

pourcentage de chargement deja effectue. Ce pourcentage est mis a jour au fur et

a mesure que l’application charge de nouvelle dependances.

13 NOUBISSI Parfait



7. Une fois que toutes les dependances sont chargees, le bouton d’annulation est

deactive (nous avons choisi de deactiver ceci parce que lorsque l’utilisateur a deja

charge les dependances dans la base de donnees, nous considerons que les licences

le sont aussi).

14 NOUBISSI Parfait



8. Une autre barre de chargement apparait pour montrer le chargement des Licences.


9. Lorsque tous les chargement se terminent avec succes. Un toast affiche un message

15 NOUBISSI Parfait


indique que le chargement s’est termine avec succes.


10. Voici un echantillon d’applications ayant toutes les trois licences.

Figure 11 – Page d’accueil avec les donnees

16 NOUBISSI Parfait


11. On peut visualiser le graphe de dependance en cliquant sur une application. Dans

ce graphe de dependances, la couleur de chaque nœud du graphe depend de la

licence du module represente par le nœud( rouge pour GPL, orange pour LGPL et

vert pour les autres )

Figure 12 – Page de visualisation des donnees

Sur cette exemple on peut voir a gauche un graphe de dependance dessine avec la librairie

d3. A droite, la liste des dependances avec un peu plus de descriptions. Dans la zone de

texte a droite l’utilisateur peut filtrer le dependances par type de licences : exemple s’il

entre MIT, l’application affiche tous les packages ayant un licence GPL.

17 NOUBISSI Parfait


4 Architecture

Afin de pouvoir bien implementer notre application, il est important de mettre sur pied

une architecture qui detaille ses composants essentiels. Cette architecture nous permet de

visualiser l’ensemble des elements de notre application et les interactions que ceux-ci

entretiennent entre eux.

4.1 Architecture de haut niveau

L’architecture d’une application peut etre faite de differentes facons. Il est important

de rester coherent, mais l’utilisateur a en general la liberte de faire une architecture en

fonction de ses gouts personnels.

Figure 13 – Architecture de l’application

Le cahier de charges nous impose un certain nombre de composants :

1. Elasticsearch

2. Kibana

3. Angularjs

4. Controler (qui expose une API)

5. Crawler

18 NOUBISSI Parfait


4.2 Roles des composants

Nous allons dans les lignes qui suivent decrire les differents composants de notre ap-

plication, en donnant leurs roles dans l’architecture general, pourquoi ces composants ont

ete choisis et quelles sont les alternatives.

1. Elasticsearch :

— C’est quoi Elasticsearch ? : Selon Wikipedia, Elasticsearch est un moteur de

recherche base sur Lucene. Il fournit un moteur de recherche en texte integral

distribue et multitenant avec une interface Web HTTP et des documents JSON

sans schema. Il est developpe en Java et est distribue en tant que source libre

sous les termes de la Licence Apache. Il est le moteur de recherche d’entreprise

le plus populaire suivi par Apache Solr, egalement base sur Lucene

— Role : Dans notre architecture, Elasticsearch permet de stocker les donnees. Plus

precisement, il stocke les donnees permettant de creer les graphes de dependance

(il s’agit en realite d’objets JSON avec une structure particuliere) une fois que

ceux-ci ont ete construits par le crawler (agent d’indexation). L’application web

peut alors en temps voulu faire des requetes sur Elasticsearch pour recuperer

les donnees permettant de construire les graphes. Il est implemente dans un

container docker et expose le port 9200.

— Pourquoi Elasticsearch ? Dans notre projet nous avons choisi d’utiliser Elas-

ticsearch parce qu’il a ete impose par le cahier des charges. Cependant, Elas-

ticsearch est une base de donnees nosql qui propose un certain nombre de

fonctionnalites non negligeables :

(a) c’est une base de donnees du type nosql, ce qui dans le contexte de notre

application facilite le stockage et la recherche des donnees ;

(b) Il met a disposition une API RESTFUL permettant d’acceder aux donnees.

De cette facon, il devient facile d’interagir avec la base de donnees en utili-

sant les methodes HTTP standards. Ceci peut etre fait depuis l’application

ou depuis un outil tels que postman 1.

— Quels sont les autres alternatives ? Bien que l’application soit faite en utilisant

Elasticsearch, il faut signaler qu’on peut le faire en utilisant d’autres systemes

de stockage de donnees : SQL(npm met a disposition un package ”sql” qui fait

des requetes sql), mongobd (Il est generalement tres courant en nodejs d’utiliser

mongobd comme base de donnees.), un fichier (un fichier peut etre une alter-

native interessante lorsque nous ne voulons pas installer d’autres applications

pour gerer la base de donnees).

2. Kibana

1. Postman permet d’interagir avec les API RESTFUL, de concevoir, construire, tester, documenteret surveiller vos services, tous en un seul endroit

19 NOUBISSI Parfait


— C’est quoi Kibana ? : Kibana est un outil open-source dedie a la restitution

et l’analyse de donnees en temps reel et qui fonctionne exclusivement avec

ElasticSearch

— Quel est son role ? : Dans notre application, kibana permet a l’utilisateur lors-

qu’il le souhaite d’explorer les donnees qui ont ete stockees dans la base de

donnees. Ceci permet de voir les graphes sous un autre angle (le graphe peut

etre vu aussi depuis l’application Angularjs), de faire des recherches et de com-

parer dans une certaine mesure les graphes les uns au autres. Il est implemente

dans un container docker et expose le port 5601.

— Pourquoi l’avoir choisi ? : Kibana a ete impose par le cahier des charges. C’est

un bon outil de visualisation de donnees stockees dans Elasticsearch.

— Quels sont les alternatives ?. Il y a peu d’outils permettant de faire aussi

bien que kibana. Mais pour l’exploration des donnees ElasticSearch, il y a

des alternatives telles que postman(Permet de faire les requetes sur notre

API), http://grafana.org/ (Au meme titre que Kibana, il permet d’explorer les

donnees ElasticSearch et de construire des graphes. Je n’ai pas eu le temps de

faire des tests sur cet outil, mais il parait tres bien concu et les critiques sont

plutot positives)

3. API

— C’est quoi API ? C’est une application ecrite en nodejs qui ecoute sur le port

7000.

— Quel est le role de API ? Dans notre architecture, il permet l’interaction entre

l’interface graphique et le reste de l’application : depuis l’interface graphique, on

peut lancer la tache de crawling a travers l’API. De la meme facon, lorsqu’une

tache de fond est entrain de s’executer, l’API permet de continuer a avoir les

informations sur cette tache, en envoyant via socket.io, ce qui permet d’avoir

une vision dynamique sur la tache. Concretement, lorsqu’on demarre docker, il

utilise la commande

/var/run/docker.sock:/var/run/docker.sock pour permettre au controler

de se connecte a l’API docker. L’API (Controler) dispose d’une route /contai-

ner et chaque fois qu’il recoit une requete POST sur cette route, il verifie la

methode et effectue l’action correspondante. Il peut s’agir soit de start, ou de

stop. Si c’est un start il lance le crawler en lui passant le lien vers le repos

comme variable d’environnement. S’il recoit POST sur la route /docker ,

c’est un message du crawler en direction de l’interface graphique. Il va donc

utiliser socket.io pour transmettre ce message a l’interface graphique. Si c’est

un stop, il va executer la commande permettant d’arreter le controleur.

— Pourquoi utiliser API ? API fait partie des composants imposes par le cahier

des charges.

20 NOUBISSI Parfait

http://grafana.org/


— Quelles sont les autres alternatives ? Une alternative pourrait etre de supprimer

ce composant, mais l’application deviendrait difficile a suivre.

4. Angularjs

— C’est quoi Angularjs ? C’est un framework JavaScript qui etend le HTML pour

le rendre dynamique. Il permet au developpeur de creer ses propres balises et

est adapte pour creer les single page applications (SPA) ;

— Quel est le role de Angularjs ? Dans notre cas, il est utilise pour creer le front-

end (interface homme-machine). Il recupere les donnees entrees par l’utilisateur

(repose de l’application par exemple) pour transmettre a l’API et il est aussi

responsable de mettre a jour l’interface graphique de l’application chaque fois

qu’il recoit une donnee sur l’evolution d’une tache de fond. Concretement, il

utilise socket.io pour rester en connection ”permanente” avec l’API. Chaque

fois que le crawler commence une nouvelle tache de crawling, il envoie via

socket.io le nombre d’elements a analyser. Dans ce cas, angular va initialiser

une variable a 100/nombre elements il va ensuite afficher a l’utilisateur la barre

de remplissage avec un pourcentage egal a 100/nombre elements. Chaque fois

que le crawler va envoyer un nouvel element, le angularjs va juste incrementer

le pourcentage de + 100/nombre element. Ainsi de suite jusqu’a la fin. Il faut

aussi signaler que tout ceci est execute dans un container. Depuis ce container,

il a une visibilite directe sur les autres containers. Il ecoute sur le port 4000.

— Pourquoi avoir choisi angularjs ? Nous avons choisi l’avant parce qu’il a ete

impose par le cahier de charge. Il faut aussi signaler que angularjs est l’un des

framework les plus utilises pour la creation de page web. Il a une communaute

importante et permet de faciliter de facon considerable la creation de page web.

— Quels sont les autres alternatives ? Pour developper les applications web, il

existe plusieurs framework permettant de le faire. Nous pouvons citer par

exemple :

— djongo

— php

— Ruby on rails

5. Crawler

— C’est quoi crawler ? Le crawler est un container qui execute une application

nodejs, il est en general lancer dynamiquement. Par l’API.

— Quel est le role de Crawler ? Dans notre application il est l’element qui commu-

nique avec les fournisseurs exterieurs comme npm, github. Lorsqu’on lance le

crawler, il effectue un certain nombre de manipulations sur le lien vers le repos

pour obtenir le lien vers le fichier package.json. Ensuite il le telecharge et ex-

trait les dependances de production (ceci est fait par defaut, mais ce comporte-

ment peut etre modifie). Si tout se passe bien, il compte le nombre d’elements

21 NOUBISSI Parfait


(de dependances) et envoie la reponse a l’API qui va la transmettre a l’in-

terface graphique. Il va ensuite faire une boucle sur cette liste. Pour chaque

dependance, il va d’abord envoyer un signal a l’interface graphique (via l’API)

avec le nom de la dependance en question, puis, il va faire la recherche sur la

liste des dependances de cette dependance. Une fois qu’il obtient la liste des

dependances, il va construire un objet json correspondant au type de donnees

acceptees par d3.js qu’il va rajouter dans un tableau. A la fin, lorsque toutes

les dependances ont ete traitees, il envoie alors le tableau final a Elasticsearch

pour le stockage avant de s’arreter.

— Pourquoi utiliser crawler ? Le crawler a ete impose par le cahier des charges.

— Quelles sont les autres alternatives ? Une alternative a l’utilisation du crawler

serait que ces taches soient accomplies par l’API, ce qui ne serait pas coherent

en terme de division du travail et rendrait l’application difficile a suivre.

4.2.1 Agent d’indexation

L’agent d’indexation est un element important de notre application. C’est a lui que

revient la responsabilite d’aller aupres des fournisseurs externes chercher les informations.

Il y a essentiellement deux fournisseurs externes dans notre application :

1. Github : Il met a disposition des developpeurs une api permettant d’acceder au

donnees des projets.

2. NPM : Il met a disposition des utilisateur des outils permettant de retrouver la

listes des dependances transitives d’un module et les donnees des modules (licenses,

issues, nom des auteurs, etc).

Dans notre application, la liste des dependances transitives et utilisee pour construire le

graphe dependances de l’application. Lorsque le crawler est lance, il envoie une requete

sur l’API de Github pour recuperer la liste de dependance de l’application. Dans notre cas

( dans notre projet, nous nous sommes concentre sur les dependances de developpement

des projets nodejs ). Une fois que le fichier JSON contenant la liste des dependances est

telecharger en local, le crawler parse le fichier et extrait la liste des dependances. Par la

suite, il envoie les requetes pour recuperer les dependances transitives qu’il stocke dans

la base de donnees. Il va egalement parcourir ces dependances pour extraire les noms

de modules qu’il envoie a npm pour recuperer leur differentes licences. Finalement, il va

aller sur Github recuperer les donnees du projet et les envoyer le tout a Elasticsearch

pour le stock. Ces donnees seront utilisee dans le futur pour construire les graphes de

dependances.

22 NOUBISSI Parfait


4.2.2 Modele de donnees et moteur de stockage

Dans notre application, les donnees sont stockees sur Elasticsearch. Elasticsearch est

une base de donnees noSQL. Il permet de creer les donnees en creant dynamiquement les

tables. Dans notre application, il y a essentiellement 3 tables :

1. Les dependances : il s’agit des dependances directes de l’application, c’est-a-dire

les elements dont les noms figurent dans le fichier package.json

2. Les applications : c’est la structure de donnees contenant les informations sur

l’application.

3. Les licences : C’est la structure de donnees contenant les informations sur les

licences.

Lorsque toutes ces donnees sont collectees, elles sont donc stockees dans la base de donnees

ElasticSearch pour un futur usage.

4.2.3 Application et interface homme-machine

L’interface homme machine est construite par une application angularjs. Elle propose

l’ensemble des elements qu’il faut pour permettre a l’utilisateur d’entrer des donnees et

de les soumettre au controleur. L’utilisateur peut y acceder via une page web.

4.2.4 Controleur de l’application

Le controleur de l’application est une application nodejs qui publie une API RES-

TFUL permettant de recevoir les donnees de l’utilisateur, de les traiter et de renvoyer

un resultat. Il peut acceder aux donnees stockees sur ElasticSearch. Il est le seul avec

kibana capable de lire les donnees stockees sur ElasticSearch. Il est le seul intermediaire

que possede l’utilisateur pour acceder au donnees. C’est a lui que revient aussi la respon-

sabilite de lancer le crawler. En effet, lorsque l’utilisateur fait une demande d’indexation,

le controleur va alors demarrer une instance de crawler pour cette tache. Si en cours de

route l’utilisateur veut stopper cette tache, il peut toujours envoyer un message stop pour

arreter le processus.

4.2.5 Exploration des donnees via Kibana

Kibana permet la visualisation des donnees stockees sur ElasticSearch et de tracer les

graphes correspondants. Il est accessible via le navigateur web sur lequel l’utilisateur peut

specifier une requete.

4.2.6 Github

Github stocke les projets et publie une API RESTFUL permettant d’y acceder. Lors-

qu’une tache d’indexation commence, le crawler envoie des requetes a Github pour recuperer

23 NOUBISSI Parfait


la liste des dependances(cette liste de dependance est stocker dans le fichier appeler pa-

ckage.json). De la meme facon, lorsque l’utilisateur entre le repos qu’il souhaite analyser,

l’utilisateur envoie a son tour une requete a Github pour recuperer la liste des branche

afin que l’utilisateur puisse choisir la bonne branche.

4.2.7 NPM (Node Package Manager)

NPM publie plusieurs API RESTFUL permettant d’acceder aux donnees. Lorsqu’une

tache d’indexation est initiee, le crawler envoie des requetes d’une part pour recuperer les

listes des dependances transitives d’un package, et d’autre part la liste les licences pour

chaque package.

4.3 Infrastructure de developpement et d’execution

Le developpement et l’execution de l’application sont faits dans des containers docker.

Il y en a 4 qui sont lances en meme temps des que l’application demarre, et un qui est lance

uniquement lorsqu’on a besoin de ses services. Il faut preciser que lorsque que l’application

sera completement terminee, il pourra alors lancer plusieurs application en parallele.

— Angularjs : C’est une application standard angulars. Le squelette de base a ete

genere automatiquement avec angm. Par la suite. Par la suite, il a ete adapte pour

correspondre a mes besoins.

— Api : api est la partie de mon application capable de demarrer le crawler. Lorsque

l’api recoit le signal, il lance le crawler en lui passant le repos de l’application qu’on

souhaite analyser. Pour faire ce travail il utilise dockerode,

4.4 Docker

Comme decrit dans la section precedente, docker est une application qui met a dispo-

sition un environnement et tous les systemes de fichiers necessaires a l’execution du code.

Il s’agit d’un outil tres puissant. Nous allons exploiter cette puissance pour construire

mon application. Tous les composants essentiels (elasticSearch, Kibana, API RESTFUL,

l’application angularjs, et bien entendu le crawler) de l’application tournent dans un

container different. Docker ayant une communaute importante, on trouve facilement des

images construites pour chacun de ses elements.

Note

- Un container est une instance d’une image qui en est cours d’execution.

-Une image est un template permettant de creer l’environnement dans lequel nous sou-

haitons executer notre code.

-Dockerfile est un fichier texte contenant les etapes permettant de creer l’environnement

que nous voulons.

24 NOUBISSI Parfait


Comment fonctionne docker ?

Docker fonctionne sur le meme principe que les machines virtuelles standards (virtual-

box, vmware pour les plus connues) : la machine hote cree un environnement dans lequel

elle simule une machine physique. Le code normalement execute par la machine physique

est alors execute par l’hyperviseur qui donne l’impression a la machine virtuelle d’avoir

toutes les ressources a disposition et la machine guest ne peut jamais ”savoir” qu’elle

est executee dans un environnement virtuel. En general, les machines virtuelles installent

toutes les dependances (noyau, systeme de fichier ...) qu’il faut pour faire tourner le guest 2,

alors que docker se contente d’installer le stricte minimum et utilisent au maximum les

ressources de la machine host 3. Docker utilise par exemple le meme noyau Linux que la

machine host, de cette facon, cela evite d’installer un noyau pour chaque machine d’ou

un gain d’espace de stockage. Si l’utilisateur veut effectuer les taches particulieres, comme

par exemple installer une application, il faut mettre la commande permettant d’installer

l’application en question dans un fichier appele Dockerfile. Toutes les commandes conte-

nues dans ce fichier sont executees lors de la construction de l’image. Une fois qu’une

image est construite, elle peut etre dupliquee a l’infini pour executer du code. Docker

permet aussi de manipuler une machine virtuelle(start, stop, build, inspect, ...) depuis un

autre programme. Pour ce faire, il met a disposition API restful sur laquelle l’utilisateur

peut passer des commandes. De cette facon, je peux demarrer un container a distance, ce

qui est particulierement interessant pour scaller une application par exemple. En general,

au lieu d’utiliser cette API en passant les commandes manuellement, on utilise un pro-

gramme qui fait les choses pour nous. Nodejs met a disposition un nombre important

de packages a cet effet. Le professeur m’a conseille d’utiliser ”dockerode” je l’ai teste et

je l’ai adopte. Lorsque une application est constituee par un ensemble de containers, il

est fastidieux de lancer les elements les uns apres les autres. Pour remedier au probleme,

il existe un utilitaire associe a docker appele docker-compose. Il permet de configurer

et d’executer plusieurs containers en une seule commande (en generale la commande est

docker-compose up [options])

Comment sont crees et geres mes containers ?

Comme vous pouvez voir mon application a plusieurs containers, chaque container ayant

une tache specifique. Pour trouver le bon container pour chaque tache, je suis alle sur le

site https://hub.docker.com/, afin de trouver des images deja precompilees qui correspon-

daient a mes attentes. Une fois que je trouve la bonne image, je l’ajoute dans le fichier

Dockerfile . C’est en general la premiere commande a etre ajoutee dans le Docketfile.

Pour que le nom de l’image soit interprete comme tel par le demon qui execute docker, il

faut preceder le nom de l’image par une commande. En effet, il existe une multitude de

commandes pour diverses taches. Nous pouvons faire le tour de quelques unes :

2. machine executee dans une autre machine3. machine ayant acces direct a la machine physique

25 NOUBISSI Parfait

https://hub.docker.com/


— FROM : Cette commande permet de specifier l’image que nous souhaitons utili-

ser : exemple FROM node:6.9 veut simplement dire que nous voulons une image

contenant node 6.9 (il faut a l’avance s’assurer que cette image existe sur

https://hub.docker.com/) ou sur la machine locale. En effet, lorsque le demon do-

cker execute cette commande, il va d’abord chercher si une image existe sur la

machine locale correspondant au nom ”node :6.9” (vous pouvez voir la liste des

images existantes sur la machine locale en utilisant la commande docker images

depuis un terminal). Si l’image n’existe pas en local, le demon ira chercher en ligne

et lorsqu’il la trouve, il va donc la telecharger en local.

— ADD Cette commande permet de copier un fichier/dossier de la machine locale

vers le container : exemple : ”ADD . .” permet de copier le fichier dans lequel se

trouve le Dockerfile vers le dossier de travail sur le container (en general sur le

container c’est /root)

— RUN Permet d’executer une commande dans la machine qu’on construit : exemple

RUN apt-get update executera la meme commande sur la machine. Il faut signaler

que par defaut l’utilisateur du container est le root.

— CMD Permet de specifier la commande qui sera executee lorsque le container

est lance : exemple CMD grunt dev permet d’executer la commande ”grunt dev”

chaque fois qu’une instance du container est lancee.

— EXPOSE Permet de specifier le port que nous voulons exposer : exemple ”EX-

POSE 9200” exposera le port 9200 pour qu’il soit accessible depuis la machine

hote.

— ...

Note :

— Pour les questions d’optimisation, lorsqu’on souhaite executer plusieurs commandes

dans un Dockerfile, il est recommande de les mettre les uns a la suite des autres en

les joignant avec un ”&&”. Ceci fait partie des bonnes pratiques. De cette facon la

commande RUN sera executee moins de fois et sera du coup plus rapide.

— Dans le fichier docker-compose.yml, les nom des fichier correspondent au host-

name 4 des container

4. Ce nom represente l’adresse IP de chaque container au niveau reseaux

26 NOUBISSI Parfait

https://hub.docker.com/


5 Implementation

L’implementation de l’application est l’une des parties les plus importantes du projet.

Elle permet de retrousser les manches et donner vie a tout ce que nous avons imagine et

concu. Nous allons decrire les differentes parties de notre application, expliquer comment

elles ont ete construites, et comment elles fonctionnent.

5.1 Agent d’indexation

L’agent d’indexation appele ”crawler” dans notre projet est la seule partie qui commu-

nique avec l’exterieur. En effet, c’est cette partie de l’application qui doit aller recuperer

les donnees accessibles via internet.

1. Processus : L’agent d’indexation (crawler) est implemente dans une machine do-

cker qui peut etre lance dynamiquement par le controleur qui lui passe un certain

nombre de parametres dont il a besoin pour s’executer(le nom du repos Github, la

branche du repos qu’il faut analyser, la nombre de process qu’il faut en parallele).

L’ensemble de ces fichiers est contenu dans le dossier appele crawler, lui-meme dans

le dossier images. L’image permettant d’executer son code est issue d’une image

node 6.9. Dans le fichier Dockerfile (qui decrit comment l’image sera construite),

on peut voir trois commandes principales :

(a) From node :6.9 Cette commande permet de recuperer une image docker

contenant la version 6.9 de nodejs. Si l’image n’est pas deja disponible locale-

ment dans le systeme, docker va aller sur dockerhub la telecharger.

(b) ADD . . Cette commande permet de copier tous les fichiers contenus dans le

dossier crawler vers la dossier de travail de la machine virtuelle docker.

(c) MAINTAINER comme son nom l’indique, cette commande permet de specifier

le nom de l’utilisateur ayant cree cette image.

(d) RUN npm install permet d’executer la commande npm install. Lorsque la

copie est terminee, ceci permet alors d’installer toutes les dependances permet-

tant d’executer notre application.

2. Algorithmes. Pour faire fonctionner correctement le crawler, il y a un ensemble de

comportements qu’il faut implementer. Pour ce faire nous avons utilise bluebird.

Notre application est typique nodejs. Elle contient essentiellement trois fichiers et

dossiers :

(a) Le dossier node modules qui contient l’ensemble des modules necessaires pour

notre application. Il s’agit essentiellement d’un dossier ou sont stockes les pa-

ckages installes.

(b) Un fichier tools.js qui contient l’ensemble des foncions ecrites pour cette ap-

plication. Il contient les fonctions suivantes :

27 NOUBISSI Parfait


— fetchModule : Permet de recuperer un module et toutes ses dependances

transitives. Il recoit en parametres le nom du module et un callback et

retourne(via le callback) un json contenant le module et ses dependances.

Pour effectuer cette tache, il utilise npm-remote-ls 5.

— insertMultipleModules : Il prend en parametre une liste de modules les insere

dans la base de donnees ElasticSearch et retourne(via callback) un tableau

contenant le statut(si tout s’est bien passe ou pas) de chaque element insere.

Il utilise le package elasticsearch qui est un client Javascript fourni par

ElasticSearch.

— selectNonExistingModulesOrLicenses : C’est une fonction qui prend en pa-

rametre un tableau contenant une liste de JSON contenant chaque module

et un booleen indiquant si le module existe ou pas dans la base de donnees

et fait en suite un filtre pour retourner uniquement les modules n’existant

pas dans la base de donnees.

— insertApplication : Cette methode permet d’inserer une application dans la

base de donnees. Il prend en parametres les donnees d’une application, les

insere dans la base de donnees et retourne un statut indiquant si la donnee

a ete correctement inseree ou non. Cette methode utilise ElasticSearch

— checkIfModuleExists : Cette methode comme son nom l’indique verifie si un

module est present ou pas dans la base de donnees. Elle prend en parametre

un tableau de dependance et retourne un tableau contenant la liste des

modules et un booleen indiquant si les modules sont presents ou pas dans

la base de donnees.

— checkIfModuleLicenseExists : Comme la methode precedente, elle prend en

parametre un tableau de modules et verifie si ceux-ci ont leurs licences dans

la base de donnees. Elle utilise elasticSearch.

— sendMsg : C’est une fonction qui permet d’envoyer une informations a l’in-

terface graphique via le controleur.

— getModuleLicense : C’est une methode qui permet de recuperer la liste et

autres information d’un module donne. Elle prend un module et retourne

un objet json contenant toutes les informations sur le module. Il utilise le

package npmview 6

— insertMultipleLicenses : C’est une methode qui prend en parametres un

tableau de modules et leurs licences et retourne un tableau contenant le

statut de chaque methode.

— getModuleName : C’est une methode qui permet de recuperer la liste des mo-

dules. Elle prendre un parametre un JSON contenant la liste des dependances

5. C’est un package node qui permet de retrouver les dependances transitives d’un module6. C’est un package qui permet de retrouver toutes les informations sur un module donnee

28 NOUBISSI Parfait


transitives et retourne un tableau contenant toutes les dependances.

(c) Le fichier app.js est le point d’entree du crawler(agent d’indexation). Lorsqu’il

est lance par le controleur, le crawler utilise le module request-as-promise 7

pour aller recuperer le fichier package.json contenant la liste de toutes les

dependances. Dans le ’then’ associe, ce fichier est parse pour obtenir la liste des

dependances(nous nous interessons au dependances de developpement). Lors-

qu’on a la liste des dependances, il faut constituer la dependance proprement

dite. Les dependances sont stockees dans un JSON 8, dont la cle represente

le nom du module et la valeur represente la version du module. Ces deux

sont alors concatenes avec un caractere ’@’ de facon a former une chaine de

la forme nomdumodule@version(exemple [email protected]).(Que ce soit pour

les dependances ou les licences, l’ideal etait de faire de leurs noms leurs IDs dans

la base de donnees. Or leurs IDs comportent des points qui sont des caracteres

interdits dans les IDs pour ElasticSearch(version 2.4). Nous avons alors choisi

de maintenir leurs noms, mais de remplacer les points (’.’) par les underscore

(’ ’) ). Une fois que cette operation est realisee sur chaque module et mis dans

un tableau, il faut alors verifier si chacun de ces element existe dans la base de

donnees. Etant donne que Javascript n’est pas asynchrone, si on lance simple-

ment la tache toutes les dependances seront verifiees une seule fois, ce qui peut

poser un reel probleme de concurrence et generer une erreur, d’autant plus que

nous travaillons dans les conteneurs docker(environnement emule). Il faut donc

trouver un moyen de realiser toutes ces operations les unes apres les autres.

Pour ce faire, il existe un module appele bluebird 9 qui permet d’executer des

operations de facon asynchrone(executer chaque operation une apres l’autre). Il

est assez simple a utiliser : il prend en parametre un tableau contenant la liste

des arguments qu’il faut passer a la fonction qu’il faut executer, et le nombre

de fonctions qu’il faut lancer en parallele. Nous utilisons alors la fonction che-

ckIfModuleLicenseExists qui nous retourne un tableau contenant la liste des

modules et leurs statuts(existe ou pas). Par la suite, nous utilisons la fonction

selectNonExistingModulesOrLicenses qui nous retourne un tableau des modules

qui n’existent pas. Si tous les modules existent, alors toutes les licences aussi

(d’apres le fonctionnement de l’application, lorsqu’on insere un module on insere

aussi sa licence ). Dans ce cas on retourne un tableau vide au processus suivant.

De cette facon tous les processus suivants retourneront un tableau vide sauf le

dernier qui va inserer les donnees dans la base de donnees. Cependant si la liste

des modules n’es pas vide, nous allons alors utilise la methode fetchModule()

7. c’est un module npm qui fait une requete HTTP et retourne une promise8. structure permettant de representer les donnees. Pour plus d’informations, vous pouvez aller sur

json.org9. http://bluebirdjs.com/docs/getting-started.html

29 NOUBISSI Parfait

http://bluebirdjs.com/docs/getting-started.html


pour recuperer la liste de toutes les dependances transitives de chaque module.

Pour eviter de saturer le reseau et creer ainsi une ”famine” entre les differents

processus qui veulent acceder de facon concurrente a l’API de npm, nous allons

comme dans le cas precedent utiliser bluebird. Nous allons ainsi lui passer le

tableau de toutes les dependances (modules), ainsi que notre fonction et un

entier representant le nombre de concurrences que nous voulons tolerer. Nous

allons recevoir dans la partie suivante un tableau contenant la liste de tous

les modules et leurs dependances transitives. Nous allons donc faire appel a la

methode insertMulipleModules pour inserer tout cela dans la base de donnees.

Nous utilisons aussi la fonction getModuleName pour parser l’objet JSON recu

et extraire la liste de tous les modules. Il faut chercher tous les modules dont la

licence n’est pas dans la base de donnees avec la methode getModuleLicense().

Cette methode retourne un tableau contenant toutes les licences pour chaque

module. Ces donnees sont alors inserees dans la base de donnees avec la methode

insertMultipleLicenses(). Une fois que les licences et dependances sont inserees

dans la base de donnees, on utilise request-as-promise pour chercher les infor-

mations sur le repos(nom de l’utilisateur ayant cree le repos, sont avatar, la

description du projet) et on utilise insertApplication pour inserer l’application

dans la base de donnees.

5.2 Elasticsearch

ElasticSearch (version 2.4) et kibana (version 4.5) comme nous avons decrit sont deux

modules qui tournent dans des container docker. Dans le fichier de configuration de docker-

compose.yml (qui definit comment les differents container interagissent entre eux au ni-

veau reseaux), ElasticSearch est configure avec un nom elasticsearch, de meme que

kibana qui est configure avec le nom kibana. De cette facon on peut utiliser ces deux

hostname comme les adresses IP. ElasticSearch est un outil assez complet. Il met a dis-

position un API RESTFUL permettant d’interroger les donnees. Nous avons trois types

de donnees :

1. Les applications : elles sont representees par une structure de donnees contenant :

— Index qui est l’index de l’application. On peut aussi voir ca comme le nom d’une

table dans les bases de donnees classiques. Le nom de l’index est applications.

— un type : il s’agit d’un indice supplementaire dont le but est d’inserer plusieurs

types de donnees sous le meme indice. Le nom du type est apps

— published at : est un champ contenant une date dans un format bien precis

(”YYYY-MM-DDThh :mm :ss+0000”). Ce champ est utilise par kibana pour

afficher les graphes, il permet en fait de savoir quand est-ce que les donnees ont

ete inserees, ce qui permet d’avoir une reference supplementaire pour rechercher

30 NOUBISSI Parfait


les donnees. Ce champ est genere par le package moment.js 10

— name : representant le nom donne au repos (il est obtenu a partir des donnees

telechargees de Github)

— url qui represente l’url du repos Github(il est obtenu de l’utilisateur)

— Application : represente la liste de toutes les dependances directes de l’appli-

cation. Il s’agit d’un tableau contenant la liste des dependances directes de

l’application, les dependances transitives etant stockees dans un autre tableau

— Description : qui est la description de l’application. Ce champ est obtenu de a

partir des donnees telechargees sur Github

— Avatar qui represente un champ contenant le lien vers l’avatar de l’utilisateur

ayant cree le package.

— Un ID qui est constitue du nom de l’utilisateur, du nom du repos et du nom

de la branche, le tout relie entre eux par des underscore (’ ’)

2. Licences : elles sont representees par une structure de donnees contenant :

— l’index : l’index pour les licence est licenses

— Le type pour les licences est cr (copyright)

— une ID qui est represente par le nom du module accompagne de sa version(les

points dans la version sont remplaces par les ’ ’)

— Un champ data contenant la liste des informations sur le module.

3. Dependancies contient des champs assez similaires au deux autres :

— un champ index dont la valeur est Dependancies

— Un champ type dont la valeur graph

— Un champ ID dont la valeur est le nom du module concatene avec la version du

module par un caractere ’@’ un champ qui contient un JSON de dependances

transitives de l’application.

5.3 Interface Homme Machine

L’interface homme-machine est implemente en angularjs. C’est une

single page application (SPA). Lorsqu’on lance le navigateur, la page par defaut est

la page dashboard sur cette page, il y a trois elements principaux. Nous avons choisi de

faire l’interface homme-machine completement en anglais afin de conserver une certaine

coherence et le rendre plus professionnel.

1. En haut a gauche, il y a un element graphique dont le titre est RISKS. Il possede

trois tabulations. Il affiche le nombre d’applications analysees, le nombre de dependances

et le nombre de module correspondant, il permet aussi d’afficher la liste de toutes les

dependances rencontrees dans notre application. Les onglets quality et security

ne sont pas encore implementees.

10. moment.js c’est un package node qui permet de generer les data et l’heure sous differents formats

31 NOUBISSI Parfait


2. En haut a droite, il y a un doughnut chart qui affiche sous forme graphique le

pourcentage des differentes categories de licence. On peut differencier trois types

de licence : les licences permissives (qui donnent tous les droits a l’utilisateur

de reproduire de transmettre et d’utiliser sans aucune contrainte, comme MIT,

Apache, open bsd, ...). Les licences faiblement permissives comme LGPL(donne le

droit a l’utilisateur de faire toutes sorte d’utilisation a condition de rendre public les

modifications effectuees sur les code source du produit en question), et les licences

GPL( qui obligent l’utilisateur d’un code open source a publier tous les modules de

l’application utilisant du code open source, y compris le code proprietaire). Etant

donne que ces trois categories sont assez representatives de tout l’ecosysteme des

licences, nous nous sommes limites a ces trois. L’element graphique en haut a droite

nous donne donc les proportions de chacun de ces grand types de licences sur les

licences que nous avons analysees. Sur la legende se trouvant a droite, on peut voir

les proportions exactes de chacun des ces types de licences.

3. En bas de ces deux elements deja cites, il y a un autre element graphique qui couvre

toute la largeur de la page. Dans l’entete de cet element graphique, on peut voir un

titre (application), un champ texte permettant de filtrer la liste des applications, un

texte indiquant le nombre d’applications selectionnees, et un bouton ADD NEW APP

permettant d’aller dans l’onglet qui permet d’ajouter une nouvelle applications. A

l’interieur de cet element graphique, sont affichees les applications une fois quelles

ont ete analysees. Tout a gauche se trouve l’avatar de l’utilisateur(c’est une image

telechargee sur Github). A droite de l’avatar on peut voir le username, le nom du

repos, la branche analyser, et la description du projet. En allant vers la droite,

on peut voir tour a tour la date de l’ajout de l’application, une icone qui indique

le statut de l’application (elle peut etre de couleur rouge dans le cas ou il y a

un des modules ayant une licence GPL : on parle d’effet contaminant, voir partie

theorique. Elle peut aussi etre orange : effet contaminant aussi dans le cas ou il y

a un module ayant une licence LGPL, ou verte dans tous les autres cas. Il est ici

question de signaler la licence la plus contraignante). Tout a droite, il y a le nom

de la licence sous la forme textuelle. Cette licence peut etre interpretee comme la

licence de l’application, car dans l’analyse, on choisi la licence la plus contraignante.

Il y a egalement trois categories a savoir GPL, LGPL, FREE(toute les licence qui

ne sont ni GPL, ni LGPL).

Au niveau de HTML, nous utilisons bootstrap 11 pour rendre les pages web presentables.

Lorsque les donnees des applications sont recues depuis le controleur 12 web du dashboard,

11. Vous pouvez regarder ici pour plus d’informations sur bootstrap :https://en.wikipedia.org/wiki/Bootstrap(front− endframework)

12. concept lie a Angularjs qui designe une fonction permettant de passer des donnees aux variableshtml des pages

32 NOUBISSI Parfait

https://en.wikipedia.org/wiki/Bootstrap_(front-end_framework)


elles sont parsee et envoyees dans une variable globale appelee ($scope), et depuis le niveau

html, ces variables sont affichees.

5.3.1 Cas particulier de D3.js

L’implementation du graphe de dependance est faite avec le framework d3.js pour plus

d’information voici le site officiel https://d3js.org/. Pour notre application nous avons

choisi de le faire avec un graphe ayant des noeuds relies les uns au autres. Lorsqu’une

application est selectionnee, sont id est envoye au controleur. Ce dernier retourne un

graphe contenant la liste de toutes les dependances transitives de notre application. Il faut

alors construire le graphe de dependances a partir de toutes ces donnees. Nous utilisons

un objet JSON pour representer ces donnees. L’idee c’est d’avoir pour chaque nœuds la

liste de toutes les dependances directes de ce nœud (on les appelles les enfants : ”children”

en anglais). Le noeud racine a pour nom le nom de l’application. Chaque nœud a une

cle et une valeur. Les nœuds n’ayant pas d’enfants ont un nom (le nom du module) et

une taille, alors que les nœuds ayant des enfants ont un nom et la liste de leurs enfants.

Toute cette structure de donnees permettant de representer le graphe doit etre generee

dynamiquement a partir des donnees de l’application. Une fonction appelee ”tree” dans

notre application permet de generer cette structure de donnees. Une fois que toutes ces

donnees sont transformees pour representer fidelement les dependances entre les differents

modules, on utilise alors les fonctions d3 pour representer les lien ronds qui representent

les modules et les lignes qui representent les relation entre ces modules. En suite on specifie

la zone dans laquelle cette donnee doit etre representee. Une fois que toute ceci est fait,

nous avons une representation graphique de nos dependances. En fonction du nombre de

dependance que possede notre application, il peut arrive que l’ecran (la zone destinee a

accueillir toutes notre graphe) soit totalement saturee au point ou il n’est plus possible

de distinguer les choses. Pour resoudre ce probleme, nous parcourons tous les nœuds et y

inserons le niveau (le niveau d’un nœud c’est sont eloignement par rapport a la racine).

Une fois cette tache effectuee, nous creons une methode ”toggle”. Dans cette methodes

nous deplacons les enfants du noeud vers une autre variable (” children”) ce fait en sorte

que ce nœud ne soit pas affiche. Une fois que tout ceci est mis en place et fonctionne

correctement, lors de l’affichage, lorsque le nombre de nœuds a afficher est atteint, nous

masquons donc les enfants, ce qui donne l’impression que le nœuds ayant des enfants n’en

a pas. Mais lorsqu’un nœud est ferme, on peut toujours cliquer sur ce lui pour l’ouvrir

dans ce cas on fait l’action inverse a celle qui a ete faite dans toggle.

Chaque nœud a aussi un nom. Lorsqu’un nœud a des dependances, celles-ci sont

representees sous la forme d’un tableau de dependance directes. Toute la structure est un

object JSON a chaque niveau,

33 NOUBISSI Parfait

https://d3js.org/


5.4 Extraction des donnees via l’API

Lorsque toutes les donnees sont inserees, l’utilisateur peut avoir envie de les exploiter

via l’API RESTFUL. Le controleur est une application nodejs qui publie une API RES-

TFUL permettant d’acceder aux donnees. Ce controleur est dans un dossier appele api.

Dans ce dossier, il y a un ensemble de fichiers et dossiers :

— tools.js : contient l’ensemble des fonctions que nous souhaitons utiliser dans cette

application.

— getXXXDependencies : permet de recuperer un ensemble de dependances

dont les IDs sont passes en parametres.

— getXXXLicenses : permet de recuperer un ensemble de licences dont l’ID est

passe en parametre.

— getOneApplication : permet de recuperer une application dont l’ID est passee

en parametre.

— getAllApplications : permet de recuperer l’ensemble de toutes les applica-

tions.

— getModuleName : permet de recuperer une liste de modules a partir d’un

arbre.

— app.js : Dans cette partie, socket.io est utilise pour permettre une connexion

live entre l’interface homme-machine et l’application. Ceci est particulierement

interessant lorsqu’on doit annoncer a l’interface graphique l’etat d’avancement

d’une tache en cours. Typiquement lorsque l’utilisateur fait une demande d’in-

dexation, il y a plusieurs etapes et a la fin de chacune des etapes le crawler fait un

post a l’api qui redirige a l’interface graphique via socket.io. Le controleur (API)

ecoute sur le port 7000. Il publie plusieurs endpoint :

1. docker(avec la methode post) : est utilisee pour demarrer ou stopper le crawler.

Lorsque le controleur recoit sur ce endEpoint un post avec le champ method = start,

il lance le crawler en lui passant les parametres url, speed, branch ( ces pa-

rametres sont recus de l’application web ). Pour pouvoir lancer dynamiquement

un container, l’api utilise un module npm appele dockerode 13

2. applications(post) : ce endPoint permet d’acceder a la liste de toutes les appli-

cations. Lorsque l’api recoit une requete sur ce endPoint, il renvoie simplement

la liste de toutes les applications. Comme mentionne dans la partie Elastic-

Search et kibana, l’application n’est rien d’autre qu’une table contenant la liste

des dependances directes. Pour representer les donnees cote utilisateur, il faut

alors faire une requete a la base de donnees pour recuperer l’ensemble de toutes

les applications.

13. dockerode est un module permettant d’executer quasiment toutes les operations docker a distance.Pour plus d’informations consulter ici : https://github.com/apocas/dockerode

34 NOUBISSI Parfait

https://github.com/apocas/dockerode


— Dockerfile

— node modules

il y a un fichier tools.js comme dans le cas du crawler, qui contient l’ensemble des

fonctions que nous allons utiliser dans cette api.

35 NOUBISSI Parfait


6 Erreurs connues

Certains erreurs erreurs existent encore dans notre projet. Lorsqu’on utilisent npm

views pour retrouver les licences des packages, dans le meilleures des cas, les licences sont

stockees dans le champs licence en tant que ”string” (chaine de caracteres). Cependant,

il arrive que certaines licences ne soient pas stockees comme des chaines de caracteres,

mais plutot des tableaux avec une structure de donnees qu’il n’est pas facile d’acceder

avec un algorithme. Il pourrait donc etre judicieux de prevoir pour la prochaine version

de l’application de donner la possibilite a l’utilisateur de modifier le champ licence en lui

fournissant les donnees brutes recoltees avec npmview. De cette facon il peut manuellement

modifier les champs intitule ”No licence” et enregistrer dans la base de donnees, et ensuite

eviter d’ecraser les champs edites.

7 Conclusion

Nous sommes donc rendu a la fin de ce projet au cours duquel il etait question de

construire une application permettant d’analyser des applications open source en nodejs.

L’application devait permettre a un utilisateur d’entrer une url d’un repos github, d’ana-

lyser le repos sur le plan legal, tout ceci de facon automatisee, et fournir les resultats a

l’utilisateur avec le details precis : detecter et signaler les modules sous licence contrai-

gnante telle que GPL, ou LGPL, de presenter les resultats a la fois sous la forme graphique

et textuelle. Il y avait aussi des contraintes quand a l’utilisation de certaines technologie,

elasticSearch pour le stockage des donnees, Kibana pour l’exploration des donnees, l’in-

terface graphique devait etre implementee avec le framework angularjs, le controleur de

l’application avec nodejs. Tous ces elements implementes dans des containers docker, et

permettre d’utiliser docker-compose pour lancer l’application.

L’application que nous avons ecrit au cours de ce travail de Bachelor peut permettre

a l’utilisateur de :

— Entrer un repos Github ;

— Lancer l’analyse du repos ;

— Affiche correctement les resultats des modules ayant une licence contraignante ;

— Presenter les resultats a la fois sous la forme graphique avec d3, et sous la forme

textuelle ;

— L’interface graphique est ergonomique et intuitive ;

Cette plate-forme en l’etat ne peut pas encore etre consideree comme une application a

part entiere, car elle ne fournis pas tous les services. Cependant, elle rempli le cahier de

charge de notre projet d’une part, et d’autre part elle est la preuve de la faisabilite d’une

telle application permettant d’evaluer la qualite des applications open source sur plusieurs

plans. Ce outils a une reelle utilite car, au cours des tests de l’application, nous avons

36 NOUBISSI Parfait


constate que certains applications qui avaient une licence permissive(MIT, Apache, ...)

utilisaient par ailleurs des composants non permissives( GPL et LGPL ), ce qui est un

risque reel en terme de legalite. Une application comme celle-ci, mieux etoffee permettrait

au developpeur de savoir rapidement que son application a des risques securitaires, legaux

ou qualitatifs.

7.1 Roadmap pour l’evolution de la plate-forme

Pour obtenir une plate-forme complete et mettant a disposition toutes les options

necessaires, un certains nombre de taches doivent encore etre accomplies. Nous allons dans

les lignes qui suivent presenter un certains nombre d’elements permettant de poursuivre

ce travail.

7.1.1 Securite

Afin d’ajouter la fonctionnalite ”securite”, nous avons trouve deux packages NPM

permettant d’evaluer la securite d’un repos NPM. nsp ( peut etre trouve ici

https://www.npmjs.com/package/nsp ) et retire.js ( peut egalement etre trouve ici

https://www.npmjs.com/package/retire ) sont deux packages pouvant aider a continuer

ce travail. En effet, ce sont deux outils en ligne de commande qui permettent d’analyser

la securite des packages nodejs. Les tests en ligne de commande ont ete effectues et il

fournissent des resultats corrects avec des CVE qu’on peut verifier en ligne. Afin d’ajouter

la securite a notre application. Nous prevoyons d’utiliser l’api github pour telecharger

le fichier package.json du projet a analyser, en suite utiliser un package npm comme

”command” ( plus d’information ici https://www.npmjs.com/package/command ), pour

executer des commandes et recuperer les informations que nous inserons dans la base de

donnees. Une fois ceci fait il faut ajouter quelques methodes permettant a notre controleur

actuel d’aller rechercher ces elements dans la base de donnees et de les envoyer au client

angulars pour l’affichage.

7.1.2 Qualite

La qualite d’un logiciel est la combinaison de plusieurs parametres comprenant entre

autres la securite et la legalite. Pour evaluer la qualite de notre application. Nous allons au

niveau applicatif combiner la securite et la legalite (et probablement d’autres parametres

a definir) pour en deduire la qualite du logiciel.

7.1.3 Autres plate-forme

Meme si pour ce projet nous nous sommes limites a analyser les packages nodejs, afin

d’avoir un produit complet, il faut aussi inclure les autres plate-forme utilisant les modules

37 NOUBISSI Parfait

https://www.npmjs.com/package/nsp

https://www.npmjs.com/package/retire

https://www.npmjs.com/package/command


open source(maven, Py PI, nuget, RubyGems). Penchons sur le cas de maven. Maven

est un outil de construction de projets (build) open source developpe par la fondation

Apache. Il permet de faciliter et d’automatiser certaines taches de la gestion d’un projet

Java. Il met a disposition de l’utilisateur un certain nombre de package open source (

pour plus d’information https://mvnrepository.com/). OWASP Dependency Check fourni

une methodologie permettant de recuperer les vulnerabilites des dependances maven.

https://www.owasp.org/index.php/OWASPDependencyCheck

38 NOUBISSI Parfait

https://mvnrepository.com/

https://www.owasp.org/index.php/OWASP_Dependency_Check


A Installation manuel

Pour installer cette application, voici les etapes a suivre :

1. Telecharger cette application depuis le repos Github :

git clone https ://github.com/SoftEng-HEIGVD/OpenSourceRiskAnalyzer.git

Figure 14 – Capture clone repos git

2. Aller en suite dans le dossier OpenSourceRiskAnalyzer/code/app/topology et

lancer la commande . docker-compose up

Figure 15 – capture test

3. Lorsqu’on ouvre le navigateur sur le port 4000 on option ceci :

39 NOUBISSI Parfait


Figure 16 – capture test

Table des figures

1 Diagramme de sequence de l’application . . . . . . . . . . . . . . . . . . . 9

2 Page d’accueil de l’application(vide) . . . . . . . . . . . . . . . . . . . . . . 11

3 Page d’insertion de donnees . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Page d’insertion des donnees . . . . . . . . . . . . . . . . . . . . . . . . . . 12







11 Page d’accueil avec les donnees . . . . . . . . . . . . . . . . . . . . . . . . 16

12 Page de visualisation des donnees . . . . . . . . . . . . . . . . . . . . . . . 17

13 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . 18

14 Capture clone repos git . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

15 capture test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

40 NOUBISSI Parfait


16 capture test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

41 NOUBISSI Parfait


B Bibliographie

References

[1] Alan Walter , ”Droit de propriete et Open Source”, 04 fevirier 2004, http://www.

e-juristes.org/Droit-de-propriete-et-Open-Source,165/#nb5

[2] ”Arnaud Jacques, La securite et l’Open Source”, 03 Decembre 2001, https://www.

securiteinfo.com/conseils/opensourcesecurity.shtml

[3] Lilia Tlemcani, ”Propriete intellectuelle - L’open source”, 08

decembre 2011 http://www.lenouveleconomiste.fr/lesdossiers/

propriete-intellectuelle-lopen-source-13091/

[4] Peter Upfold, ”The differences between the GPL, LGPL and

the BSD”, 06 avril 2007 https://fosswire.com/post/2007/04/

the-differences-between-the-gpl-lgpl-and-the-bsd/

[5] Frederic Schutz, ”Logiciel libre et securite”, http://www.clusis.ch/pdf/inforum/

gull_schutz_securite.pdf

[6] Burcin Gercek, ”Securite des logiciels libres : mythes et realites”, http://www.

symantec.com/region/fr/resources/secu_mythe.html

[7] Ismet Geri, ”L’Open Source, toujours des lacunes en securite ?”, 20 oc-

tobre 2015, http://www.journaldunet.com/solutions/expert/62528/

l-open-source--toujours-des-lacunes-en-securite.shtml

[8] Marie Varasson, ”Systeme d’informations, l’open securite”, 18 no-

vembre 2015, http://www.lenouveleconomiste.fr/lesdossiers/

systeme-dinformations-lopen-securite-28860

[9] Kim Weins, ”Best Practices for Open Source Compliance and Governance in Automo-

tive”, novembre 2011 https://events.linuxfoundation.org/images/stories/

pdf/als11_weins.pdf

[10] Pascal Gasser, ”Best Practices for Open Source Compliance

and Governance in Automotive”, 20 aout 2015 https:

//www.kmu.admin.ch/kmu/fr/home/actuel/interviews/2014/

logiciels-libres-presentent-des-atouts-incontestables.html

[11] Gilbert Robert & Frederic Schutz, ”L’entreprise doit-elle adopter les logiciels libres ?”

http://dit-archives.epfl.ch/FI01/fi-sp-1/sp-1-page3.html

https ://www.aspectsecurity.com/research-presentations/the-unfortunate-reality-of-

insecure-libraries

42 NOUBISSI Parfait

http://www.e-juristes.org/Droit-de-propriete-et-Open-Source,165/#nb5

http://www.e-juristes.org/Droit-de-propriete-et-Open-Source,165/#nb5

https://www.securiteinfo.com/conseils/opensourcesecurity.shtml

https://www.securiteinfo.com/conseils/opensourcesecurity.shtml

http://www.lenouveleconomiste.fr/lesdossiers/propriete-intellectuelle-lopen-source-13091/

http://www.lenouveleconomiste.fr/lesdossiers/propriete-intellectuelle-lopen-source-13091/

https://fosswire.com/post/2007/04/the-differences-between-the-gpl-lgpl-and-the-bsd/

https://fosswire.com/post/2007/04/the-differences-between-the-gpl-lgpl-and-the-bsd/

http://www.clusis.ch/pdf/inforum/gull_schutz_securite.pdf

http://www.clusis.ch/pdf/inforum/gull_schutz_securite.pdf

http://www.symantec.com/region/fr/resources/secu_mythe.html

http://www.symantec.com/region/fr/resources/secu_mythe.html

http://www.journaldunet.com/solutions/expert/62528/l-open-source--toujours-des-lacunes-en-securite.shtml

http://www.journaldunet.com/solutions/expert/62528/l-open-source--toujours-des-lacunes-en-securite.shtml

http://www.lenouveleconomiste.fr/lesdossiers/systeme-dinformations-lopen-securite-28860

http://www.lenouveleconomiste.fr/lesdossiers/systeme-dinformations-lopen-securite-28860

https://events.linuxfoundation.org/images/stories/pdf/als11_weins.pdf

https://events.linuxfoundation.org/images/stories/pdf/als11_weins.pdf

https://www.kmu.admin.ch/kmu/fr/home/actuel/interviews/2014/logiciels-libres-presentent-des-atouts-incontestables.html



http://dit-archives.epfl.ch/FI01/fi-sp-1/sp-1-page3.html

Documents

Plate-forme d’ evaluation des risques li es a l