2022 - 2023

Informatique

Mise en place d’une chaine de

sécurité des applications digitales

Réalisé par: Mayssa ZAHEG

Encadré par:

Encadrant ESPRIT: Mohamed Adel SELLAMI

Encadrant Entreprise: Fayez TEKITEK

 DÉDICACE

A mes chers parents

Pour tous leur sacrifices, leur amour, leur tendresse, leurs soutien et
leurs prières tout au long de mes études
A ma chère sœur
Pour son encouragement permanent, et son soutien moral
A mes chers frères
Pour leurs appuis et leurs encouragement, Que ce travail soit
l’accomplissement de vos voeux tant allégués, et le fruit de votre
soutien infaillible, Merci d’être toujours là pour moi.

i
 REMERCIEMENTS

Je souhaite adresser mes remerciements les plus sincères aux personnes qui m’ont apporté
leur aide et qui ont contribué à l’élaboration de ce rapport ainsi qu’à la réussite de cette formi-
dable année universitaire.

Ces remerciements vont tout d’abord au corps professoral et administratif d’École supérieure
privée d’ingénierie et de technologie ESPRIT, pour la richesse et la qualité de leur enseignement
et qui déploient de grands efforts pour assurer à leurs étudiants une formation actualisée.

Je tiens à remercier sincèrement Mr. Mohamed Adel SELLAMI et Mr. Fayez TEKITEK, qui se
sont toujours montrés à l’écoute et très disponible tout au long de la réalisation de ce travail,
ainsi pour l’inspiration, l’aide et le temps qu’ils ont bien consacré et sans qui ce travail n’aurait
jamais vu le jour.

Enfin, j’adresse mes plus sincères remerciements à tous mes proches et amis, qui m’ont toujours
encouragé au cours de la réalisation de ce rapport.

Merci à tous et à toutes.

ii
 TABLE DES MATIÈRES

Introduction générale 1

1 Étude, analyse et spécification des besoins du projet 3

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Cadre et contexte du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Cadre du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Problématique du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.3 Objectifs à atteindre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Démarche adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Cycle de développement d’un logiciel . . . . . . . . . . . . . . . . . . . . 5
1.3.1.1 Méthode SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 Langage de modélisation UML . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2.1 Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.7 Pilotage du Projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.7.1 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.7.2 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

iii
 1.8 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.8.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.8.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Fondements théoriques 13
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1 SonarQube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.1 Présentation de SonarQube . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.2 Pourquoi SonarQube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.3 Workflow de SonarQube . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Fortify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1 Présentation de Fortify . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Pourquoi Fortify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Workflow de Fortify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.3.1 Source analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.4 Les Différences entre SonarQube et Fortify . . . . . . . . . . . . . . . . . 17
2.3 Sonatype NexusIQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1 Présentation de Sonatype IQ . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 Pourquoi Sonatype IQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.3 Workflow de Sonatype IQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Les tests de pénétration des applications . . . . . . . . . . . . . . . . . . . . . . 20
2.5 Les tests de pénétrations des images docker . . . . . . . . . . . . . . . . . . . . . 20
2.5.1 Qu’est ce qu’une image docker . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.2 Pourquoi pentester les images docker : . . . . . . . . . . . . . . . . . . . 21
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Sprint1 « Installation des outils de scan statique » 23

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1 Backlog de sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Réalisation du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1 Installation de SonarQube . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.2 Les étapes d’installation de SonarQube . . . . . . . . . . . . . . . . . . . 24
3.2.3 Résultat de l’installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

iv
 3.2.4 Installation de Fortify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.5 Les étapes d’installation de Fortify . . . . . . . . . . . . . . . . . . . . . . 25
3.2.6 Résultat de l’installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.7 Installation de SonatypeIQ . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.8 Les étapes d’installation de SonatypeIQ . . . . . . . . . . . . . . . . . . . 26
3.2.9 Résultat de l’installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 Sprint 2 « Les processus d’intégration et de suivie de sécurité » 28

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1 Backlog de sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Réalisation du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 Sonarqube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.1 Script de scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.2 Plateforme SonarQube . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4 Fortify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4.1 Scripts de scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4.2 Plateforme Fortify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5 SonatypeIQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5.1 Script SonatypeIQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5.2 Plateforme de sonatype NexusIQ . . . . . . . . . . . . . . . . . . . . . . . 38
4.6 Rapport de suivi des métriques de sécurité . . . . . . . . . . . . . . . . . . . . . 41
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5 Sprint 3 « Les tests de pénétration » 43

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1 Backlog de Sprint3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Test de pénétration des application . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.1 Bugs techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.1.1 Exemples de bugs techniques . . . . . . . . . . . . . . . . . . . 44
5.2.2 Bugs logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.2.1 Exemples de bugs logiques . . . . . . . . . . . . . . . . . . . . 48
5.3 Test de pénétration des images dockers . . . . . . . . . . . . . . . . . . . . . . . 50
5.3.1 Exemples de vulnérabilités . . . . . . . . . . . . . . . . . . . . . . . . . . 50

v
 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Conclusion générale 55

vi
 TABLE DES FIGURES

1.1 logo de la société Vermeg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Méthode SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Historique d’UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Interface « Diagramme de cas d’utilisation » . . . . . . . . . . . . . . . . . . . . . 9

2.1 Fortify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Workflow de Fortify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Workflow de Sonatype IQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 Installation de SonarQube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Installation de Fortify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Installation de SonatypeIQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1 Pipeline d’intégration des applications digitales sur Jenkins . . . . . . . . . . . . 30

4.2 Stages sonar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3 Scan sonar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4 Vue globale des projets dans SonarQube . . . . . . . . . . . . . . . . . . . . . . . 31
4.5 Vue par projet dans SonarQube . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.6 points d’accès de sécurité dans SonarQube . . . . . . . . . . . . . . . . . . . . . 32
4.7 Interface d’administration de SonarQube . . . . . . . . . . . . . . . . . . . . . . 33
4.8 Pipeline d’intégration Fortify des applications digitales sur Jenkins . . . . . . . . 34
4.9 Stages Fortify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.10 Scan Fortify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.11 Script sur VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

vii
4.12 Task Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.13 dashboard de statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.14 Vue détaillées sur un projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.15 Informations et recommandations . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.16 Partie rapport sur Fortify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.17 Partie administration sur Fortify . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.18 La commande SonatypeIQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.19 Vue globale de SonatypeIQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.20 Vue par projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.21 Vue par vulnérabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.22 Rapport de SonatypeIQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.23 Suivi de SonarQube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.24 Suivi de Fortify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.25 Suivi de SonatypeIQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1 Injection de la quote au paramètre id . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2 Vérification de l’interaction du paramètre id avec la base de données . . . . . . . 45
5.3 Injection du code SQL dans la requête . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4 Extraction de la table admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.5 Injection du code JavaScript dans le paramètre d’URL . . . . . . . . . . . . . . . 47
5.6 Suppression du participant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.7 Ajout du participant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.8 Test de la liste généré de projectId . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.9 Exploitation du projectId . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.10 Téléchargement du malware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.11 Accès de lecture des fichiers non autorisé . . . . . . . . . . . . . . . . . . . . . . 51
5.12 Accès d’exécution des fichiers non autorisé . . . . . . . . . . . . . . . . . . . . . 51
5.13 Création non autorisée des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . 52
5.14 Avoir la version de Linux kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.15 Détection du "DirtyPipe" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.16 Exploitation du "DirtyPipe" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

viii
 LISTE DES TABLEAUX

1.1 Backlog Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 Backlog de sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1 Backlog de sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1 Backlog de Sprint3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

ix
 LISTE DES ABRÉVIATIONS

BD Base de données. 46

UML Langage de Modélisation Unifié. 6

x
 INTRODUCTION GÉNÉRALE

E présent rapport de projet de fin d’études se concentre sur la mise en place d’une chaîne

L de sécurité dans le contexte de la sécurité des applications et des images dockers.

La sécurité est devenue un enjeu majeur dans le domaine du développement logiciel,
car les applications sont de plus en plus exposées à des menaces et à des attaques potentielles.
L’objectif principal de ce projet est de mettre en place une chaîne de sécurité robuste et ef-
ficace en utilisant des outils tels que SonarQube, Fortify et Sonatype IQ et aussi par les tests de
pénétrations.
Cette chaîne de sécurité vise à renforcer la protection des applications et à réduire les risques liés
aux vulnérabilités de sécurité.
Le premier volet de ce projet porte sur l’utilisation de SonarQube, un logiciel d’analyse sta-
tique du code source, qui permet de détecter les bugs, les vulnérabilités de sécurité, les instances
de code dupliqué et d’autres anomalies pouvant nuire à la qualité du code. SonarQube offre des
fonctionnalités avancées pour mesurer et améliorer la qualité du code source, ce qui contribue
à la robustesse et à la fiabilité des applications.
Le deuxième volet du projet est axé sur l’utilisation de Fortify, une solution d’analyse de sé-
curité statique. Fortify permet de détecter les vulnérabilités de sécurité dans le code source, en
utilisant des règles et des techniques avancées d’analyse. Il fournit des rapports détaillés sur les
vulnérabilités identifiées, permettant aux développeurs de prendre des mesures correctives pour
renforcer la sécurité de l’application.
Le troisième volet du projet concerne l’utilisation de Sonatype IQ, un outil de gestion des
composants open source. Sonatype IQ permet d’analyser les dépendances des applications, d’iden-
tifier les vulnérabilités et les licences des composants open sources utilisés, et de fournir des re-
commandations pour garantir une utilisation sécurisée et conforme des composants.

1
 Enfin, le quatrième volet du projet se concentre sur les tests de pénétration des applications
et des images Docker. Ces tests visent à évaluer la résistance des applications et des environne-
ments Docker face à des attaques ciblées. Ils permettent de découvrir les vulnérabilités poten-
tielles et d’identifier les faiblesses de sécurité qui pourraient être exploitées par des personnes
malveillantes.
Le rapport est structuré en cinq chapitres.
Nous commençons le rapport par une étude de projet. Un chapitre durant lequel nous pré-
sentons l’organisme d’accueil ainsi que le contexte du sujet. Nous détaillons aussi la démarche
adoptée pour la réalisation de ce travail et nous nous intéressons à l’analyse et spécification des
besoins, backlog du produit et les environnements matériels et logiciels.
Le chapitre suivant est réservé expliquer et présenter les différents outils de scan et les raisons
de leurs choix de même pour les tests de pénétration des applications et des images dockers.
Les trois derniers chapitre présente chacun un sprint de projet commençons par le sprint
d’installation des outils de scan statique, puis le sprint des processus d’intégration et de suivie
de sécurité et enfin le sprint des tests de pénétration.
En conclusion, nous clôturons ce rapport tout en évoquant les perspectives qui peuvent étendre
notre projet.

2
 CHAPITRE 1

ÉTUDE, ANALYSE ET SPÉCIFICATION DES

BESOINS DU PROJET

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Cadre et contexte du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Démarche adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.5 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.6 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.7 Pilotage du Projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.8 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3
Introduction
Ce chapitre sera la pierre angulaire pour la compréhension du projet.
Nous commençons la première partie par le cadre et le contexte de notre projet. Ensuite, nous
dévoilons le processus simplifié que nous préconisons pour la modélisation de projet, aussi ce
chapitre vise à identifier et à comprendre les besoins fonctionnels et non fonctionnels ainsi que
l’environnement matériel et logiciel nécessaires pour garantir la mise en place de notre chaine
de sécurité.

1.1 Présentation de l’organisme d’accueil

Vermeg est un groupe international fondé en 1993 basé en France, Belgique, Luxembourg et
en Tunisie, composé de plus de 1600 collaborateurs et disposant de 550 clients dans plus de 40
pays, VERMEG opére dans plusieurs gammes de services B2B : retraites et assurances, gestion de
patrimoine et d’actifs, marchés financiers et de sécurité et services financiers numériques. Ver-
meg est également partenaire de la transformation digitale en Finance et assurance, avec l’offre
Digital Financial Services, appuyée sur des composants financiers, des méthodes agiles Time-to-
Market, ainsi que des composants digitaux, articulés autour du Framework de Vermeg, Palmyra
(cf.ref.[1]).

FIGURE 1.1 – logo de la société Vermeg

1.2 Cadre et contexte du sujet

1.2.1 Cadre du sujet

Ce travail s’inscrit dans le cadre d’un sujet de fin d’études en vue de l’obtention d’un diplôme
d’ingénieur de génie logiciel au sein d’ESPRIT "Ecole Supérieure Privée d’Ingénierie et de Techno-
logies".
Durant un stage de six mois effectué à la société Vermeg notre mission consiste à mettre en
place une chaine de sécurité pour les applications digitales .

4
1.2.2 Problématique du sujet

Afin d’assurer la sécurité de nos applications et protéger nos clients contre les attaques et les
failles et empêcher les pirates d’afficher des données sensibles et les exploiter, la mise en place
d’une chaine de sécurité est la meilleure solution par des différents outils de scan et les pentes.

1.2.3 Objectifs à atteindre

Notre mission consiste à mettre en place une chaine de sécurité avec des outils SAST :
Fortify pour la sécurité des codes sources, sonatype pour la sécurité des jars et des dépendances,
sonarqube pour la qualité de code, aussi les pentest des applications et des images dockers.

1.3 Démarche adoptée

1.3.1 Cycle de développement d’un logiciel

1.3.1.1 Méthode SCRUM

Dans le cadre de notre projet et afin d’assurer le bon déroulement des différentes phases de
ce dernier, nous avons opté pour la méthode agile Scrum. Le mot SCRUM (« mêlée ») fait réfé-
rence à la mêlée du rugby. En effet, cette méthode met en exergue l’esprit d’équipe et la volonté
d’avancer ensemble vers un même but.
S’il fallait résumer la méthode SCRUM en une phrase ?
SCRUM est une méthode itérative incrémentale centrée sur la réalisation d’un produit fonction-
nel (plutôt des produits non directement utiles comme par exemple certaines documentation).
Cette méthode est articulée autour de trois acteurs clés :
✱ le Product Owner : il a une vision complète du produit,
✱ le Scrum master : il assure le bon déroulement du projet et rappelle la méthode,
✱ l’équipe Scrum : elle développe le produit.
Le Product Owner définit le backlog du produit, c’est-à-dire la liste valorisée des fonctionnalités
cibles du produit. Cette liste a pour vocation d’évoluer, au fur et à mesure que la définition du
produit se construit.
Le premier sprint peut alors commencer ; Mais avant de débuter, l’équipe Scrum doit définir et
prioriser les fonctionnalités auxquelles elle s’attaquera durant cette itération. L’ensemble de ces
tâches est appelé « backlog du sprint ».
Lors du sprint, l’équipe, accompagnée d’un Scrum master, itère sur les développements et dé-

5
 FIGURE 1.2 – Méthode SCRUM

bute chaque journée par une « mêlée » durant laquelle elle rappelle les objectifs du jour.
A la fin de chaque sprint, le client ainsi que le Product Owner évaluent le produit partiellement
livrable afin de le valider ou d’indiquer les modifications à réaliser (elles seront alors ajoutées au
backlog du produit).
La méthode SCRUM est plus adaptée aux projets complexes sur lesquels on n’a pas de visibi-
lité : elle apporte davantage de flexibilité et d’adaptabilité aux évolutions demandées ainsi qu’une
meilleure gestion des risques (cf.ref.[2]).

1.3.2 Langage de modélisation UML

1.3.2.1 Terminologie

Le Langage de Modélisation Unifié (UML) se définit comme un langage de modélisation gra-

phique et textuel destiné à comprendre et décrire des besoins, spécifier et documenter des sys-
tèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points
de vue.
UML unifie à la fois les notations et les concepts orientés objet (voir l’historique d’UML sur la
figure 1.3). Il ne s’agit pas d’une simple notation graphique, car les concepts transmis par un dia-
gramme ont une sémantique précise et sont porteurs de sens au même titre que les mots d’un
langage (cf.ref.[3]).

6
 FIGURE 1.3 – Historique d’UML

1.4 Besoins fonctionnels

Les besoins fonctionnels définissent les fonctionnalités spécifiques pour la réalisation du
projet :
✱ Installer Sonarqube
✱ Installer Fortify
✱ Insaller Sontype nexusIQ
✱ Maitriser l’utilisation de Fortify et NexusIQ
✱ Créer les pipelines du scan sur jenkins
✱ Créer et scheduler les scripts par les taskscheduler sur les VMs
✱ Pentester les applications et les images dockers
✱ Suivre les metriques de securité
✱ Assisster et supporter les équipes pour les correctifs
✱ Supporter les problémes d’administration

7
1.5 Besoins non fonctionnels
En plus des fonctionnalités, il est important de prendre en compte les besoins non fonction-
nels, qui spécifient les contraintes et les critères de qualité auxquels la chaîne de sécurité doit
satisfaire.
La liste suivante peut être une évocation utile pour s’assurer que nous avons couvert l’essentiel.
✱ Performance
❊ La performance se réfère à la capacité de la chaîne de sécurité à fournir des résultats
rapidement et efficacement. Une bonne performance signifierait que les outils utili-
sés, tels que Sonarque, Fortify et Sonatype IQ, sont capables d’analyser et de traiter les
applications de manière efficace et rapide.
✱ Disponibilité
❊ La disponibilité fait référence à la capacité de la chaîne de sécurité à être opération-
nelle et accessible lorsque nécessaire. Il est important que les outils de sécurité soient
disponibles en tout temps pour effectuer des analyses et des tests de sécurité. La dis-
ponibilité peut être assurée en mettant en place une infrastructure robuste, et en ga-
rantissant que les outils sont correctement configurés et maintenus...
✱ Fiabilité
❊ La fiabilité se rapporte à la capacité de la chaîne de sécurité à fonctionner de manière
cohérente et à produire des résultats précis. Il est essentiel que les outils de sécurité
utilisés fournissent des résultats fiables et cohérents lors de l’identification des vulné-
rabilités et de l’évaluation de la sécurité des applications. Une fiabilité élevée garantit
que les problèmes de sécurité ne passent pas inaperçus et permet une prise de déci-
sion efficace pour les actions correctives.
✱ Intégrité
❊ L’intégrité se réfère à la garantie que la chaîne de sécurité est protégée contre les mo-
difications non autorisées ou les altérations. Garantir que les résultats de sécurité sont
fiables et qu’ils n’ont pas été manipulés.
✱ Compatibilité
❊ La compatibilité fait référence à la capacité de la chaîne de sécurité à fonctionner har-
monieusement avec l’environnement existant, y compris les outils de développement,
les frameworks et les systèmes d’exploitation utilisés dans le projet. Il est important de
s’assurer que les outils de sécurité sélectionnés (Sonarque, Fortify, Sonatype IQ) sont
compatibles avec les technologies utilisées dans les applications. Une compatibilité

8
 élevée facilite l’intégration de la chaîne de sécurité dans le processus de développe-
ment existant.

1.6 Diagramme de cas d’utilisation

Pour mieux comprendre les différentes fonctionnalités et interactions de la chaîne de sécurité
ainsi que les acteurs impliqués, nous avons réalisé un diagramme de cas d’utilisation globale.
Ce diagramme illustre les principales actions effectuées par les utilisateurs au sein de notre pro-
jet :

FIGURE 1.4 – Interface « Diagramme de cas d’utilisation »

9
1.7 Pilotage du Projet avec Scrum

1.7.1 Backlog du produit

Le backlog du produit est le passage le plus important dans la méthodologie Scrum. En effet,
il comprend la liste des fonctionnalités ou encore histoires utilisateurs (user story)

TABLE 1.1 – Backlog Produit

1.7.2 Planification des sprints

Plusieurs sprints sont créés pendant la planification.

C’est une ligne directrice qui reflète les attentes quant aux fonctionnalités qui seront mises en
œuvre et quand elles seront terminées. Il sert également de base pour suivre l’avancement du
projet.

10
Dans notre cas, nous avons découpé notre projet en trois sprints :

TABLE 1.2 – Planification des sprints

1.8 Environnement de travail

1.8.1 Environnement matériel

Pour la réalisation du tableau de bord, nous utilisons : un micro-ordinateur ayant les carac-
téristiques suivantes :
✱ La marque : DELL
✱ Processeur : 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz 1.69 GHz
✱ mémoire vive : 16.0 GB

1.8.2 Environnement logiciel

Nous avons recours à différents logiciels tels que :

✱ Windows 10 Enterprise - Système d’exploitation
✱ Machine virtuelle windows - fait référence à l’ensemble des logiciels et des configurations
utilisées pour exécuter les outils de sécurité, les applications, et les différents composants
du système (cf.ref.[4]).
✱ Jenkins - Outil d’intégration continue et de déploiement continu (CI/CD). Il permet d’au-
tomatiser les tâches de sécurité (cf.ref.[5]).

11
 ✱ BurpSuite - suite d’outils de test de sécurité des applications web largement utilisés par
les professionnels de la sécurité, il offre des fonctionnalités avancées pour effectuer des
tests d’intrusion, des analyses de sécurité et des manipulations de trafic web (cf.ref.[6]).
✱ Latex - un langage de description donnant à l’auteur les moyens d’obtenir des documents
mis en page de façon professionnelle sans avoir à se soucier de leur forme(cf.ref.[7]).

Conclusion
Après ce premier chapitre, nous avons clarifié le contexte de notre projet, spécifié les besoins
fonctionnels, non fonctionnels de notre application et présentait le diagramme de cas d’utilisa-
tion.
Ensuite, le backlog de notre projet, Ainsi, nous avons détaillé la phase de réalisation des sprints
et Enfin, l’environnement matériel et logiciel de travail.

12
 CHAPITRE 2

FONDEMENTS THÉORIQUES

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1 SonarQube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Fortify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Sonatype NexusIQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4 Les tests de pénétration des applications . . . . . . . . . . . . . . . . . . . . 20

2.5 Les tests de pénétrations des images docker . . . . . . . . . . . . . . . . . . . 20

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

13
Introduction
Ce chapitre constitue une base essentielle pour comprendre les concepts clés et les outils de
sécurité utilisés dans le cadre de la mise en place de la chaîne de sécurité et des tests de pénétra-
tion des applications et des images Docker.
Cette section vise à fournir les connaissances théoriques nécessaires pour appréhender les prin-
cipes fondamentaux de la sécurité et pour comprendre le fonctionnement des outils clés impli-
qués dans notre projet.

2.1 SonarQube

2.1.1 Présentation de SonarQube

En effet, SonarQube est une solution logicielle utilisée pour détecter, classifier et résoudre
les défauts présents dans le code source. Son objectif principal est d’inspecter le code source des
logiciels et des applications en cours de développement afin de repérer les bugs, les vulnérabilités
de sécurité, les duplications de code et autres anomalies pouvant altérer la qualité du code et, par
conséquent, le bon fonctionnement de l’application.
SonarQube se base sur une série de règles et de métriques préétablies pour analyser le code
source et générer des rapports détaillés mettant en évidence les problèmes détectés. Ces rapports
permettent aux développeurs de comprendre les problèmes identifiés et de prendre les mesures
nécessaires pour les corriger. L’objectif ultime est d’améliorer la qualité générale du code, de pré-
venir les erreurs de programmation, de réduire les vulnérabilités de sécurité et d’augmenter la
maintenabilité des applications.
En plus de l’analyse du code, SonarQube propose des fonctionnalités supplémentaires, telles
que l’évaluation de la dette technique, qui estime le coût associé à la résolution des problèmes
de code, la génération de rapports de qualité et la centralisation des résultats d’analyse. Ces fonc-
tionnalités aident les équipes de développement à suivre et à améliorer en permanence la qualité
de leur code source .(cf.ref.[8]).

2.1.2 Pourquoi SonarQube

le choix de SonarQube comme outil de sécurité est justifié par sa capacité à détecter les vul-
nérabilités de sécurité, sa large prise en charge des langages de programmation, sa base de règles
étendue, sa personnalisation des règles de sécurité, son intégration dans les processus de déve-

14
loppement et sa capacité à générer des rapports détaillés. SonarQube contribue ainsi à améliorer
la sécurité des applications dès les premières étapes du développement.

2.1.3 Workflow de SonarQube

Les développeurs push leurs codes sur le SCM (git, bitbucket..) et à partir de ce scm et sur
des pipelines Jenkins on fait un clone et on analyse le code par un plugiciel sonar configuré et le
résultat sera envoyé au serveur Sonarqube.

FIGURE 2.1 – Fortify

2.2 Fortify

2.2.1 Présentation de Fortify

Fortify est une suite d’outils de sécurité statique développés par micro Focus. Elle est conçue
pour identifier et atténuer les vulnérabilités de sécurité dans le code source des applications,
réduisant ainsi les risques d’exploitation, les atteintes à la sécurité et aide les développeurs à
identifier et résoudre les problèmes avec moins d’efforts et en moins de temps grâce à son analyse
statique de sécurité, son intégration dans le cycle de développement, son analyse de composition
logicielle et sa génération de rapports détaillés(cf.ref.[9]).

2.2.2 Pourquoi Fortify

Le choix de Fortify est justifié par sa capacité à fournir une analyse approfondie des vulnérabi-
lités, son intégration dans le cycle de développement, sa prise en charge des meilleures pratiques

15
de sécurité, son analyse automatisée des codes sources tiers, sa génération de rapports détaillés
et son support de conformité aux réglementations. En utilisant Fortify, on peut améliorer la sé-
curité des applications et réduire les risques liés aux vulnérabilités de sécurité.

2.2.3 Workflow de Fortify

Le code est builder et traiter par un contrôleur qui s’appelle le source analyzer, le résultat est
un fichier .fpr qui sera envoyé au serveur fortify.

FIGURE 2.2 – Workflow de Fortify

2.2.3.1 Source analyzer

Fortify Source Analyzer (également connu sous le nom de Fortify SCA) est un composant clé
de la suite Fortify qui permet d’analyser le code source des applications afin de détecter les vulné-
rabilités de sécurité. Fortify Source Analyzer utilise des techniques d’analyse statique pour iden-
tifier les faiblesses de sécurité potentielle dans le code source, en se basant sur une vaste base de
connaissances de vulnérabilités connues.
Voici quelques informations sur Fortify Source Analyzer :
✱ Analyse statique du code source :
Fortify Source Analyzer effectue une analyse statique du code source, ce qui signifie qu’il examine
le code sans l’exécuter. Il parcourt le code source ligne par ligne et applique des règles prédéfinies
pour identifier les vulnérabilités potentielles, telles que les failles de sécurité, les injections, les

16
débordements de tampon, les vulnérabilités de configuration, etc.
✱ Base de connaissances des vulnérabilités :
Fortify Source Analyzer est alimenté par une base de connaissances des vulnérabilités, qui est ré-
gulièrement mise à jour avec les dernières informations sur les failles de sécurité connues. Cela
permet à l’outil de détecter les vulnérabilités courantes et de fournir des informations contex-
tuelles sur les problèmes identifiés.
Fortify Source Analyzer est un outil puissant pour l’analyse de sécurité du code source. Il peut
être utilisé pour renforcer la sécurité des applications en détectant et en corrigeant les vulnéra-
bilités de sécurité dès les premières étapes du développement.

2.2.4 Les Différences entre SonarQube et Fortify

SonarQube et Fortify sont deux outils de sécurité utilisés dans le domaine du développement
logiciel pour identifier et corriger les vulnérabilités et les erreurs de code.
Bien qu’ils aient des objectifs similaires, ils diffèrent dans leur approche et leurs fonctionnalités.
Voici quelques différences clés entre SonarQube et Fortify :
✱ Fonctionnement :
SonarQube : SonarQube est un outil open source basé sur des règles statiques qui analyse le
code source pour détecter les problèmes de qualité et de sécurité. Il offre des fonctionnalités
d’analyse statique du code, de mesure de la dette technique, de suivi des métriques de qualité et
de génération de rapports.
Fortify : Fortify, développé par Micro Focus, est une suite d’outils de sécurité statique qui uti-
lisent des analyses statiques et dynamiques pour identifier les vulnérabilités dans le code source.
Il propose des fonctionnalités avancées telles que l’analyse de sécurité statique (SAST), l’analyse
de sécurité dynamique (DAST), la gestion des vulnérabilités, et l’intégration avec d’autres outils
de sécurité.
✱ Couverture des langages :
SonarQube : SonarQube prend en charge de nombreux langages de programmation populaires
tels que Java, C/C++, C#, JavaScript, Python, etc. Il propose des plugins spécifiques pour chaque
langage pour une analyse approfondie du code.
Fortify : Fortify supporte également une large gamme de langage, mais il est particulièrement
réputé pour sa prise en charge des langages de programmation orientés vers la sécurité telle que
Java, .NET, C/C++, JavaScript, Objective-C, etc. Il offre des règles de sécurité spécifiques pour
chaque langage.

17
 ✱ Intégration avec les outils de développement :
SonarQube : SonarQube peut être intégré dans le processus de développement en tant que
plugin ou extension pour divers environnements de développement intégrés (IDE) tels qu’Eclipse,
IntelliJ, Visual Studio, etc. Il peut également être intégré dans les systèmes de gestion de versions
tels que Git, SVN, etc.
Fortify : Fortify propose des intégrations avec les principaux outils de développement tels
que IntelliJ, Eclipse, Visual Studio, Jenkins, etc. Il offre également des interfaces de ligne de com-
mande pour l’intégration dans des processus d’intégration continue (CI) et d’autres workflows.
✱ Orientation vers la sécurité :
SonarQube : SonarQube se concentre sur l’analyse de la qualité du code, y compris certains
aspects de la sécurité. Il fournit des règles de sécurité pour identifier les vulnérabilités courantes,
mais il n’est pas aussi spécialisé que Fortify en matière de sécurité.
Fortify : Fortify est spécifiquement conçu pour les tests de sécurité et l’identification des vul-
nérabilités. Il propose des règles de sécurité exhaustives pour identifier les vulnérabilités connues
et potentielles, et fournit des rapports détaillés avec des informations sur les risques et les recom-
mandations de correction.
En conclusion, il est important de noter que SonarQube et Fortify sont complémentaires.

2.3 Sonatype NexusIQ

2.3.1 Présentation de Sonatype IQ

Sonatype IQ se concentre sur la gestion des dépendances et la sécurité des composants open
source utilisés dans les applications. Il fournit des fonctionnalités d’analyse de sécurité, la possi-
bilité de définir des politiques personnalisées, et peut être intégré dans des pipelines d’intégra-
tion continue.
Nexus IQ permet d’analyser les bibliothèques open source pour tous les formats populaires,
y compris NPM, Nuget, Maven, Bowser, etc. IL permet également de protéger les déploiements
contre les derniers risques de sécurité exposés dans l’utilisation des bibliothèques open source.
Sonatype IQ joue un rôle important dans la réduction des risques liés à l’utilisation des com-
posants open source et dans l’adoption de bonnes pratiques de sécurité dans le développement
logiciel (cf.ref.[10]).

18
2.3.2 Pourquoi Sonatype IQ

Le choix de Sonatype Nexus IQ peut être justifié par plusieurs raisons :

✱ Gestion complète des composants open source :
Sonatype Nexus IQ offre une gestion complète des composants open source utilisés dans les ap-
plications. Il permet de gérer les dépendances, de suivre les licences des composants et d’analy-
ser les vulnérabilités associées. Cela aide à garantir la conformité légale et à réduire les risques
de sécurité liés à l’utilisation des composants open source.
✱ Analyse approfondie de la sécurité des composants :
Sonatype Nexus IQ propose une analyse approfondie de la sécurité des composants open source.
Il identifie les vulnérabilités connues et les faiblesses de sécurité des composants utilisés dans
les applications. Cela permet de détecter rapidement les vulnérabilités critiques et de prendre
des mesures pour les corriger ou les remplacer par des alternatives plus sécurisées.
✱ Intégration avec les outils de développement :
Sonatype Nexus IQ peut être intégré aux outils de développement et aux systèmes d’intégration
continue, tels que Jenkins, Maven, Gradle, etc. Cette intégration facilite l’automatisation de l’ana-
lyse de sécurité des composants à chaque étape du processus de développement, garantissant
ainsi une sécurité continue et proactive.
✱ Politiques de gestion des composants :
Sonatype Nexus IQ permet de définir des politiques de gestion des composants open source.
Vous pouvez spécifier des règles pour les licences acceptables, les vulnérabilités tolérées et les
bonnes pratiques de sécurité. Cela aide à maintenir une gouvernance cohérente des composants
et à s’assurer que seuls les composants conformes aux politiques définies sont utilisés.
✱ Support de conformité aux réglementations :
Sonatype Nexus IQ peut aider les organisations à se conformer à des réglementations spéci-
fiques, telles que les exigences de licence open source ou les normes de sécurité de l’industrie. Il
fournit des informations détaillées sur les licences des composants, les vulnérabilités détectées
et les recommandations de conformité, facilitant ainsi le processus de conformité.
En choisissant Sonatype Nexus IQ, nous bénéficions d’une gestion complète des composants
open source, d’une analyse approfondie de la sécurité, d’une intégration avec les outils de dé-
veloppement, de politiques de gestion personnalisée et d’un support de conformité aux régle-
mentations. Cela vous permet de renforcer la sécurité des applications et de garantir l’utilisation
responsable et sécurisée des composants open source.

19
2.3.3 Workflow de Sonatype IQ

Un nouveau composant est arrivé il passe par une évaluation s’il n’y a pas de problème il passe
directement comme composant normal sinon il passe à une recherche de sécurité et finalement
l’identification de sa criticité si el est malveillante ou pas.

FIGURE 2.3 – Workflow de Sonatype IQ

2.4 Les tests de pénétration des applications

Les tests de pénétration, également connus sous le nom de tests d’intrusion ou de tests de
sécurité, sont des évaluations réalisées pour identifier les vulnérabilités d’un système informa-
tique. Ces tests sont effectués afin de simuler des attaques potentielles qu’un système pourrait
subir et d’évaluer sa résistance face à ces attaques.
Les tests de pénétration peuvent inclure différentes étapes, telles que la collecte d’informa-
tions sur le système cible (recon), l’identification des points d’entrée potentiels, l’exploitation des
vulnérabilités découvertes, l’élévation des privilèges, la manipulation de données sensibles, etc.
Donc les résultats obtenus permettent de mesurer le niveau de sécurité actuel et d’évaluer
les risques encourus.

2.5 Les tests de pénétrations des images docker

2.5.1 Qu’est ce qu’une image docker

Les images Docker sont les blocs de construction des conteneurs Docker. Docker est une
plate-forme open source qui permet aux développeurs d’automatiser le déploiement d’appli-
cation dans des conteneurs. Un conteneur est un package léger, autonome et exécutable qui

20
comprend tout ce qui est nécessaire pour exécuter une application, y compris le code, l’envi-
ronnement d’exécution, les outils système, les bibliothèques et les dépendances.
Une image Docker est un modèle en lecture seule ou un instantané d’un conteneur. Il contient
les fichiers, configurations et dépendances nécessaires pour créer et exécuter une instance d’un
conteneur. Les images Docker sont créées à partir d’un ensemble d’instructions appelé Docker-
file, qui définit les étapes de création de l’image. Ces instructions spécifient l’image de base, le
code d’application à inclure, les dépendances à installer et toutes les configurations supplémen-
taires requises.
Les images Docker sont stockées dans un registre, tel que Docker Hub, qui est un référentiel
central pour le partage et la distribution d’images. Les développeurs peuvent extraire (téléchar-
ger) des images du registre vers leur ordinateur local ou vers un serveur, puis les utiliser pour créer
des conteneurs. Plusieurs conteneurs peuvent être créés à partir de la même image, et chaque
conteneur est isolé des autres, fournissant un environnement cohérent et reproductible pour
l’exécution des applications.
Les images Docker sont conçues pour être portables et peuvent s’exécuter sur n’importe quel
système sur lequel Docker est installé. Ils permettent de regrouper les applications et leurs dé-
pendance de manière autonome, ce qui facilite le déploiement et la mise à l’échelle des applica-
tions dans différents environnements, tels que le développement, les tests et la production.

2.5.2 Pourquoi pentester les images docker :

Quelques raisons pour lesquelles le penrst des images Docker sont nécessaires :
✱ Evaluation des vulnérabilités :
Les images Docker peuvent contenir des versions logicielles obsolètes ou des vulnérabilités connues.
En effectuant des tests d’intrusion, vous pouvez identifier et évaluer les vulnérabilités poten-
tielles, les erreurs de configuration ou les paramètres de sécurité faible dans l’image.
✱ Se protéger contre les attaques :
Les tests d’intrusion permettent d’identifier les failles de sécurité susceptibles d’être exploitées
par des attaquants. En simulant divers scénarios d’attaque, vous pouvez découvrir des vulné-
rabilités susceptibles d’entraîner un accès non autorisé, des violations de données ou d’autres
activités malveillantes. La correction de ces vulnérabilités avant le déploiement permet de pro-
téger votre système et vos données.
✱ Exigences de conformité :
De nombreux secteurs et cadres réglementaires, tels que PCI DSS, HIPAA ou GDPR, exigent que

21
les organisations effectuent des évaluations de sécurité régulières, y compris des tests de pé-
nétration. En testant les images Docker, vous pouvez garantir la conformité à ces exigences et
démontrer votre engagement en matière de sécurité.
✱ Vérification de l’intégrité des images :
Les images Docker peuvent être extraites de référentiels externes, et il existe un risque d’utiliser
par inadvertance des images malveillantes ou falsifiées. Les tests d’intrusion permettent de vé-
rifier l’intégrité des images, en s’assurant qu’elles sont exemptes de tout code malveillant ou de
modifications non autorisées.
✱ Configurations par défaut sécurisées :
Les images Docker sont souvent fournies avec des configurations par défaut, qui peuvent ne pas
être optimisées pour la sécurité. En effectuant des tests d’intrusion, vous pouvez identifier et
traiter les défauts non sécurisés, tels que les mots de passe faibles, les services inutiles ou les
contrôles d’accès trop permissifs.
✱ Amélioration continue de la sécurité :
les tests d’intrusion constituent une approche proactive de la sécurité. En testant et en évaluant
régulièrement les images Docker, vous pouvez continuellement améliorer la sécurité de vos ap-
plications conteneurisées. Cela vous aide à garder une longueur d’avance sur les vulnérabilités
potentielles et renforce votre stratégie de sécurité globale.
Dans l’ensemble, les tests d’intrusion des images Docker sont essentiels pour atténuer les
risques de sécurité.

Conclusion
Ce chapitre des fondements théoriques constitue une base solide pour la compréhension
des concepts clés liés à la sécurité et à la mise en place d’une chaîne de sécurité. Nous avons
également examiné les outils essentiels tels que SonarQube, Fortify et Sonatype IQ, ainsi que les
tests de pénétration des applications et des images docker.

22
 CHAPITRE 3

SPRINT1 « INSTALLATION DES OUTILS DE

SCAN STATIQUE »

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1 Backlog de sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Réalisation du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

23
Introduction
Dans ce chapitre, Nous allons attaquer le premier sprint de l’installation de SonarQube, For-
tify et Sonatype nexusIQ.

3.1 Backlog de sprint 1

Le tableau ci-dessous présente le Backlog de sprint1 :

TABLE 3.1 – Backlog de sprint 1

3.2 Réalisation du sprint 1

3.2.1 Installation de SonarQube

3.2.2 Les étapes d’installation de SonarQube

1.Vérification des prérequis systèmes pour SonarQube, tels que la version de Java requise et
les exigences matérielles....
2. Téléchargement de SonarQube du site officiel en choisissons la version compatible avec
notre système d’exploitation.
3. Configuration de la base de données selon les recommandations de SonarQube.
4.Configuration de SonarQube : Décompressé le fichier téléchargé et accédé au dossier So-
narQube. Modification des fichiers de configuration selon les besoins, notamment le fichier so-
nar.properties, pour spécifier les détails de la base de données, les paramètres de connexion, etc.
5. Démarrage de SonarQube : Exécuter le script de démarrage approprié. S’assurer que la
base de données est en cours d’exécution et accessible. SonarQube se lancera et commencera à

24
s’exécuter sur le port par défaut 9000.

3.2.3 Résultat de l’installation

La figure suivante montre l’installation de SonarQube

FIGURE 3.1 – Installation de SonarQube

3.2.4 Installation de Fortify

3.2.5 Les étapes d’installation de Fortify

1. Exécuter le fichier Fortify.exe et Cliquer sur suivant sur l’écran de bienvenue.

2. Sélectionner I accept the agreement dans la pop-up de licence agreement puis cliquer
next
3. Sélectionner l’emplacement de la licence Fortify, puis cliquer sur next.
4. L’URL du serveur de mise à jour de Fortify est apparue.
5. Cliquer sur next jusqu’à la fin de l’installation et le démarrage de Fortify.

3.2.6 Résultat de l’installation

La figure suivante montre l’installation de Fortify

25
 FIGURE 3.2 – Installation de Fortify

3.2.7 Installation de SonatypeIQ

3.2.8 Les étapes d’installation de SonatypeIQ

1. Installation de CentOS
2. Installation et configuration de Docker en CentOS 8
3. Installation de SonaType IQ Server
4. Sélectionner l’emplacement de la licence
5. Démarrage de Sonatype Nexus IQ

3.2.9 Résultat de l’installation

La figure suivante montre l’installation de SonatypeIQ

FIGURE 3.3 – Installation de SonatypeIQ

26
Conclusion
À l’issue de ce chapitre, nous disposons des interfaces de réalisation des fonctionnalités du
premier sprint.

27
 CHAPITRE 4

SPRINT 2 « LES PROCESSUS

D’INTÉGRATION ET DE SUIVIE DE
SÉCURITÉ »

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Backlog de sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2 Réalisation du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3 Sonarqube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4 Fortify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.5 SonatypeIQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.6 Rapport de suivi des métriques de sécurité . . . . . . . . . . . . . . . . . . . 41

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

28
Introduction
Dans ce chapitre, nous allons détailler le travail réalisé durant le deuxième sprint.

4.1 Backlog de sprint 2

Le tableau ci-dessous présente le backlog de sprint2 :

TABLE 4.1 – Backlog de sprint 2

4.2 Réalisation du sprint 2

4.3 Sonarqube

4.3.1 Script de scan

Le scan de SonarQube se fait dans un pipeline sur Jenkins pour faciliter l’intégration des nou-
veaux projets et automatiser leurs scans.
Aprés avoir définis les configurations nécassaire du version maven et java el défini la liste des
exclusion si elle existe, nous commencions à définir les stages, faire un clone et à utilisé la com-
mande sonar :sonar pour faire le scan.
la figure suivante est une interface de notre pipeline Jenkins.

29
 FIGURE 4.1 – Pipeline d’intégration des applications digitales sur Jenkins

La figure4.2 présente comment nous ajoutons les stages :

FIGURE 4.2 – Stages sonar

La figure4.3 présente la commande de scan :

30
 FIGURE 4.3 – Scan sonar

4.3.2 Plateforme SonarQube

Cette interface présente la vue globale des projets dans SonarQube où se trouve la liste de
tous les projets, un filtre de recherche et la barre d’outils.

FIGURE 4.4 – Vue globale des projets dans SonarQube

Linterface suivante présente la vue par projet :

31
 FIGURE 4.5 – Vue par projet dans SonarQube

L’interface suivante est l’interface de points d’accès de sécurité dans SonarQube,il donne une
explication de risk détecté, et comment nous pouvons le fixer.

FIGURE 4.6 – points d’accès de sécurité dans SonarQube

32
 La dernière interface de cette partie présente la partie administration de SonarQube.

FIGURE 4.7 – Interface d’administration de SonarQube

4.4 Fortify

4.4.1 Scripts de scan

Nous avons des scans qui se réalisent sur Jenkins et d’autres sur nos V. Ms :
Script Jenkins Le script commence par un clone de projet puis le scan Fortify se fait sur quatre
étapes faites par le source analyzer :
✱ Première étape : un build
✱ Deuxième étape : une conversion des classes de développement en un langage compré-
hensible par Fortify.
✱ Troisième étape : scan du code et renvoie d’un fichier result.fpr.
✱ Quatrième étape : upload de ce fichier .fpr sur le serveur Fortify.

33
 FIGURE 4.8 – Pipeline d’intégration Fortify des applications digitales sur Jenkins

FIGURE 4.9 – Stages Fortify

FIGURE 4.10 – Scan Fortify

Scripts sur les VMs :

34
Nous avons la possibilité de scanner nos applications sur nos VMs robuste par la création des
scripts cmd et aussi d’automatiser leurs créneaux de scan à l’aide de tasks Scheduler.

FIGURE 4.11 – Script sur VM

La figure suivante est une interface de Task Scheduler.

FIGURE 4.12 – Task Scheduler

4.4.2 Plateforme Fortify

Fortify offre une dashboard de statistiques sur les problèmes détectés.

35
 FIGURE 4.13 – dashboard de statistiques

La vue sur le projet nous permet de savoir le nombre totale des vulnérabilités classifié critique,
servere, moyenne, et faible ainsi des informations et des recommandations de correction.

FIGURE 4.14 – Vue détaillées sur un projet

La figure4.15 présente plusieurs détails sur le problème détecté sur Fortify : la classe, le ligne,

36
la méthode ... et aussi la possibilité de changer son statut faux positif par exemple.

FIGURE 4.15 – Informations et recommandations

Fortify nous donne la main de générer des rapports en plusieurs types, comme le rapport
de vulnérabilité qui détaille chaque vulnérabilité (information, cause, recommandation ...) et le
rapport d’application qui donne juste une vue globale sur les vulnérabilités détectées telles que
le nombre total en critique, sévère, moyenne et faible et des charts d’évolution.

FIGURE 4.16 – Partie rapport sur Fortify

Dans la partie administration, on trouve plusieurs fonctionnalités telles que l’event log, l’ajout
des utilisateurs (Ldap ou standard) avec différents rôles ( développeur, manager, security Leader

37
....) et la configuration (proxy, email, rapport) ...

FIGURE 4.17 – Partie administration sur Fortify

4.5 SonatypeIQ

4.5.1 Script SonatypeIQ

La commande de scan s’ajoute juste avant les commande fortify.

FIGURE 4.18 – La commande SonatypeIQ

Nous utilisons le jar nexus-iq-cli pour faire le scan.

4.5.2 Plateforme de sonatype NexusIQ

Dans cette partie nous allons vous lister les différentes interfaces de SonatypeIQ

38
 FIGURE 4.19 – Vue globale de SonatypeIQ

FIGURE 4.20 – Vue par projet

La vue suivante de vulnérabilité donne plus de détails et une recommandation.

39
 FIGURE 4.21 – Vue par vulnérabilité

SonatypeIQ offre aussi la possibilité de génération du rapport.

FIGURE 4.22 – Rapport de SonatypeIQ

40
4.6 Rapport de suivi des métriques de sécurité
Nous allons citer quelques exemples de rapport de suivi :

FIGURE 4.23 – Suivi de SonarQube

FIGURE 4.24 – Suivi de Fortify

41
 FIGURE 4.25 – Suivi de SonatypeIQ

Ce sont des rapports envoyés aux équipes de développement chaque semaine pour suivre
l’avancement sur les correctifs.

Conclusion
Durant ce sprint nous avons mis en place les différents outils statiques et les différentes pro-
cédures pour assurer la sécurité de nos applications et aider les équipes de développement à faire
le nécessaire.

42
 CHAPITRE 5

SPRINT 3 « LES TESTS DE PÉNÉTRATION »

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1 Backlog de Sprint3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2 Test de pénétration des application . . . . . . . . . . . . . . . . . . . . . . . 44

5.3 Test de pénétration des images dockers . . . . . . . . . . . . . . . . . . . . . 50

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

43
Introduction
Durant ce chapitre nous allons attaquer les tests de pénétration des applications et des images
docker.

5.1 Backlog de Sprint3

TABLE 5.1 – Backlog de Sprint3

5.2 Test de pénétration des application

Il y a deux types de vulnérabilités ou des bugs ;
✱ Bugs techniques
✱ Bugs logiques

5.2.1 Bugs techniques

Les bugs techniques, sont des défauts dans un logiciel ou tout système informatique. Ces bugs
peuvent entraîner des comportements indésirables, des dysfonctionnements ou des pannes dans
le système.

5.2.1.1 Exemples de bugs techniques

notre premier exemple d’attaque :

✱ SQL Injection :
L’injection SQL est une faille qui se produit lorsqu’un attaquant peut manipuler les requêtes de
base de données d’une application en insérant du code SQL malveillant. Cette vulnérabilité sur-
vient lorsqu’une application ne valide pas correctement ou ne désinfecte pas les entrées utilisa-
teur avant de les utiliser dans des instructions SQL.
Les conséquences d’une attaque réussie par injection SQL peuvent être graves. Il peut effec-
tuer des actions non autorisées, telles que récupérer, modifier ou supprimer des données de la

44
base de données. Ils peuvent également augmenter leurs privilèges, exécuter des commandes
arbitraires, voire prendre le contrôle complet du système.
Scénario réel d’exploitation :
Vulnérabilté détectée :

FIGURE 5.1 – Injection de la quote au paramètre id

Dans l’URL (http ://www.*****.com/product2.php ?id=1), le paramètre id semble être le pa-

ramètre vulnérable sensible à l’injection SQL, comme l’indique la capture d’écran ci-jointe, on
a ajouté un quotte «’» encodé(%27) pour vérifier la dynamicité du paramètre id avec la base de
données.

FIGURE 5.2 – Vérification de l’interaction du paramètre id avec la base de données

La réponse de la requête «Vous avez une erreur dans votre syntaxe SQL ; consultez le manuel

45
qui correspond à la version de votre serveur MySQL pour la bonne syntaxe à utiliser près de ”
AND producttype_status=1 ORDER BY producttype_sort asc’ à la ligne 1» confirme l’interaction
avec la base de données.
On peut exploiter cette vulnérabilité en injectant du code SQL malveillant dans le paramètre
id pour manipuler la requête SQLexécutée par le serveur. Par exemple, si le code côté serveur
construit une requête SQL on peut ajouter du code SQL malveillant au paramètre id pour modi-
fier le comportement de la requête, et en résultat on a eu le nom de la Base de données (BD).

FIGURE 5.3 – Injection du code SQL dans la requête

Grâce au nom de la BD obtenus, on a pu extracter les différentes colonnes de la table ck_user_admin

de la DB.

FIGURE 5.4 – Extraction de la table admin

notre deuxiéme exemple d’attaque :

✱ XSS (Cross-Site Scripting)-Reflected :
C’est une vulnérabilité de sécurité courante dans les applications Web. Elle permet à un attaquant
d’injecter du code malveillant (généralement du code JavaScript) dans les champs de saisie ou
les paramètres d’URL des pages Web consultées par d’autres utilisateurs. Cela se produit lorsque

46
l’application Web n’effectue pas une validation ou un filtrage adéquat des données fournies par
l’utilisateur.
Lorsque d’autres utilisateurs consultent ces pages, le code malveillant est exécuté dans leur
navigateur, ce qui permet à l’attaquant d’exploiter des informations sensibles, de compromettre
des sessions utilisateur, d’effectuer des actions non autorisées, ou même de propager davantage
d’attaques.
Scénario réel d’exploitation :
Vulnérabilté detectée : Le XSS réfléchi (également appelé XSS non persistant) se produit lorsque
les données fournies par l’utilisateur sont immédiatement renvoyées par le serveur dans la ré-
ponse, sans nettoyage ni validation appropriés. Dans ce cas, la charge utile <img src=q oner-
ror=prompt(8)> est injectée dans le paramètre d’URL id, puis renvoyée dans la réponse. Lorsque
le navigateur interprète la réponse, il exécute le code JavaScript dans l’attribut onerror, déclen-
chant la boîte de dialogue d’invite.
Lorsqu’un utilisateur visite une page avec cette vulnérabilité et que l’image spécifiée ne se
charge pas, la fonction JavaScript prompt(8) est exécutée, affichant une boîte de dialogue avec
le message "8". Il s’agit d’un exemple simple qui peut être utilisé pour exploiter des informations
sensibles, effectuer des actions au nom de l’utilisateur ou diffuser des logiciels malveillants.

FIGURE 5.5 – Injection du code JavaScript dans le paramètre d’URL

5.2.2 Bugs logiques

Ce sont des défauts de conception et de mise en œuvre d’une application qui permet à un
attaquant de manipuler la logique de l’application c’est un problème où l’application ne fonc-
tionne pas comme prévu dans un état spécifique.

47
5.2.2.1 Exemples de bugs logiques

notre premier exemple d’attaque :

✱ Broken Access Control :
Élévation des privilèges utilisateur(User privilege escalation) : un attaquant peut être en mesure
d’élever ses privilèges au sein du système, d’accéder à des informations sensibles ou d’effectuer
des actions réservées aux utilisateurs privilégiés.
Accès non autorisé aux ressources (Unauthorized access to resources) : cela peut inclure l’ac-
cès aux comptes, aux données sensibles ou aux fonctionnalités administratives d’autres utilisa-
teurs.
Scénario réel d’exploitation :
Vulnérabilté detectée : Notre application est une application bancaire donc on a plusieurs utili-
sateurs dont chacun à des spécifiques préviléges :
✱ Participant-1 :gestion des problémes reportés par les utilisateurs ( prévilége acquis par
l’admin)
✱ Admin
Vulnérabilté detectée :
La vulnérabilité de contrôle d’accès interrompu, permettant aux participants de supprimer
d’autres participants sans autorisation appropriée. Dans ce cas, les participants ont la possibilité
de supprimer d’autres participants, ce qui peut entraîner un accès non autorisé, une perte de
données et une interruption de la fonctionnalité de l’application.
Cette vulnérabilité se produit lorsque l’application ne parvient pas à appliquer les contrôles
d’accès appropriés, permettant aux utilisateurs non autorisés d’effectuer des actions au-delà de
leurs privilèges prévus.

FIGURE 5.6 – Suppression du participant

48
 FIGURE 5.7 – Ajout du participant

notre deuxiéme exemple d’attaque :

✱ Insecure Direct Object References (IDOR) :
Des références d’objets directes non sécurisées se produisent lorsqu’une application expose des
références directes à des objets ou ressources d’implémentation internes, tels que des fichiers,
des enregistrements ou des clés de base de données. Ces références peuvent être manipulées par
un attaquant pour accéder à des informations non autorisées ou sensibles. Contrairement aux
vulnérabilités de contrôle d’accès traditionnel, IDOR se concentre sur le référencement direct
des objets.
Vulnérabilté detectée : Notre application bancaire a plusieurs utilisateurs dont chacun à des
spécifiques privilèges :
Admin : création du projet et ajout de chef d’agence sur ce projet.
Chef d’agence : ajout d’une équipe(ensemble d’utilisateurs).
User : utilisateur simple qui est ajouté par le chef d’agence.
Chaque utilisateur à son propre identifiant (ID) lors de la création du compte L’admin peut créé
des projets et peut affecter un chef de projet à ces projets.
L’application contient une vulnérabilité IDOR (Insecure Direct Object Reference) qui permet
à un attaquant de forcer brutalement l’identifiant de compte avec l’ID de projet et obtenir po-
tentiellement un accès non autorisé à des informations sensibles ou d’effectuer des actions non
autorisées.

49
 FIGURE 5.8 – Test de la liste généré de projectId

FIGURE 5.9 – Exploitation du projectId

5.3 Test de pénétration des images dockers

5.3.1 Exemples de vulnérabilités

✱ Insecure permission :

50
- Unrestricted Write access : si les fichiers ou les répertoires du conteneur disposent d’autorisa-
tions définies pour autoriser l’accès en écriture à tous les utilisateurs, cela peut potentiellement
exposer des informations sensibles ou autoriser des modifications non autorisées.

FIGURE 5.10 – Téléchargement du malware

Le répertoire tmp a un accès en écriture permettant à un simple utilisateur d’y ajouter des fi-
chiers ou des scripts malveillants. Si un utilisateur privilégié (root) exécute le script malveillant,
cela peut entraîner une élévation de privilèges. ou un simple utilisateur peut créer un script mal-
veillant dans le répertoire /tmp puis l’exécuter afin d’exploiter certaines vulnérabilités du conte-
neur.
- Unrestricted read access : n’importe qui peut voir le contenu des fichiers contenant des
informations sensibles.

FIGURE 5.11 – Accès de lecture des fichiers non autorisé

Ces fichiers contiennent des informations sensibles et des données confidentielles. Cepen-
dant, ces fichiers ont des autorisations de lecture qui permettent à quiconque de voir leur contenu.
- Unrestricted execute access : n’importe qui peut exécuter des fichiers exécutables, ce qui
pose des risques de sécurité tels que l’exécution non autorisée.

FIGURE 5.12 – Accès d’exécution des fichiers non autorisé

51
 FIGURE 5.13 – Création non autorisée des utilisateurs

le script "add-user.sh" est un outil utilisé pour ajouter de nouveaux utilisateurs à une instance
de serveur JBoss Wildfly, en particulier aux groupes "Management User" ou "Application User".
Cependant, entre les mains d’un simple utilisateur, ce script a un accès d’exécution non sécurisé
et il pourrait être utilisé pour ajouter des utilisateurs non autorisés au serveur et potentiellement
accéder à des informations sensibles ou effectuer des actions malveillantes.
✱ Privilege escalation :
L’élévation directe des privilèges dans un conteneur Docker fait référence à l’exploitation d’une
vulnérabilité dans l’environnement du conteneur, en particulier la version 5.15.0 du noyau Linux
non sécurisé et vulnérable à un exploit connu sous le nom de "dirty pipe", permet à un attaquant
d’élever ses privilèges d’un utilisateur disposant de privilèges inférieurs à l’utilisateur root dans
le conteneur.
En tirant parti de cette vulnérabilité, l’attaquant peut contourner l’isolation du conteneur et
obtenir un accès illimité au conteneur, compromettant potentiellement le système hôte.
Privilege escalation :

FIGURE 5.14 – Avoir la version de Linux kernel

Après avoir accédé au conteneur, on a exécuté la commande «uname –a» pour savoir la ver-
sion de Linux kernel, qui est 5.15.0. Dans ce cas, on a utilisé l’outil «LinPEAS» pour avoir les CVEs

52
exploitable qui affecte ce kernel.
La vulnérabilité DirtyPipe a été détecté.

FIGURE 5.15 – Détection du "DirtyPipe"

Exploitation deCVE-2022-0847 (DirtyPipe) :

C’est une vulnérabilité du noyau Linux depuis la version 5.8. Il permet aux processus non privi-
légiés d’écraser les données dans les fichiers en lecture seule, ce qui entraîne une élévation des
privilèges.

FIGURE 5.16 – Exploitation du "DirtyPipe"

53
 Le user keycloak est un utilisateur «non-root» sans privilèges, on a exploité cette CVE par
l’outil «TRAITOR» : C’est un outil d’exploitation des vulnérabilités et des erreurs de configuration
facilement accessibles pour l’élévation des privilèges

Conclusion
Les tests de pénétration sont le plus haut niveau de sécurité, elle s’impose sur les skills en
développement et en sécurité pour détecter des vulnérabilités assez risker sur nos systèmes et
images.

54
 CONCLUSION GÉNÉRALE

Our conclure, nous avons effectué un stage de fin d’études au sein de la société VERMEG

P à Tunis. Lors de ce stage, nous avons pu mettre en pratique nos connaissances théo-
riques acquises durant la formation à ESPRIT , tout en étant confronté aux difficultés
réelles du monde du travail et du management d’équipes.
Ce stage a été très enrichissant, car il nous a permis de découvrir le domaine du Sécurité. Il
nous a permis de participer concrètement à ses enjeux à travers notre mission.
Le But de ce travail était de Mettre en place une chaine de sécurité pour les applications
digitales.
Nous avons commencé par l’installation des outils en premier lieu, puis nous avons bien mai-
trisé l’utilisation de ses outils et nous avons utilisé des pipelines de scan sur Jenkins et des scripts
exécutables sur les VMs et par les résultats d scan nous avons pu suivre les métriques de sécurité
et supporter les équipes pour les correctifs et bien sûr résoudre les problèmes d’administration.
Enfin nous avons réalisé des tests de pénétration des applications et des images docker.
Toute application passe par un scan SonarQube pour s’assurer de sa qualité de code source et
puis ce code source se scan par Fortify pour assurer sa sécurité contre les défauts de code et puis
un scan Sonatype NexusIQ pour détecter tout composant open source malveillant et enfin l’ap-
plication passe au test de pénétration pour détecter tout types de vulnérabilité qui peut menacer
nos systèmes et images docker.
À la fin de cette démarche nous pouvant livrer un produit totalement sécurisé a nos clients,
assurant leur protection contre les exploitations et les attaques de sécurités.
La perspective de notre projet, est de réaliser une application de suivi automatique accessible
par les équipes de développement et permet de les notifier en cas d’augmentation de nombre de
vulnérabilités.

55
 En effet, nous gardons de ce stage un excellent souvenir, il constitue désormais une expé-
rience professionnelle valorisante et encourageante pour l’avenir.
Nous pensons que cette expérience nous a offert une bonne préparation à notre insertion
professionnelle car elle fut une expérience enrichissante et complète.
Enfin, nous tenons à exprimer la satisfaction d’avoir pu travailler dans de bonnes conditions.

56
 RÉFÉRENCES BIBLIOGRAPHIQUES

[1] Software, Digital for Finance, and Insurance. Bienvenue chez vermeg. <https://www.
jobteaser.com/fr/companies/vermeg, 2014. [En ligne ; accès le 10-avril-2019].

[2] Coralie Meynier. Le match : « cycle en v » vs scrum, quelle méthode choisir ? <https:
//islean-consulting.fr/fr/organisation-dsi/cycle-en-v-scrum-que-choisir/,
2016.

[3] Pascal Roques. UML2 Modéliser une application Web. Éditions Eyrolles, 2017.

[4] L’équipe Oracle. Qu’est-ce qu’une machine virtuelle (vm). <https://www.oracle.com/fr/

cloud/definition-machine-virtuelle-vm/#:~:text=Une%20machine%20virtuelle%
20ou%20VM,disque%20dur%20et%20carte%20r%C3%A9seau.

[5] Bastien. Jenkins : définition, fonctionnement, avantages du logiciel open source d’intégra-
tion continue. <https://www.lebigdata.fr/jenkins-definition-avantages, 2017.

[6] Vaadata. Introduction à burp, l’outil dédié à la sécurité des plateformes web. <https://
www.lebigdata.fr/jenkins-definition-avantages, 2019.

[7] wikipedia. Latex. <https://fr.wikipedia.org/wiki/LaTeX, 2023.

[8] Raymond. Sonarqube, un analyseur de code statique. <https://blog.ouidou.fr/

sonarqube-un-analyseur-de-code-statique-b79d78651d52, 2019.

[9] L’équipe Micro Focus. Fortify on demand. <https://www.microfocus.com/fr-fr/

cyberres/application-security/fortify-on-demand, 2023.

[10] L’équipe Sonatype. Nexus iq for scm. <https://help.sonatype.com/iqserver/

integrations/nexus-iq-for-scm#:~:text=Nexus%20IQ%20for%20SCM%20is,work%
20directly%20within%20your%20SCM.

57