Siwar Benfakhta Rapport VF

République Tunisienne
Ministère de l’enseignement supérieur

et de la recherche scientifique
Université de Tunis El Manar
Institut supérieur d’informatique
Rapport de Stage de Fin d’Études

Présenté en vue de l’obtention de la
Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques
Spécialité : Ingénierie de développement des logiciels
Par :
Siwar BEN FAKHTA
Solution SaaS d’analyse avancée des vulnérabilités

pour les dispositifs IoT
Encadrant professionnel : Monsieur Hamza BEN AMMAR

Encadrant académique : Docteur Hela LIMAM
Réalisé au sein de Teligencia GmbH /Layer8
Année Universitaire 2022 - 2023

République Tunisienne
Ministère de l’enseignement supérieur
et de la recherche scientifique
Université de Tunis El Manar
Institut supérieur d’informatique
Rapport de Stage de Fin d’Études

Présenté en vue de l’obtention de la
Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques
Spécialité : Ingénierie de développement des logiciels
Solution SaaS d’analyse avancée des vulnérabilités

pour les dispositifs IoT
Encadrant professionnel : Monsieur Hamza BEN AMMAR

Encadrant académique : Docteur Hela LIMAM
Réalisé au sein de Teligencia
Année Universitaire 2022 - 2023

J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance.
Encadrant professionnel, Monsieur Hamza BEN AMMAR
Signature et cachet
J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance.
Encadrant académique, Docteur Hela LIMAM
Signature
Dédicaces
Siwar BEN FAKHTA
ii
Remerciements
iii
Table des matières
Introduction générale 1
1 Cadre général du projet 3

1.1 Présentation de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Étude et critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Choix méthodologique de développement . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Plannification et spécification des besoins 8

2.1 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 Identification des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3 Identification des besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . 10
2.2 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Diagramme des cas d’utlisation global . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Spécification architecturale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.1 Architecture logicielle de teligencia.io . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.2 Clean Architecture pour Backend . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Structure et plannification du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6.1 Plannification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6.2 Diagramme de Gantt prévisionnel du projet . . . . . . . . . . . . . . . . . . . 16
3 Sprint 1 : Gestion des utilisateurs, authentification et site web 18

3.1 Backlog du premier sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Analyse des cas d’utilisation du premier Sprint . . . . . . . . . . . . . . . . . . . . . 20
3.2.1 Cas d’utilisation « S’authentifier » . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.2 Cas d’utilisation « Editer profil » . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.3 Cas d’utilisation « Gérer les utilisateurs » . . . . . . . . . . . . . . . . . . . . 21
3.3 Conception des cas d’utilisation du premier sprint . . . . . . . . . . . . . . . . . . . 23
iv
3.3.1 Conception du cas d’utilisation « s’authentifier » . . . . . . . . . . . . . . . . 23
3.3.2 Conception du cas d’utilisation « Editer profil » . . . . . . . . . . . . . . . . 23
3.3.3 Conception du cas d’utilisation « Afficher les utilisateurs » . . . . . . . . . . . 24
3.3.4 Conception du cas d’utilisation « Activer un utlisateur » . . . . . . . . . . . . 25
3.4 Réalisation des cas d’utilisation du premier sprint . . . . . . . . . . . . . . . . . . . . 25
3.4.1 Modèle de données du premier sprint . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.2 Interfaces réalisées au cours du premier sprint . . . . . . . . . . . . . . . . . . 26
3.5 Revue du premier sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4 Sprint 2 : Analyse d’un firmware 31

4.1 Backlog du second sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Analyse des cas d’utilisation du second sprint . . . . . . . . . . . . . . . . . . . . . . 33
4.2.1 Cas d’utilisation « Analyser un firmware » . . . . . . . . . . . . . . . . . . . . 33
4.2.2 Cas d’utilisation « Consulter la liste des firmwares » . . . . . . . . . . . . . . 33
4.3 Conception des cas d’utilisation du second sprint . . . . . . . . . . . . . . . . . . . . 34
4.3.1 Conception du cas d’utilisation « Analyser un firmware » . . . . . . . . . . . . 34
4.3.2 Conception du cas d’utilisation« consulter la liste des firmwares » . . . . . . . 35
4.4 Réalisation des cas d’utilisation du second sprint . . . . . . . . . . . . . . . . . . . . 36
4.4.1 Modèle de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.2 Interfaces réalisées au cours du second sprint . . . . . . . . . . . . . . . . . . 37
4.5 Revue du second sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5 Sprint 3 : Résultats d’analyse du firmware 39

5.1 Backlog du troisième sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2 Analyse des cas d’utilisation du troisième sprint . . . . . . . . . . . . . . . . . . . . . 40
5.2.1 Cas d’utilisation « Consulter les résultats d’analyse » . . . . . . . . . . . . . . 40
5.3 Conception des cas d’utilisation du troisième sprint . . . . . . . . . . . . . . . . . . . 43
5.3.1 Conception du cas d’utilisation « Afficher l’analyse du code source » . . . . . 43
5.3.2 Conception du cas d’utilisation « Analyser les composants du firmware » . . . 43
5.4 Réalisation des cas d’utilisation du troisième sprint . . . . . . . . . . . . . . . . . . . 44
5.4.1 Modèle de données du troisième sprint . . . . . . . . . . . . . . . . . . . . . . 44
5.4.2 Interfaces réalisées au cours du troisième sprint . . . . . . . . . . . . . . . . . 44
v
5.5 Modèle de données global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.6 Revue du troisième sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6 Sprint 4 : Implémentation d’une pipeline CI/CD 49

6.1 Présentation du CI/CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.1.1 CI : Intégration continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.1.2 CD : Déploiement continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.1.3 Architecture CI/CD proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2 Backlog du produit du quatrième sprint . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.3 Analyse des cas d’utilisation du quatrième sprint . . . . . . . . . . . . . . . . . . . . 54
6.3.1 Digramme d’activité de l’intégration continue . . . . . . . . . . . . . . . . . . 54
6.3.2 Digramme d’activité du déploiement continue . . . . . . . . . . . . . . . . . . 54
6.4 Réalisation des cas d’utilisation du quatrième sprint . . . . . . . . . . . . . . . . . . 55
6.5 Revue du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.6 Diagramme de Gantt réel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Conclusion générale et perspectives 58
Bibliographie 59
WARNING 60
vi
Table des figures
1.1 Logo Teligencia Labs[1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Diagramme des cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Architecture logicielle de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Architecture clean [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Plannification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Diagramme de Gantt prévisionnel du projet . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Raffinement du cas d’utilisation « Gérer les utilisateurs ». . . . . . . . . . . . . . . . 21

3.2 Diagramme de séquence système du cas d’utilisation « S’authentifier ». . . . . . . . . 23
3.3 Diagramme de séquence système du cas d’utilisation « Editer profil ». . . . . . . . . 24
3.4 Diagramme de séquences détaillé du cas d’utilisation « Afficher les utilisateurs ». . . 24
3.5 Diagramme de séquence détaillé du cas d’utilisation « Activer un utlisateur ». . . . . 25
3.6 Modèle de données du premier sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.7 Interface de création d’un nouveau compte. . . . . . . . . . . . . . . . . . . . . . . . 27
3.8 Interface de création d’un nouveau compte. . . . . . . . . . . . . . . . . . . . . . . . 28
3.9 Interface du modification du profil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.10 Interface du site web de l’application. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.11 Interface gestion des utilisateurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1 Diagramme de séquence détaillé du cas d’utilisation« Analyser un firmware » . . . . 35

4.2 Diagramme de séquence détaillé du cas d’utilisation« consulter la liste des firmwares » 35
4.3 Modèle de données du second sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4 Interface d’importation d’un firmware . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5 Interface de la liste des firmwares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1 Digramme du cas d’utilisation raffiné de « Consulter les résultats d’analyse » . . . . 41

5.2 Diagramme de séquence détaillé du cas d’utilisation« Analyser code source » . . . . 43
5.3 Diagramme de séquence détaillé du cas d’utilisation« Analyser un firmware » . . . . 43
5.4 Modèle de données du troisème sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.5 Interface du résultat d’analyse des licenses. . . . . . . . . . . . . . . . . . . . . . . . 44
vii
5.6 Interface du questionnaire d’analyse des licenses. . . . . . . . . . . . . . . . . . . . . 45
5.7 Interface de l’analyse du code source . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.8 Interface de la liste des composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.9 Interface de l’arbre des fichiers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.10 Interface de la liste des vulnérabilités . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.11 Modèle de données global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.1 Cycle de vie de CI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.2 Automatisation du processus de déploiement . . . . . . . . . . . . . . . . . . . . . . . 52
6.3 Architecture CI/CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.4 Digramme d’activité de l’intégration continue . . . . . . . . . . . . . . . . . . . . . . 54
6.5 Digramme d’activité du déploiement continue . . . . . . . . . . . . . . . . . . . . . . 54
6.6 Fichier Docker-Compose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.7 Fichier nginx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.8 Pipeline jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.9 Diagramme de Gantt réel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
viii
Liste des tableaux
2.1 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1 Backlog du premier sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Description textuelle du cas d’utilisation S’authentifier. . . . . . . . . . . . . . . . . . 20
3.3 Description textuelle du cas d’utilisation Editer profil. . . . . . . . . . . . . . . . . . 21
3.4 Description textuelle du cas d’utilisation « Afficher les utilisateurs ». . . . . . . . . . 22
3.5 Description textuelle du cas d’utilisation Activer utilisateur. . . . . . . . . . . . . . . 22
4.1 Backlog du second sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2 Description textuelle du cas d’utilisation Analyser un firmware . . . . . . . . . . . . 33
4.3 Description textuelle du cas d’utilisation consulter la liste des firmwares . . . . . . . 34
5.1 Description textuelle du cas d’utilisation Consulter les résultats d’analyse . . . . . . 40

5.2 Description textuelle du cas d’utilisation Afficher les vulnérabilités . . . . . . . . . . 41
5.3 Description textuelle du cas d’utilisation Afficher l’analyse du code source . . . . . . 42
5.4 Description textuelle du cas d’utilisation Afficher la conformité des licenses . . . . . . 42
6.1 Backlog du quatrième sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
ix
Liste des abréviations
— API = Interface de programmation d’application
— CSRF = Cross-site request forgery
— IOT = Internet Of Things
— NIST = National Institute of Standards and Technology
— NVD = National Vulnerability Database
— SQL = Structured Query Language
— XSS = Cross-Site Scripting
x
Introduction générale
La cybersécurité est devenue l’un des enjeux majeurs de notre ère numérique, notamment
avec la prolifération des objets connectés à Internet. Les dispositifs IoT sont de plus en plus présents
dans notre vie quotidienne, des appareils ménagers intelligents aux systèmes de sécurité intelligents
en passant par les voitures autonomes, mais ils présentent également des risques potentiels pour la
sécurité et la confidentialité des données. Les cybercriminels peuvent exploiter les vulnérabilités des
dispositifs connectés pour accéder à des informations sensibles, nuire à la vie privée et causer des
dommages physiques.
Il existe actuellement dans le monde plusieurs solutions de sécurité pour les dispositifs IoT
telles que Netrise, Onekey et Binaré qui offrent des fonctionnalités de sécurité avancées telles que la
surveillance en temps réel, la détection des intrusions, le chiffrement des données et l’authentification
des utilisateurs. Cependant, ces solutions ont leurs limites, notamment en termes de coût et de
complexité d’implémentation, ainsi que de compatibilité avec différents dispositifs IoT.
Dans cette optique, Teligencia a déployé un effort soutenu en vue de concevoir une solution
novatrice et performante en matière d’analyse des vulnérabilités des objets connectés témoigne
d’une recherche perpétuelle de l’excellence technologique. Cet enjeu crucial nécessite une approche
méthodique et rigoureuse et requiert l’exploration inlassable de nouvelles approches et la mobilisation
de compétences pointues dans des domaines tels que la cryptographie, la sécurité informatique
et l’intelligence artificielle ainsi q’une compréhension approfondie des architectures de systèmes
embarqués et la capacité de développer des algorithmes sophistiqués. Cet engagement dans une
recherche incessante a fait naitre une solution de pointe, capable de relever les défis les plus ardus
de la cybersécurité des objets connectés.
Nous présenterons les chapitres du notre rapport. Nous commencerons par le premier chapitre
intitulé « Cadre général du projet » qui défnissera d’abord défnissera le cadre de notre projet, puis il
proposera les solutions aux critiques existantes. Enfin il présentera la méthodologie à suivre tout au
long du projet. Le deuxième chapitre intitulé « Plannification et spécification des besoins » permet
de présenter un recueil de besoins fonctionnels et techniques et une vue globale sur l’architecture
à adopter pour le projet. Les troisième et quatrième chapitres seront principalement consacrés à
la partie métier de notre projet, répondant ainsi aux exigences du projet. Le cinquième chapitre
1
Introduction générale
sera entièrement dédié à l’implémentation d’une pipeline d’intégration continue et de déploiement

continu. Nous concluons ce présent rapport avec une conclusion et des perspectives.
2
Chapitre 1
Cadre général du projet
Plan
1 Présentation de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Étude et critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Choix méthodologique de développement . . . . . . . . . . . . . . . . . . 7

Chapitre 1. Cadre général du projet
Introduction
L’objectif de ce chapitre est de situer notre travail dans son contexte global. Nous débutons
par présenter l’organisme d’acceuil, puis nous examinons l’existant. Ensuite, nous exposons l’objectif
du projet avant de clôturer en décrivant la méthodologie de développement que nous allons utiliser.
1.1 Présentation de l’entreprise
Fondée en 2020, Teligencia est un fournisseur de services de cybersécurité haut de gamme

basée à Düsseldorf, Allemagne. Elle est spécialisée dans la protection des données et les besoins en
sécurité numérique des petites et grandes entreprises.
En combinant les connaissances technologiques, la sécurité intelligente et les outils de pointe
en un seul endroit, Teligencia découvre une toute nouvelle frontière de solutions de cybersécurité
innovantes, notamment l’évaluation des risques, les services de test de pénétration, la gestion des
vulnérabilités et plus encore. Sa force unique réside dans l’analyse des défis de sécurité spécifiques et
dans l’utilisation de stratégies originales qui renforcent non seulement la défense cybernétique, mais
améliorent également les performances de l’entreprise, faisant en fin de compte de son organisation
un leader dans son secteur [1].
Figure 1.1 : Logo Teligencia Labs[1]
1.2 Étude et critique de l’existant
Les appareils IoT sont devenus omniprésents dans notre vie quotidienne, des maisons intelligentes
aux usines connectées en passant par les villes intelligentes. Cependant, en raison de leur manque
de sécurité intrinsèque, ces appareils sont vulnérables aux cyberattaques, ce qui peut entraîner
des conséquences graves telles que la divulgation de données sensibles, l’usurpation d’identité et la
prise de contrôle à distance de l’appareil. Pour cette raison, la sécurité des dispositifs IoT est un
sujet de préoccupation majeur pour les fabricants, les entreprises et les utilisateurs finaux. Pour
4
protéger les appareils IoT contre les attaques, les entreprises ont développé plusieurs solutions
d’analyse de vulnérabilités. Dans cette étude, nous allons passer en revue les solutions d’analyse de
vulnérabilités existantes spécialement conçues pour les dispositifs IoT, telles que EMBARK, Binarly
et bien d’autres. Ces solutions permettent aux propriétaires et aux gestionnaires d’appareils IoT de
détecter les vulnérabilités et les failles de sécurité, de surveiller l’état de sécurité des appareils, et de
prendre des mesures pour réduire les risques d’attaques et de compromissions.
Dans cette enquête, nous allons examiner en détail les principales solutions d’analyse de
vulnérabilités existantes pour les appareils IoT, leurs fonctionnalités, leurs avantages et leurs limites.
1 EMBARK : EmbarK est un logiciel open-source d’analyse de vulnérabilités pour les applications web.
Il a été développé pour aider les développeurs à identifier les failles de sécurité dans leurs applications
web et à les corriger avant qu’elles ne soient exploitées par des attaquants.
Il peut détecter une large gamme de vulnérabilités, notamment les failles de type injection SQL, les
failles XSS, les failles CSRF et les failles de sécurité liées à la configuration.
Une des fonctionnalités intéressantes d’EmbarK est la génération de rapports détaillés. Les développeurs
peuvent facilement visualiser les vulnérabilités détectées, triées par ordre de criticité. Les rapports
incluent également des captures d’écran pour aider les développeurs à comprendre comment les vulnérabilités
ont été découvertes.
Bien que la solution EMBARK présente de nombreux avantages en matière de détection de vulnérabilités
pour les appareils IoT, elle présente également certaines limites et faiblesses.
Parmi ses limites nous pouvons citer
— Crash de l’application : L’application s’est fermée de manière inattendue en analysant le

firmware ;
— Analyse limitée : L’analyse du firmware est limitée à l’extraction du version, le nom du vendeur
et la date de publication sans aucune information sur le score de risque ou un résumé sur l’état
du système.
— Compatibilité limitée : EMBARK peut ne pas être compatible avec tous les types de systèmes
et d’applications, ce qui peut limiter sa capacité à détecter les vulnérabilités dans certains
environnements ;
— Dépendance des mises à jour : EMBARK doit être régulièrement mis à jour pour détecter
les dernières vulnérabilités, ce qui peut entraîner des coûts et des efforts supplémentaires pour
l’entreprise.
2 Binarly : Binarly est un logiciel spécialisé dans la sécurité informatique qui se concentre sur l’analyse
de fichiers binaires. Il utilise une approche basée sur l’analyse de comportement pour identifier les
menaces potentielles et détecter les malwares. Binarly utilise une technique de sandboxing pour isoler
5
les fichiers suspects et les analyser dans un environnement sécurisé, sans risque pour le système hôte.
Bien que Binarly soit un outil puissant pour la détection de malwares basée sur l’analyse de fichiers
binaires, mais il présente de nombreux limites parmi lesquelles nous pouvons citer
— Limitations dans la détection des vulnérabilités logiques : Binarly se concentre principalement

sur la détection des vulnérabilités de bas niveau et l’analyse des fichiers binaires donc il peut avoir
des difficultés à détecter des vulnérabilités plus complexes qui impliquent des failles logiques.
— Coûts élevés : Le coût d’acquisition et de maintenance de la solution Binarly peut être élevé,
surtout pour les petites entreprises qui ont des budgets limités.
— Nécessité d’une expertise en sécurité : Pour utiliser efficacement Binarly, une expertise en
sécurité est nécessaire pour interpréter les résultats et prendre des mesures correctives appropriées.
— Mauvais UX/UI : Binarly présente une expérience utilisateur complexe et une interface utilistateur
peu conviviale et peu attrayante.
1.3 Solution proposée
Après une analyse critique de l’existant en matière de cybersécurité pour les objets connectés,
il est évident de dire que les solutions actuelles d’analyse de vulnérabilités en vigueur présentent
des insuffisances significatives qui peuvent compromettre leur efficacité. En effet, elles peuvent être
sujettes à des biais et des limitations liés à leurs méthodes d’analyse à savoir la plupart d’elles
se basent sur des règles prédéfinies pour déceler des vulnérabilités connues, ce qui les rend moins
performantes pour détecter des vulnérabilités émergentes ou inconnues. Pour répondre à ces défis,
une nouvelle solution émerge qui offre une analyse des firmwares, une identification des composants
et assure la conformité des licences. Cette solution identifie les vulnérabilités connues, les failles de
sécurité potentielles et les faiblesses dans la configuration des paramètres de sécurité, permettant
une détection rapide des menaces potentielles et une réponse immédiate pour minimiser les risques.
Grâce à ces informations précieuses, les utilisateurs peuvent prendre des mesures proactives pour
renforcer la sécurité de leurs dispositifs IoT et protéger les données sensibles qu’ils manipulent.
Teligencia.io est une solution de cybersécurité pour IoT qui représente une amélioration significative
par rapport aux solutions existantes, offrant une meilleure précision, une expérience utilisateur plus
érgonomique, une réactivité accrue et une surveillance continue des appareils connectés.
6
1.4 Choix méthodologique de développement
Notre application d’analyse des vulnérabilités des firmwares est un défi majeur en raison
de l’écosystème en constante évolution et du développement rapide des objets connectés. Cette
situation rend le processus complexe et exige une méthodologie de travail flexible et adapté aux
exigences changeants. Pour surmonter ces défis, nous avons opté pour le framwework Scrum. Cette
méthodologie de gestion de projet agile permet une approche itérative et incrémentale du développement
de logiciels, ce qui rend le processus plus flexible et plus efficace.
Conclusion
Dans cette partie de notre rapport, nous avons présenté l’organisme d’accueil, ensuite nous
sommes passée à l’étude de l’existant et constatation. Nous avons aussi énoncé l’objectif de notre
projet avant de clôturer avec la méthodologie de développement adoptée.
7
Chapitre 2
Plannification et spécification des

besoins
Plan
1 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Diagramme des cas d’utlisation global . . . . . . . . . . . . . . . . . . . . 12
4 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5 Spécification architecturale . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6 Structure et plannification du projet . . . . . . . . . . . . . . . . . . . . . 16

Chapitre 2. Plannification et spécification des besoins
Introduction
Dans le présent chapitre,nous allons nous concentrer sur les fonctionnalités que notre système
doit fournir. Nous commençons par identifier les différents acteurs impliqués dans le système. Ensuite,
nous analysons les besoins du système et représentons ces besoins à l’aide de la méthode de modélisation
UML. Pour illustrer les besoins, nous utilisons des diagrammes de cas d’utilisation ainsi que des
descriptions textuelles détaillées.
2.1 Identification des besoins
Dans cette section, nous identifions les acteurs de notre application et nous présentons en
détail les exigences qui seront mises à la disposition de chaque acteur. Ces besoins sont classés en
besoins fonctionnels et non fonctionnels.
2.1.1 Identification des acteurs
Nous avons identifié deux catégories d’utilisateurs de notre système :
— Administrateur : c’est le responsable du système d’administration de la plateforme ayant

plus de privilèges d’accès aux données. Il est chargé de la gestion des différents éléments de la
plateforme parmi lesquels nous pouvons citer la gestion des utilisateurs ;
— Utilisateur : représente un utilisateur simple qui a le droit d’accéder à l’application afin de

procéder à l’analyse de ses firmwares et identifier des vulnérabilités potentiels.
2.1.2 Identification des besoins fonctionnels
Dans cette partie, nous détaillerons l’ensemble des fonctionnalités que notre application web
doit offrir aux utilisateurs. Le système à élaborer doit respecter les besoins fonctionnelles suivantes :
— Analyser un firmware : Cette fonctionnalité permet à l’utilisateur de l’application d’importer

un fichier de firmware afin de le faire analyser par le système et d’identifier d’éventuels risques
existants.
— Gérer les utililsateurs : Cette fonctionnalité permet à l’administrateur de l’application de
— Activer un nouveau utilisateur ;
— Supprimer un utlisateur.
9
— Créer un compte : Cette fonctionnalité permet à l’utlisateur de créer un compte pour

bénéficier des avantages de la solution.
— Modifier profil : Cette fonctionnalité permet à l’utilisateur de modifier ses informations.
— S’authentifier : Cette fonctionnalité permet à l’utilisateur de se connecter à l’application

en utilisant ses identifiants, à savoir son adresse e-mail et son mot de passe, afin d’accéder à
l’ensemble des fonctionnalités disponibles.
— Consulter les résultats d’analyse : Cette fonctionnalité permet d’afficher les résultats
d’analyse du firmware en mettant l’accent sur les différentes vulnérabilités trouvées, le degré
de risque et les éventuels attaques.
— Consulter le site web : Cette fonctionnalité permet à l’utilisateur de parcourir le site web
de Teligencia.io.
2.1.3 Identification des besoins non fonctionnels
Les besoins non fonctionnels sont des exigences implicites auxquelles le système doit répondre.
Ils sont essentiels pour améliorer la qualité des services offerts par le site. Parmi ces besoins nous
citons :
— Sécurité : Une attention minutieuse a été accordée à la sécurité dans tous les aspects de
l’application. Notre solution doit garantir la confidentialité, l’intégrité et la disponibilité des
données sensibles et des résultats d’analyse. Elle doit également mettre en place des mécanismes
de protection contre les attaques potentielles et les intrusions ;
— Temps de réponse : L’analyse d’un firmware nécessite initialement une étape d’extraction,
suivie d’une étape d’identification des vulnérabilités. Cette dernière exige un temps d’analyse
assez important donc nous avons opté pour une solution qui minimise le temps de réponse et
par la suite améliore l’expérience utilisateur en permettant une utilisation fluide et réactive de
l’application, sans délais perceptibles ;
— L’ergonomie : Nous accordons une attention particulière à l’ergonomie de l’application,

en effet notre concepteur ui/ux a veillé à garantir une cohérence visuelle et une expérience
utilisateur fluide. ;
— Extensibilité : L’application doit pouvoir s’adapter facilement à de nouveaux types de vulnérabilités,

à de nouvelles technologies ou à des changements dans l’environnement informatique.
10
2.2 Backlog du produit
Dans cette section, nous allons aborder le backlog du produit, un élément essentiel dans
le processus de développement de notre application. Notre équipe produit, dirigée par notre Scrum
Master, a consciencieusement préparé ce backlog présenté dans le tableau 2.1 pour guider et prioriser
les fonctionnalités et les améliorations à apporter à notre produit.
Tableau 2.1 : Backlog du produit
Numéro
ID Titre User Story Priorité
sprint
En tant qu’un utilisateur

1 Créer un compte je souhaite m’inscrire au Elevé 1
système.

2 S’authentifier Elevé 1
je souhaite m’authentifier
En tant qu’un admin je

3 Gérer des utilisateurs souhaite ajouter, modifier Moyenne 1
ou désactiver un utilisateur.

4 Consulter le site web je souhaite consulter le site Moyenne 1
web de la solution teligencia.io.

5 Analyser un firmware je souhaite analyser un firmware Elevé 2
pour détecter les vulnérabilités.

je souhaite consulter les
6 Consulter les résultats d’analyse Elevé 3
résultats d’analyse après le
scan du firmware.
En tant qu’un utilisateur je

7 Consulter liste firmware Moyenne 2
souhaite consulter la liste des firmwares
En tant qu’un spécialiste devops je

8 Automatiser le pipeline Moyenne 4
souhaite automatiser le pipeline.
11
2.3 Diagramme des cas d’utlisation global
La figure 2.1 met en relief le diagramme de cas d’utilisation globale de notre application.
Notre application doit offrir un ensemble de fonctionnalités pour les deux acteurs concernés.
Figure 2.1 : Diagramme des cas d’utilisation global
12
2.4 Environnement logiciel
Dans le cadre de notre projet, nous avons sélectionné avec soin les outils et l’environnement
logiciel pour répondre aux besoins spécifiques et garantir l’efficacité de notre travail. Nous avons
pris en compte plusieurs critères, tels que la compatibilité, la fiabilité, la facilité d’utilisation et les
fonctionnalités offertes par les différentes solutions disponibles. Le tableau 2.2 détaille les différents
outils que nous avons utilisés au cours de notre développement.
Tableau 2.2 : Environnement logiciel
Environnement Logiciel Définition
Visual Studio Code est un éditeur de code source

qui peut être utilisé avec une variété de langages de programmation [2].
Pycharm est un logiciel multi-plateforme qui

fonctionne sous Windows, Mac OS X et GNU/Linux [3].
Gitlab, c’est une plateforme permettant d’héberger et de gérer

des projets web de A à Z [4].
Docker permet d’embarquer une application dans un ou plusieurs

containers logiciels qui pourra s’exécuter sur n’importe quel
serveur machine, qu’il soit physique ou virtuel [5].
Jenkins est, comme vous vous en doutez, un outil d’automatisation

des processus d’intégration continue et de déploiement continu [6].
Postman est un logiciel qui va vous permettre tester une API [7].
Visual Paradigm Online est un outil de conception de diagrammes

en ligne en vue d’une programmation [8].
LaTeX (dont le logo est LATEX) est un langage et un système

de composition de documents [9].
13
2.5 Spécification architecturale
2.5.1 Architecture logicielle de teligencia.io
La figure 2.2 met en relief l’architecture globale de notre application. Nous avons choisi de
concevoir une architecture pour notre solution d’analyse des vulnérabilités des firmwares, composée
d’un frontend React, d’un backend Node.js et d’une API Python Flask dédiés à la logiqe métier
et le traitement des données et d’une base de données NVD qui est une base de données publique
et gratuite gérée par le National Institute of Standards and Technology (NIST) aux États-Unis. A
partir de laquelle nous récupérons les vulnérabilités (cve) des composants. Cette décision repose
sur plusieurs arguments solides. Premièrement, cette architecture nous permet de diviser notre
application en plusieurs services, chacun étant responsable d’une fonctionnalité spécifique. Dans
notre cas, le frontend React se concentre sur l’interface utilisateur conviviale et interactive, tandis que
le backend Node.js et l’API Python Flask sont dédiés à l’extraction et à l’analyse des vulnérabilités
des firmwares. Deuxièmement, cette architecture favorise la scalabibilité et permet de faire évoluer
les composants en fonction des besoins spécifiques. Finalement, adopter une telle architecture nous
permet de développer une solution robuste et performante pour l’analyse des firmwares vulnérables.
Figure 2.2 : Architecture logicielle de l’application
14
2.5.2 Clean Architecture pour Backend
Notre projet de développer une solution SaaS d’analyse des vulnérabilités des dispositifs IoT
représente un défi complexe et innovant. En raison de la nature évolutive de l’écosystème IoT et des
exigences changeantes en matière de sécurité, il est impératif d’adopter une approche rigoureuse et
adaptable pour le développement du backend. L’architecture Clean se révèle être un choix judicieux
pour maintes raisons :
— Séparation claire des responsabilités : en découpant notre application en différentes couches

logiques telles que la couche de présentation, la couche métier et la couche d’accès aux données,
nous obtenons un code plus modulaire et facile à comprendre.
— Adoption de bonnes pratiques de sécurité : en isolant la logique de l’application et en séparant

clairement les couches, nous pouvons mieux contrôler les accès aux ressources sensibles
— Réduction les dépendances indésirables et de garantir une base solide
La figure 2.3 refléte la clean architecture qui vise à réduire les dépendances de notre logique
métier avec les services (API, Base de données, Framework, Librairies tierces), pour maintenir une
application stable au cours de ses évolutions.
Figure 2.3 : Architecture clean [10]
15
2.6 Structure et plannification du projet
2.6.1 Plannification des sprints
Pour mener ce projet à terme, nous avons choisi de l’organiser en plusieurs sprints. Chaque
sprint représentera une période de temps définie au cours de laquelle nous nous concentrerons sur des
objectifs spécifiques et livrerons des fonctionnalités précises. La figure 2.4 dévoile la plannification
et le découpage de notre projet en sprints.
Figure 2.4 : Plannification des sprints
2.6.2 Diagramme de Gantt prévisionnel du projet
Le diagramme de Gantt, couramment utilisé en gestion de projet, est l’un des outils les
plus efficaces pour représenter visuellement l’état d’avancement des différentes activités (tâches) qui
constituent un projet [11]. La figure 2.5 met en relief le diagramme de Gantt prévisionnel du projet.
A la fin du projet, nous allons élaboré le diagramme de Gantt réel et nous allons éffectuer une petite
comparaison pour mesurer notre performance par rapport au planning initial et identifier d’éventuels
écarts.
16
Figure 2.5 : Diagramme de Gantt prévisionnel du projet
Conclusion
Ce présent chapitre a abordé une spécification des besoins qui procure une vision plus claire
du sujet abordé et une compréhension plus profonde des tâches à réaliser. Dans le chapitre suivant,
nous allons entamer notre premier sprint.
17
Chapitre 3
Sprint 1 : Gestion des utilisateurs,

authentification et site web
Plan
1 Backlog du premier sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 Analyse des cas d’utilisation du premier Sprint . . . . . . . . . . . . . . 20
3 Conception des cas d’utilisation du premier sprint . . . . . . . . . . . . 23
4 Réalisation des cas d’utilisation du premier sprint . . . . . . . . . . . . 25
5 Revue du premier sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Chapitre 3. Sprint 1 : Gestion des utilisateurs, authentification et site web
Introduction
Une fois que nous avons minutieusement planifié notre projet, nous entreprendrons la phase de
réalisation des sprints qui le compose. Le présent chapitre sera entièrement dédié au premier sprint,
qui a pour objectif de mener à concrétiser la fonctionnalité d’authentification et le développement du
site web. Nous procéderons à établir de manière rigoureuse le backlog du sprint, avant de présenter
une solution conceptuelle clairement structurée, à travers divers diagrammes élaborés. Enfin, nous
amorcerons la phase de réalisation proprement dite.
3.1 Backlog du premier sprint
Dans l’optique d’élucider les tâches à mener à terme avant la fin du sprint, nous procéderons
à l’élaboration minutieuse du tableau 3.1 de sprint backlog qui recense en détail toutes les histoires
utilisateur à développer pendant la durée impartie à ce sprint.
Tableau 3.1 : Backlog du premier sprint
ID User Story Tâches Priorité
En tant qu’un utilisateur, je -Création de l’interface de création d’un compte.

1 1
souhaite créer un compte. -Développement backend.
En tant qu’un utilisateur, je

-Création de l’interface d’authentification
souhaite m’authentifier à l’aide
2 -Développement coté backend 1
d’un login et d’un mot de
-Intégration d’api
passe.
-Développement de l’interface de la liste

des utilisateurs
En tant qu’un administrateur,
3 -Développement de la fonctionnalité de 2
je souhaite gérer les utilisateurs
désactivation d’un utilisateur et l’affichage de
la liste.
-Développement de l’interface de modification

En tant qu’un utilisateur,
4 du profil 3
je souhaite éditer mon profil
-Développement de la fonctionnalité en backend
En tant qu’un utilisateur,

5 -Développement du site web 4
je souhaite consulter le site web.
19
3.2 Analyse des cas d’utilisation du premier Sprint
Dans cette partie, nous allons présenter les cas d’utilisation qui met en exergue les fonctionnalités
essentielles que nous avons prévues pour ce premier sprint.
3.2.1 Cas d’utilisation « S’authentifier »
Nous entamons notre étude analytique par une description textuelle, telle que spécifiée au
sein du tableau 3.2 , afin de cerner les aspects essentiels du processus d’authentification.
Tableau 3.2 : Description textuelle du cas d’utilisation S’authentifier.
Cas d’utilisation S’authentifier
Acteur Utilisateur
Pré condition L’utilsateur doit avoir un compte sur l’application
Post condition L’utilisateur authentifié, il doit avoir un accès à son espace privé.
1) L’utilisateur demande l’interface d’authentification.

2) Le système affiche le formulaire.
3) L’utilisateur saisit son email et mot de passe.
Scénario nominal
4) L’utilisateur clique sur le bouton "login".
5) Le système vérifie les champs.
6) Le système redirige l’utilisateur vers son espace.
5.1) Le système affiche « Login ou mot de passe invalides » .

Scénario alternatif
(Retour à l’étape 3)
3.2.2 Cas d’utilisation « Editer profil »
Nous continuons notre démarche d’analyse en dévoilons la description textuelle dans le

tableau 3.3 relatif au cas d’utilisation « Editer profil ». Cette fonctionnalité permet à l’utilisateur
de facilement modifier et actualiser les détails de son profil selon ses besoins par la suite maintenir
ses informations personnelles à jour.
20
Tableau 3.3 : Description textuelle du cas d’utilisation Editer profil.
Cas d’utilisation Editer profil
Acteur Utilisateur
Pré condition L’utilisateur doit etre authentifié.
Post condition Les informations de l’utilisateur sont mises à jour.
1) L’utilisateur demande l’interface de modification.

2) Le système affiche le formulaire.
3) L’utilisateur met à jour les champs.
Scénario nominal
4) L’utilisateur clique sur le bouton "Valider".
5) Le système vérifie les champs.
6) Le système met à jour le profil.
5.1) Le système affiche « Champs invalides »

Scénario alternatif
(Retour à l’étape 3).
3.2.3 Cas d’utilisation « Gérer les utilisateurs »
Dans cette sous section, nous allons détailler les fonctionnalités spécifiques relatives à la
gestion des utilisateurs, en se basant sur les exigences du système exprimées préalablement. La
figure 3.1 met en évidence le raffinement du cas d’utilisation « Gérer les utilisateurs ».
Figure 3.1 : Raffinement du cas d’utilisation « Gérer les utilisateurs ».
21
Le tableau 3.4 met en relief la description détaillé du cas d’utilisation afficher la liste des
utilisateurs.
Tableau 3.4 : Description textuelle du cas d’utilisation « Afficher les utilisateurs ».
Cas d’utilisation Afficher la liste des utilisateurs
Acteur Administrateur
Pré condition L’administrateur doit etre authentifié.
Post condition Liste des utilisateurs affichée.
1) L’administrateur demande l’interface des utilisateurs.

Scénario nominal 2) Le système affiche la liste des utilisateurs.
3) L’administrateur consulte la liste.
Scénario alternatif Néant.
Le tableau 3.5 montre la description textuelle du cas d’utilisation « Activer un utilisateur ».

Cette fonctionnalité permet à un administrateur du système d’autoriser l’accès d’un utilisateur à la
plateforme ou au service. Grâce à cette fonctionnalité, l’administrateur peut valider et approuver
les comptes des utilisateurs, leur permettant ainsi de se connecter et d’utiliser les fonctionnalités
offertes.
Tableau 3.5 : Description textuelle du cas d’utilisation Activer utilisateur.
Cas d’utilisation Activer un utilisateur
Acteur Administrateur
Pré condition L’administrateur doit etre authentifié et liste des utilisateurs affichée.
Post condition Statut de l’utilisateur est activé.
1) L’administrateur clique sur le bouton activer.

2) Le système demande la confirmation de l’action.
Scénario nominal 3) L’administrateur confirme l’activation de l’utilisateur.
4) Le système met à jour le statut et affiche un message
de succès.
Scénario alternatif 3.1) L’administrateur annule l’action et le statut ne change pas.
22
3.3 Conception des cas d’utilisation du premier sprint
Pour garantir une implémentation efficace et cohérente du projet, une attention particulière
a été accordée à la conception du système, qui sera présentée dans cette section, accompagnée de
diagrammes de séquence détaillés pour illustrer les scénarios clés.
3.3.1 Conception du cas d’utilisation « s’authentifier »
La figure 3.2 dévoile le diagramme de séquence détaillée qui illustre la fonctionnalité d’authentification.
Il représente le processus par lequel un utilisateur demande une connexion au système.
Figure 3.2 : Diagramme de séquence système du cas d’utilisation « S’authentifier ».
3.3.2 Conception du cas d’utilisation « Editer profil »
La figure 3.2 dévoile le diagramme de séquence de la fonctionnalité de la mise à jour du profil.
23
Figure 3.3 : Diagramme de séquence système du cas d’utilisation « Editer profil ».
3.3.3 Conception du cas d’utilisation « Afficher les utilisateurs »
La figure 3.4 dévoile le diagramme de séquence de la fonctionnalité de l’affichage de la liste

des utilisateurs du système.
Figure 3.4 : Diagramme de séquences détaillé du cas d’utilisation « Afficher les utilisateurs ».
24
3.3.4 Conception du cas d’utilisation « Activer un utlisateur »
La figure 3.5 dévoile le diagramme de séquence de la fonctionnalité de l’activation d’un

utilisateur du système.
Figure 3.5 : Diagramme de séquence détaillé du cas d’utilisation « Activer un utlisateur ».
3.4 Réalisation des cas d’utilisation du premier sprint
3.4.1 Modèle de données du premier sprint
Notre solution est spécialement conçue pour détecter et évaluer les vulnérabilités ainsi que
les failles de sécurité dans les firmwares utilisés dans les objets connectés. L’analyse approfondie des
firmwares implique le traitement d’un grand nombre de données provenant de différentes sources, ce
qui nécessite une base de données NoSQL telle que MongoDB pour sa capacité à gérer efficacement de
gros volumes de données. En effet, la quantité de données générées lors de l’analyse des vulnérabilités
des firmwares peut être considérable, et MongoDB est parfaitement adapté pour stocker et traiter
ces données de manière efficace.
L’une des raisons majeures pour lesquelles MongoDB est particulièrement approprié dans
ce contexte réside dans la complexité et la variabilité des structures de données des firmwares.
Les firmwares peuvent présenter des structures de données complexes et changeantes en fonction
25
des versions et des appareils. La flexibilité offerte par MongoDB en termes de schéma de données
permet de gérer ces structures de manière souple et d’adapter facilement l’analyse aux différentes
versions et configurations de firmwares. Dans ce contexte nous avons soigneusement conçu notre
modèle de données présenté dans la figure 3.6. En effet, nous avons identifié les principales entités
et relations nécessaires pour soutenir les fonctionnalités spécifiques du sprint en cours. Nous avons
défini les attributs clés pour chaque document, en nous assurant de prendre en compte les besoins
de performance et de scalabilité.
Figure 3.6 : Modèle de données du premier sprint
3.4.2 Interfaces réalisées au cours du premier sprint
Dans cette section, nous dévoilerons les diverses interfaces élaborées durant cette étape de
développement. La figure 3.7 illustre l’interface de création d’un nouveau compte.
26
Figure 3.7 : Interface de création d’un nouveau compte.
27
La figure 3.8 illustre l’interface d’authentification pour accéder au système.
Figure 3.8 : Interface de création d’un nouveau compte.
La figure 3.9 illustre l’interface du modification du profil de l’utilisateur du système.
Figure 3.9 : Interface du modification du profil.
28
La figure 3.10 illustre l’interface du site web de l’application.
Figure 3.10 : Interface du site web de l’application.
29
La figure 3.11 illustre l’interface administrateur de la gestion des utilisateurs
Figure 3.11 : Interface gestion des utilisateurs.
3.5 Revue du premier sprint
A la fin de ce sprint, une réunion de revue de sprint a été tenue en présence des membres de
l’équipe Scrum. Nous avons commencé par expliquer l’objectif global du sprint et les fonctionnalités
spécifiques qui avaient été planifiées. Chaque membre de l’équipe a pris la parole pour présenter
le travail qu’il avait accompli pendant le sprint. Nous les développeurs, nous avons effectué des
démonstrations des nouvelles fonctionnalités, en mettant en évidence les aspects techniques et en
expliquant les choix que nous avions faits. Pendant ces démonstrations, le product Owner et le scrum
Master pouvaient interagir avec nous, poser des questions et exprimer leurs impressions.
La revue de sprint s’est conclue avec succès, atteignant son objectif de valider le travail réalisé et de
nous permettre de passer à la suite.
Conclusion
Au présent chapitre, nous avons mis l’accent sur l’élaboration de notre première étape de
travail, ce qui nous a permis de disposer d’un incrément du logiciel potentiellement livrable. Dans
le prochain chapitre, nous focaliserons notre attention sur la réalisation du deuxième sprint qui
s’articule principalement autour de la partie métier de notre solution qui est l’analyse d’un firmware.
30
Chapitre 4
Sprint 2 : Analyse d’un firmware
Plan
1 Backlog du second sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2 Analyse des cas d’utilisation du second sprint . . . . . . . . . . . . . . . 33
3 Conception des cas d’utilisation du second sprint . . . . . . . . . . . . . 34
4 Réalisation des cas d’utilisation du second sprint . . . . . . . . . . . . . 36
5 Revue du second sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Chapitre 4. Sprint 2 : Analyse d’un firmware
Introduction
Après avoir achevé le premier sprint avec succès, nous entamons maintenant le deuxième
sprint dédié à l’analyse du firmware, qui représente un micrologiciel intégré dans un objet connecté
ou un système embarqué. Nous entreprendrons l’établissement du backlog du sprint, suivi de la
présentation d’une solution conceptuelle clairement structurée, étayée par une variété de diagrammes
élaborés. Enfin, nous entamerons la phase de mise en œuvre, concrétisant ainsi notre vision.
4.1 Backlog du second sprint
Afin de clarifier les tâches essentielles à accomplir avant la clôture du sprint, nous entreprendrons
une élaboration méticuleuse du tableau 4.1 du sprint backlog. À l’issue de notre réunion de planification
de ce sprint, nous avons définit ce tableau qui détaille chaque histoire utilisateur à développer durant
la période définie pour ce sprint .
Tableau 4.1 : Backlog du second sprint
ID User Dtory Tâches Priorité
- Création de l’interface d’importation du

firmware
En tant qu’un utilisateur je veux
- Développement du service qui fait
1 analyser un firmware à fin d’extraire 1
l’extraction et l’analyse du firmware
des vulnérabilités potentiels.
- Consommation et intégration de l’api
d’extraction
-Création de l’interface web

-Développement du service d’extraction
En tant qu’un utilisateur, je du firmware.
2 veux consulter -Développement du service d’extraction 2
la liste des firmwares. des vulnérabilités des composants.

-Consommation du flask API
-Consommation et intégration de node api
32
4.2 Analyse des cas d’utilisation du second sprint
Dans la présente section, nous allons analyser les fonctionnalités clés prévues pour le second
sprint.
4.2.1 Cas d’utilisation « Analyser un firmware »
Dans le cadre de notre étude analytique, nous entamons le processus en établissant une
description textuelle, conformément aux spécifications définies dans le tableau 4.2. Cette approche
nous permet de cerner en détail les aspects essentiels du cas d’utilisation « Analyser un firmware »
qui vise à identifier les vulnérabilités potentielles dans un dispositif IoT en analysant son firmware.
Les dispositifs IoT, tels que les objets connectés, sont souvent dotés de micrologiciels ou de firmwares
spécifiques qui contrôlent leur fonctionnement.
Tableau 4.2 : Description textuelle du cas d’utilisation Analyser un firmware
Cas d’utilisation Analyser un firmware
Acteur Utilisateur
Précondition L’utilisateur doit être authentifié
Postcondition Le firmware est ajouté au système
1- L’utilisateur clique sur le bouton "upload firmware"

2- Le système affiche l’interface du formulaire
Scénario nominal 4- L’utilisateur remplit tous les champs requis du formulaire
5- Le système vérifie la saisie
6- Le système ajoute le firmware avec succès
Scénario alternatif 5.1- Le système affiche "champs invalides" et retour à l’étape 4
4.2.2 Cas d’utilisation « Consulter la liste des firmwares »
Dans cette section, nous allons aborder le cas d’utilisation "consulter la liste des firmwares".
Cette fonctionnalité permettra aux utilisateurs d’accéder à une vue complète de tous les firmwares
disponibles, en affichant leurs spécifications, métadonnées et autres informations pertinentes. Les
utilisateurs pourront ainsi consulter les détails des firmwares tels que leur nom, version, date d’analyse,
fournisseur, et toute autre information pertinente pour prendre des décisions éclairées concernant
les firmwares à sélectionner pour leur analyse. Le tableau 5.2 présente la description textuelle
33
du cas d’utilisation « consulter la liste des firmwares » qui permet aux utilisateurs d’accéder aux
informations des firmwares générées lors de l’analyse.
Tableau 4.3 : Description textuelle du cas d’utilisation consulter la liste des firmwares
Cas d’utilisation consulter la liste des firmwares
Acteur Utilisateur
Postcondition Liste des firmwares affichée
1- L’utilisateur clique sur "Firmware list"

Scénario nominal
2- Le système affiche une liste des firmwares trouvées
Scénario alternatif Néant
4.3 Conception des cas d’utilisation du second sprint
Dqns cette section, nous avons travaillé à représenter de manière visuelle les interactions entre
les différents acteurs et les composants à travers des diagrammes de séquence détaillés.
4.3.1 Conception du cas d’utilisation « Analyser un firmware »
Le diagramme de séquence présenté dans la figure 4.1 met en évidence la séquence d’actions
pour analyser un firmware dans le système.
34
Figure 4.1 : Diagramme de séquence détaillé du cas d’utilisation« Analyser un firmware »
4.3.2 Conception du cas d’utilisation« consulter la liste des firmwares »
pour identifier les différents vulnérabiliés trouvées.
Figure 4.2 : Diagramme de séquence détaillé du cas d’utilisation« consulter la liste des
firmwares »
35
4.4 Réalisation des cas d’utilisation du second sprint
4.4.1 Modèle de données
Le modèle de données affiché dans la figure 4.3 offre une représentation visuelle des composants
essentiels de notre application qui ont été mis en jeu au cours de notre second sprint. Il met en
évidence les collections, leurs attributs et propriétés, offrant ainsi une vue d’ensemble claire de la
structure de notre système. Ce diagramme a servi de guide pour notre implémentation et a facilité
la compréhension de notre architecture logicielle.
Figure 4.3 : Modèle de données du second sprint
36
4.4.2 Interfaces réalisées au cours du second sprint
Dans cette section, nous dévoilerons les diverses interfaces élaborées durant cette étape de
développement. La figure 4.4 illustre l’interface d’importation d’un firmware.
Figure 4.4 : Interface d’importation d’un firmware
La figure 4.5 illustre l’interface de la liste des firmwares.
Figure 4.5 : Interface de la liste des firmwares
37
4.5 Revue du second sprint
Au cours de cette revue, nous avons présenté les fonctionnalités et les tâches que nous avons
accomplies au cours du sprint. Parmi les réalisations majeures, nous avons pu démontrer la mise
en place de la solution d’analyse des vulnérabilités d’un firmware. Aussi, nous avons résolu des
problèmes de performance liés à la gestion des données volumineuses, ce qui a considérablement
amélioré la vitesse de traitement. A l’issue de cette cérémonie, nous avons pu valider la majorité des
fonctionnalités en mentionnant des améliorations souhaitées.
Conclusion
Dans le présent chapitre, nous avons accordé une grande importance à l’élaboration de notre
deuxième étape de travail, ce qui nous a permis de créer un incrément du logiciel potentiellement
livrable. Dans le prochain chapitre, nous concentrerons notre attention sur la réalisation du troisième
sprint.
38
Chapitre 5
Sprint 3 : Résultats d’analyse du

firmware
Plan
1 Backlog du troisième sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2 Analyse des cas d’utilisation du troisième sprint . . . . . . . . . . . . . . 40
3 Conception des cas d’utilisation du troisième sprint . . . . . . . . . . . 43
4 Réalisation des cas d’utilisation du troisième sprint . . . . . . . . . . . . 44
5 Modèle de données global . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6 Revue du troisième sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Chapitre 5. Sprint 3 : Résultats d’analyse du firmware
Introduction
Après avoir achevé le second sprint avec succès, nous entamons maintenant le troisième
sprint dédié aux résultats d’analyse du firmware. Nous entreprendrons avec rigueur l’établissement
du backlog du sprint, suivi de la présentation d’une solution conceptuelle clairement structurée,
étayée par une variété de diagrammes élaborés. Enfin, nous entamerons la phase de mise en œuvre,
concrétisant ainsi notre vision.
5.1 Backlog du troisième sprint
Tableau 5.1 : Description textuelle du cas d’utilisation Consulter les résultats d’analyse
ID Histoire Taches Priorité
-Création de l’interface web et le

questionnaire d’analyse
En tant qu’un utilisateur je peux consulter
-Création de l’api de l’analyse de la
les résultats d’analyse d’un firmware tel
1 confirmité des licenses 1
que la confirmité des licenses et l’analyse
-Création de l’api de l’analyse du code
du code source
source du firmware
-Intégration des api
5.2 Analyse des cas d’utilisation du troisième sprint
L’analyse des cas d’utilisation permet de comprendre les besoins et les exigences des utilisateurs,
ainsi que les fonctionnalités attendues du système. Lors de cette analyse, chaque cas d’utilisation est
examiné en détail pour identifier les acteurs impliqués, les actions effectuées et les résultats attendus.
5.2.1 Cas d’utilisation « Consulter les résultats d’analyse »
Dans cette sous-section, nous allons examiner de manière raffinée les fonctionnalités spécifiques
liées à l’affichage des résultats d’analyse, en nous appuyant sur les exigences du système mentionnées
précédemment. La figure 5.1 illustre le niveau de détail atteint dans le cas d’utilisation « Consulter
les résultats d’analyse ». Cette fonctionnalité permet aux utilisateurs d’accéder aux résultats détaillés
40
d’une analyse de firmware, notamment les vulnérabilités identifiées, les composants utilisés, le système
des fichiers et d’autres informations pertinentes.
Figure 5.1 : Digramme du cas d’utilisation raffiné de « Consulter les résultats d’analyse »
Nous poursuivons avec la description textuelle au tableau 5.2 du cas d’utilisation "afficher
les vulnérabilités". Cette fonctionnalité permet aux utilisateurs d’obtenir une liste des vulnérabilités
détectées dans un firmware spécifique. Ainsi d’évaluer rapidement les risques potentiels associés à
un firmware donné et de prendre des mesures appropriées pour remédier à ces vulnérabilités. Elle
fournit une visibilité essentielle sur les problèmes de sécurité liés aux firmwares et facilite la prise de
décision informée en matière de gestion des risques.
Tableau 5.2 : Description textuelle du cas d’utilisation Afficher les vulnérabilités
Cas d’utilisation Afficher les vulnérabilités
Acteur Utilisateur
Postcondition Liste des vulnérabilités affichée
1- L’utilisateur clique sur "vulnerability analysis

Scénario nominal
2- Le système affiche une liste des vulnérabilités trouvées
41
Ensuite, nous enchainons avec la description textuelle du cas d’utilisation « Afficher l’analyse
du code source » indiqué dans le tableau 5.3. Cette exigence et aussi importante puisqu’elle va
identifier les failles de sécurité qui peuvent inclure des vulnérabilités, des erreurs de programmation,
des pratiques de sécurité inadéquates ou des défauts de conception. L’analyse permet de les repérer
et de les évaluer en termes de gravité et de potentiel d’exploitation.
Tableau 5.3 : Description textuelle du cas d’utilisation Afficher l’analyse du code source
Cas d’utilisation Afficher l’analyse du code source
Acteur Utilisateur
Postcondition Analyse du code source affiché
1- L’utilisateur clique sur "Analyse du code source"

Scénario nominal 2- Le système affiche les résultats d’analyse du code source avec
les vulnérabilités potentiels.
Aussi nous allons dévoiler la description textuelle du cas d’utilisation « Afficher la conformité
des licenses » représentée dans le tableau 5.4. Cette fonctionnalité est essentielle pour analyser les
licences des composants d’un firmware afin d’identifier les éventuelles violations et d’évaluer leur
conformité aux normes de licences.
Tableau 5.4 : Description textuelle du cas d’utilisation Afficher la conformité des licenses
Cas d’utilisation Afficher la conformité des licenses
Acteur Utilisateur
Postcondition Analyse des composants est effectuée
1- L’utilisateur clique sur "License compliance"

2- Le système affiche un questionnaire
3- L’utilisateur remplit le questionnaire
Scénario nominal
4- Le système valide les champs
5- L’utilisateur confirme ses réponses
6- Le système analyses les réponses et affiche les résultats
Scénario alternatif 4.1- Le système affiche "champs requis" et retour à l’étape 3
42
5.3 Conception des cas d’utilisation du troisième sprint
5.3.1 Conception du cas d’utilisation « Afficher l’analyse du code source »
pour afficher l’analyse du source code
Figure 5.2 : Diagramme de séquence détaillé du cas d’utilisation« Analyser code source »
5.3.2 Conception du cas d’utilisation « Analyser les composants du firmware »
pour analyser les composants d’un firmware.
Figure 5.3 : Diagramme de séquence détaillé du cas d’utilisation« Analyser un firmware »
43
5.4 Réalisation des cas d’utilisation du troisième sprint
5.4.1 Modèle de données du troisième sprint
La figure 5.4 illustre le modèle de données du troisème sprint suivi au cours de l’implémentation.
Figure 5.4 : Modèle de données du troisème sprint
5.4.2 Interfaces réalisées au cours du troisième sprint
La figure 5.5 illustre l’interface du résultat d’analyse de la conformité des licenses.
Figure 5.5 : Interface du résultat d’analyse des licenses.
44
La figure 5.6 illustre l’interface du questionnaire à remplir par le client afin d’identifier des
éventuelles violations des licenses.
Figure 5.6 : Interface du questionnaire d’analyse des licenses.
La figure 5.7 illustre l’interface du résultats d’analyse du code source du firmware.
Figure 5.7 : Interface de l’analyse du code source
45
La figure 5.8 illustre l’interface de la liste des composants extraites à partir d’un sbom.
Figure 5.8 : Interface de la liste des composants
La figure 5.9 illustre l’interface de l’affichage de l’arbre des fichiers après extraction du
firmware.
Figure 5.9 : Interface de l’arbre des fichiers.
La figure 5.10 illustre l’interface de la liste des vulnérabilités trouvées après une analyse
profonde du firmware.
46
Figure 5.10 : Interface de la liste des vulnérabilités
5.5 Modèle de données global
Maintenant, nous présentons le modèle de données global de notre application présenté dans
la figure 5.11 qui constitue une composante fondamentale de son architecture. Il met en valeurles
entités et les concepts essentiels de notre domaine métier.
Figure 5.11 : Modèle de données global
47
5.6 Revue du troisième sprint
Ce sprint a été une période passionnante et productive pour notre équipe. Nous avons réussi
à relever plusieurs défis et à réaliser des avancées significatives dans nos objectifs. Au cours de ce
sprint, nous avons principalement mis en oeuvre la confirmité des licenses et l’analyse du source
code. Un autre aspect essentiel de ce sprint a été notre engagement continu envers l’agilité et la
collaboration. Nous avons maintenu des réunions régulières de suivi, favorisant une communication
transparente et une prise de décision collective.
Conclusion
Au présent chapitre, nous avons mis l’accent sur l’élaboration de notre troisième étape de
travail, ce qui nous a permis de disposer d’un incrément du logiciel potentiellement livrable. Dans le
prochain chapitre, nous focaliserons notre attention sur la réalisation du quatrième sprint.
48
Chapitre 6
Sprint 4 : Implémentation d’une

pipeline CI/CD
Plan
1 Présentation du CI/CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2 Backlog du produit du quatrième sprint . . . . . . . . . . . . . . . . . . . 53
3 Analyse des cas d’utilisation du quatrième sprint . . . . . . . . . . . . . 54
4 Réalisation des cas d’utilisation du quatrième sprint . . . . . . . . . . . 55
5 Revue du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6 Diagramme de Gantt réel . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Chapitre 6. Sprint 4 : Implémentation d’une pipeline CI/CD
Introduction
Dans ce chapitre, nous aborderons l’implémentation d’une pipeline CI/CD au sein de notre
projet. La mise en place d’une telle pipeline joue un rôle central dans notre processus de développement,
automatisant les étapes clés, de la compilation du code à son déploiement en production. Au
cours de ce chapitre, nous explorerons les différents aspects de l’implémentation de notre pipeline
CI/CD. Nous commencerons par présenter les outils et technologies que nous avons sélectionnés
pour soutenir notre processus d’automatisation. Ensuite, nous décrirons les différentes phases de la
pipeline, notamment la compilation, les tests unitaires, les tests d’intégration, et enfin, le déploiement
continu.
6.1 Présentation du CI/CD
6.1.1 CI : Intégration continue
L’intégration continue est une méthode de développement de logiciel DevOps avec laquelle les
développeurs intègrent régulièrement leurs modifications de code à un référentiel centralisé, suite à
quoi des opérations de création et de test sont automatiquement menées. L’intégration continue
désigne souvent l’étape de création ou d’intégration du processus de publication de logiciel, et
implique un aspect automatisé (un service d’IC ou de création) et un aspect culturel (apprendre
à intégrer fréquemment). Les principaux objectifs de l’intégration continue sont de trouver et de
corriger plus rapidement les bogues, d’améliorer la qualité des logiciels et de réduire le temps
nécessaire pour valider et publier de nouvelles mises à jour de logiciels CI. La figure 6.1 montre
les différents étapes de l’approche de l’intégration continue.
Figure 6.1 : Cycle de vie de CI
50
Nous pouvons détailler les différentes étapes comme suit
0. Build et intégrer le code : Le code source doit être disponible en permanence sur un
référentiel centralisé. Chaque développement doit être suivi pour révision. Ensuite, toutes les
étapes doivent être automatisées par un orchestrateur, capable de reproduire ces étapes et de
gérer les dépendances entre elles. De plus, l’utilisation d’un orchestrateur donne à chacun un
accès, à tout moment, à un tableau de bord qui fournit l’état de santé des étapes d’intégration
continue. De cette façon, les développeurs disposent de la boucle de rétroaction nécessaire le
plus tôt possible, afin de garantir que l’application est prête en tout temps.
Dans notre cas, nous avons choisi Jenkins comme notre orchestrateur.
0. Tester le code : Dans notre approche d’intégration continue DevOps, une étape clé consiste
à tester le code de manière automatisée. Nous avons intégré des tests dans notre pipeline afin
de garantir la qualité et la fiabilité de notre application à chaque modification du code source.
0. Qualité du code : Maintenant que les tests unitaires sont rédigés et exécutés, nous commençons
à bénéficier d’une meilleure qualité de code et à être rassurés quant à la fiabilité et à la
robustesse de l’application. Grâce à la compilation et aux tests unitaires, nous pouvons désormais
mesurer la qualité du code. Tout cela permet aux développeurs de maintenir un code de très
bonne qualité au fil du temps, en alertant l’équipe en cas de dérive des bonnes pratiques de
test.
Pour évaluer la qualité de notre code, nous avons choisi SonarQube.
6.1.2 CD : Déploiement continue
La livraison continue est une méthode de développement de logiciels dans le cadre de laquelle
les modifications de code sont automatiquement préparées en vue de leur publication dans un
environnement de production. Véritable pilier du développement moderne d’applications, la livraison
continue étend le principe de l’intégration continue en déployant tous les changements de code dans
un environnement de test et/ou de production après l’étape de création. Lorsque la livraison continue
est correctement implémentée, les développeurs disposent en permanence d’un artefact de génération
prêt pour le déploiement qui a été soumis avec succès à un processus de test standardisé [12]. La
figure 6.2 montre l’automatisation du processus du déploiement.
51
Figure 6.2 : Automatisation du processus de déploiement
6.1.3 Architecture CI/CD proposée
La figure 6.3 représente l’architecture de la solution proposée. Le processus de la pipeline

démarre lorsque le développeur effectue une modification dans GitHub grâce à un Webhook GitHub.
Tout d’abord, le projet Maven commence à se construire, puis passe à la phase des tests unitaires
avec JUnit5. Une fois la construction et les tests terminés, nous passons à l’analyse de la qualité du
code avec SonarQube. Ensuite, les images Docker seront construites à l’aide des DockerFiles pour le
backend et le frontend. Après avoir configuré les images, nous lancerons notre application sur Docker
à l’aide de docker-compose, qui organisera les images dans un conteneur unique.
Figure 6.3 : Architecture CI/CD
52
6.2 Backlog du produit du quatrième sprint
Le tableau 6.1 met en relief les différentes étapes à aboutir pour créer une pipeline CI/CD.
Tableau 6.1 : Backlog du quatrième sprint
ID Histoire Taches Priorité
- Création des fichiers Dockerfile

En tant que spécialiste DevOps,
des applications
1 je veux dockeriser 1
- Construction des images
toute l’application.
-Exécution des conteneurs
- Préparer les configurations nécessaires

En tant que spécialise DevOps,
2 - Création du fichier Jenkins 1
je veux intégrer jenkins avec docker
-Intégration de Jenkins avec Docker
- Créer un repository dans Gitlab

En tant que spécialiste Devops, - Installer SonarQube
3 je veux intégrer SonarQube avec - Mettre les configurations necessaires 2
gitlab - Envoyer les rapports de qualité avec

SonarQube
- Ecrire les scripts pour automatiser les build

- Ecrire les scripts pour automatiser les tests
- Ecrire les scripts pour automatiser la qualité
En tant que spécialise DevOps,
4 de code 2
je veux automatiser tout le process
- Ecrire les scripts pour automatiser le
déploiement
- Tester le pipeline
53
6.3 Analyse des cas d’utilisation du quatrième sprint
6.3.1 Digramme d’activité de l’intégration continue
La figure 6.4 montre l’intégration continue est un processus de la construction, les tests
unitaires et enfin les tests de qualité du code. L’ensemble du processus sera géré dans le serveur
Jenkins, qui représente notre orchestrateur.
Figure 6.4 : Digramme d’activité de l’intégration continue
6.3.2 Digramme d’activité du déploiement continue
La figure 6.5 montre la phase de déploiement qui est assurée par Docker et Nexus.
Figure 6.5 : Digramme d’activité du déploiement continue
54
6.4 Réalisation des cas d’utilisation du quatrième sprint
La figure 6.6 représente le fichier docker compose, qui est responsable de la création de network
entre les images docker et pour créer le conteneur.
Figure 6.6 : Fichier Docker-Compose
La figure 6.7 représente le fichier de configuration Jenkins.
Figure 6.7 : Fichier nginx
La figure 6.8 montre l’ensemble des phases d’un Job Jenkins afin d’automatiser l’ensemble
processus.
55
Figure 6.8 : Pipeline jenkins
6.5 Revue du sprint
Au cours de la revue de ce sprint, nous avons présenté notre pipeline. Tout d’abord, nous
avons mis en place la construction automatique du code source à l’aide de l’outil Jenkins. Cela nous
permet de garantir que notre application est toujours prête à être déployée. Dans l’ensemble, ce
sprint a été marqué par la mise en place réussie de notre pipeline CI/CD, renforçant ainsi notre
capacité à livrer rapidement et de manière fiable notre application à nos utilisateurs finaux.
6.6 Diagramme de Gantt réel
À la fin, nous avons utilisé un diagramme de Gantt réel, présenté das la figure 6.9, pour évaluer
notre projet et comparer nos réalisations avec nos objectifs initiaux. Ce diagramme nous a permis
de visualiser et d’analyser notre progression réelle par rapport à notre planification prévisionnelle.
En examinant le diagramme de Gantt réel, nous avons constaté que la plupart des tâches ont été
effectivement accomplies. Cependant, nous avons également identifié des délais dépassés au cours du
projet. Par exemple, nous avons consacré plus de temps que prévu à la phase de recherche initiale,
ce qui a retardé le démarrage effectif du développement. De plus, dans la partie de la gestion des
licences, nous avons rencontré des difficultés pour trouver une méthode d’évaluation de la conformité
des licences, ce qui a entraîné un retard supplémentaire. Cela nous a donné une vision claire de notre
avancement et des écarts éventuels par rapport à nos attentes initiales.
56
Figure 6.9 : Diagramme de Gantt réel
57
Conclusion générale et perspectives
À l’heure du bilan, ce présent rapport reflète le fruit d’un travail et d’un stage de quatre
mois en collaboration avec l’entreprise Teligencia GmbH/Layer8 pour couronner des années d’une
formation étendue et reconnue au sein de l’Institut Supérieur d’Informatique. Ce projet consiste à
mettre en place une solution d’analyse avancée des vulnérabilités des dispositifs IoT.
Nous avons commencé notre travail par une recherche perpétuelle et approfondie sur les
systèmes embarqués, les firmwares et la sécurité des objets connectés. Cette étape préliminaire nous
a permis de mieux appréhendrer les enjeux du domaine. Ensuite, nous avons procédé à l’analyse et
la spécification des besoins pour mieux définier les fonctionnalités souhaitées.
Etant convaincus de l’importance de l’adoption d’une approche agile, nous avons opté pour
le framwork Scrum pour la mise en place de notre projet. Cela nous a aidé à diviser le travail en
itérations, d’implémenter de manière itérative les différentes fonctionnalités métier.
Ce rapport témoigne de notre engagement, de notre expertise acquise tout au long de ce

stage et de notre capacité à relever des défis techniques et fonctionnels. Nous sommes fiers de ce que
nous avons atteint et comme perspectives nous comptons intégrer un module basé sur l’intelligence
artificielle pour la classification des firmwares, aussi un module de monitoring en temps réelle et
générer un rapport d’estimation de risques.
58
Bibliographie
[1] « Teligencia. » (2023), adresse : https://teligencia.com/?page_id=23.
[2] « Vscode. » (2023), adresse : https://fr.wikipedia.org/wiki/Visual_Studio_Code.
[3] « Paycharm. » (2023), adresse : https://fr.wikipedia.org/wiki/PyCharm.
[4] « Gitlab. » (2023), adresse : https://www.axopen.com/blog/2017/02/gitlab-cest-quoi/.
[5] « Docker. » (2023), adresse : https : / / www . journaldunet . fr / web - tech / guide - de - l -
entreprise - digitale / 1146290 - docker - definition - docker - compose - docker - hub -
docker-swarm-160919/.
[6] « Jenkins. » (2023), adresse : https : / / www . data - transitionnumerique . com / devops -
jenkins/.
[7] « Postman. » (2023), adresse : https://www.eewee.fr/postman-cest-quoi/.
[8] « Visual Paradigm. » (2023), adresse : https : / / digitiz . fr / outil / visual - paradigm -
online/.
[9] « Latex. » (2023), adresse : https://fr.wikipedia.org/wiki/LaTeX.
[10] « Clean Architecture. » (2023), adresse : https://www.adimeo.com/blog/forum-php-2019-

clean-architecture.
[11] « Gantt. » (2023), adresse : https://www.gantt.com/fr/.
[12] « CD. » (2023), adresse : https://aws.amazon.com/fr/devops/continuous-delivery/.
59
WARNING
This report contains confidential information belonging to Teligencia
GmbH/Layer8, and towards this context :

• It is not allowed in any case to publish it outside the establishment where
the author is registered prior taking permission from Teligencia UG/Layer8

• It must be only published within the establishment where registered his
author for the sake of consultation and it is allowed only for exclusive archiving
of the establishment.
• In any kind of use outside those conditions mentioned above may be

exposed to a serious legal harm by Teligencia GmbH /Layer8.
60
Résumé
Ce rapport a été rédigé dans le cadre d’un projet de fin d’études d’ingénieur à l’ISI, réalisé en
étroite collaboration avec Teligencia GmbH/Layer8, une entreprise spécialisée dans le domaine de
la cybersécurité. L’objectif central de ce projet était de concevoir et mettre en œuvre une solution
d’analyse avancée visant à identifier et à évaluer les vulnérabilités des dispositifs IoT. Grâce à
une approche approfondie et innovante, ce projet visait à renforcer la sécurité des dispositifs IoT.
Mots clés : Objet connecté, firmware, risque, sbom...
Abstract
This report has been prepared as part of an engineering graduation project at ISI, carried out in
close collaboration with Teligencia GmbH/Layer8, a company specializing in the field of cyber-
security. The main objective of this project was to design and implement an advanced analysis
solution aimed at identifying and evaluating vulnerabilities in IoT devices. Through aninnovative
approach, this project aimed to enhance the security of IoT devices.
Keywords : IOT, firmware, risk, sbom...
isi@isim.rnu.tn : ¨¤rtk¯ d§rb 71 706 698 : HAf 71 706 164 : Ah TA§C 2080 ¨¤CAb A§r w h 2
2, Abou Raihane Bayrouni 2080 l’Ariana Tél : 71 706 164 Fax : 71 706 698 Email : isi@isim.rnu.tn

Siwar Benfakhta Rapport VF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Siwar Benfakhta Rapport VF

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne

Ministère de l’enseignement supérieur

Rapport de Stage de Fin d’Études

Solution SaaS d’analyse avancée des vulnérabilités

Encadrant professionnel : Monsieur Hamza BEN AMMAR

Réalisé au sein de Teligencia GmbH /Layer8

Année Universitaire 2022 - 2023

Rapport de Stage de Fin d’Études

Solution SaaS d’analyse avancée des vulnérabilités

Encadrant professionnel : Monsieur Hamza BEN AMMAR

Réalisé au sein de Teligencia

Année Universitaire 2022 - 2023

Encadrant professionnel, Monsieur Hamza BEN AMMAR

Encadrant académique, Docteur Hela LIMAM

Siwar BEN FAKHTA

1 Cadre général du projet 3

2 Plannification et spécification des besoins 8

3 Sprint 1 : Gestion des utilisateurs, authentification et site web 18

4 Sprint 2 : Analyse d’un firmware 31

5 Sprint 3 : Résultats d’analyse du firmware 39

6 Sprint 4 : Implémentation d’une pipeline CI/CD 49

Conclusion générale et perspectives 58

1.1 Logo Teligencia Labs[1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Diagramme des cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 Raffinement du cas d’utilisation « Gérer les utilisateurs ». . . . . . . . . . . . . . . . 21

4.1 Diagramme de séquence détaillé du cas d’utilisation« Analyser un firmware » . . . . 35

5.1 Digramme du cas d’utilisation raffiné de « Consulter les résultats d’analyse » . . . . 41

6.1 Cycle de vie de CI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.1 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 Backlog du premier sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1 Backlog du second sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.1 Description textuelle du cas d’utilisation Consulter les résultats d’analyse . . . . . . 40

6.1 Backlog du quatrième sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

— API = Interface de programmation d’application

— CSRF = Cross-site request forgery

— IOT = Internet Of Things

— NIST = National Institute of Standards and Technology

— NVD = National Vulnerability Database

— SQL = Structured Query Language

— XSS = Cross-Site Scripting

sera entièrement dédié à l’implémentation d’une pipeline d’intégration continue et de déploiement

Cadre général du projet

2 Étude et critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . 4

4 Choix méthodologique de développement . . . . . . . . . . . . . . . . . . 7

1.1 Présentation de l’entreprise

Fondée en 2020, Teligencia est un fournisseur de services de cybersécurité haut de gamme

Figure 1.1 : Logo Teligencia Labs[1]

1.2 Étude et critique de l’existant

Parmi ses limites nous pouvons citer

— Crash de l’application : L’application s’est fermée de manière inattendue en analysant le

— Limitations dans la détection des vulnérabilités logiques : Binarly se concentre principalement

1.3 Solution proposée

1.4 Choix méthodologique de développement

Plannification et spécification des

3 Diagramme des cas d’utlisation global . . . . . . . . . . . . . . . . . . . . 12

6 Structure et plannification du projet . . . . . . . . . . . . . . . . . . . . . 16

2.1 Identification des besoins

2.1.1 Identification des acteurs

Nous avons identifié deux catégories d’utilisateurs de notre système :

— Administrateur : c’est le responsable du système d’administration de la plateforme ayant

— Utilisateur : représente un utilisateur simple qui a le droit d’accéder à l’application afin de

2.1.2 Identification des besoins fonctionnels

— Analyser un firmware : Cette fonctionnalité permet à l’utilisateur de l’application d’importer