Université Mohammed V – Rabat

Ecole Mohammadia d’Ingénieurs

Département Génie Informatique

DEV-SEC-OPS

Sujet

Devoir 2 :

SAST & DAST

Réalisé par : Encadré par :

MOHAMED ECHARFAOUY Pr. A. RETBI
MOHAMED AOUZAL Mme. Q. EL MAAZOUZI

ANNÉE UNIVERSITAIRE 2024-2025

1
 TABLE DES MATIERES
I. Introduction Générale .............................................................................................. 4
II. Partie 1 : SAST .......................................................................................................... 5
1. Introduction .......................................................................................................... 5
2. Atelier 1 : SAST avec le projet [Link]/qamar16/DevSecOps-crash-course-
pygoat sur GitHub................................................................................................................... 5
1. Fork et importation de projet ........................................................................... 5
2. Création du workflow ....................................................................................... 6
3. Explication de la configuration ......................................................................... 7
4. Aperçu de l’outil Bandit .................................................................................... 8
5. Résultats après exécution : ............................................................................. 10
6. Analyse des Résultats ..................................................................................... 12
7. Ajouter des clés par défaut pour les environnements de développement .... 13
8. Améliorations pour éviter les faux positifs ..................................................... 14
9. Les vulnérabilités détectées par bandit avec corrections nécessaires ........... 15
10. Corrections et améliorations du workflow ................................................. 18
11. Nouvelle Configuration : Explication ........................................................... 19
12. Comparaison avec les Configurations Précédentes .................................... 21
13. Améliorations de la Nouvelle Configuration ............................................... 21
14. Résultat de l’exécution de la nouvelle configuration .................................. 22
15. Différentes étapes du workflow : ................................................................ 22
3. Partie 2 : sast avec le projet [Link]/qamar16/DevSecOps-crash-course-
pogota sur gitlab................................................................................................................... 24
1. Importation de projet sur gitlab ..................................................................... 24
2. Fichier de configuration yml ........................................................................... 25
3. Explication de la configuration ....................................................................... 27
4. Pipeline résultat .............................................................................................. 30
5. Rapport généré ............................................................................................... 30
6. Améliorations pour Réduire les Faux Positifs ................................................. 31
7. Rapport après amélioration ............................................................................ 32
8. Rapport sast_scan ........................................................................................... 32
4. Conclusion de la partie sast ................................................................................ 35
III. Partie 2 : DAST ........................................................................................................ 36
1. Introduction ........................................................................................................ 36
2. Atelier 1 dast avec Template sous image docker ............................................... 36
2
 1. Configuration yml ........................................................................................... 36
2. Aperçu de l'analyse DAST (Dynamic Application Security Testing)................. 36
3. Le fichier de configuration yml ....................................................................... 38
4. Description de la configuration ...................................................................... 39
5. Pipeline résultat : ............................................................................................ 43
6. Tableau de bord de sécurité ........................................................................... 43
7. Rapport de sécurité ........................................................................................ 44
8. Rapport généré dans la phase DAST ............................................................... 45
9. Points positifs : ................................................................................................ 46
3. Atelier 2 : dast avec intégration de OWASP ZAP ................................................ 46
1. Aperçu sur OWASP ZAP .................................................................................. 46
2. Exécution ........................................................................................................ 48
3. Configuration du pipeline GitLab pour DAST et ZAP ...................................... 50
4. Configuration yml ........................................................................................... 50
5. Explication de la configuration ....................................................................... 51
6. Détails de la configuration : ............................................................................ 52
7. Rapports générés : .......................................................................................... 53
8. Résultats et rapports....................................................................................... 53
9. Conclusion de l’atelier..................................................................................... 54
4. Conclusion de la partie dast ............................................................................... 55
IV. Conclusion Générale .............................................................................................. 56

3
 I. Introduction Générale
Dans le monde actuel de la transformation numérique, la sécurité des applications est
devenue un enjeu stratégique majeur. Face à des cybermenaces de plus en plus
sophistiquées, il est indispensable de garantir la résilience des systèmes dès les premières
étapes de leur développement. L’approche DevSecOps, qui intègre la sécurité dans chaque
phase du cycle de vie des applications, repose sur des pratiques automatisées permettant de
détecter et de corriger les vulnérabilités rapidement et efficacement. Ce projet s’inscrit dans
cette démarche en mettant en œuvre une stratégie combinée de Static Application Security
Testing (SAST) et de Dynamic Application Security Testing (DAST).
L’analyse SAST se concentre sur l’évaluation statique du code source, permettant de
repérer des vulnérabilités telles que des erreurs de syntaxe, des failles de logique ou encore
des problèmes de sécurité potentiels avant même l’exécution de l’application. De son côté,
l’analyse DAST cible les comportements dynamiques en scannant les applications dans un
environnement d’exécution. L’intégration de l’outil OWASP ZAP, une référence dans les tests
dynamiques de sécurité, a permis d’enrichir cette démarche en simulant des attaques contre
l’application web afin d’identifier des vulnérabilités exploitables comme les failles XSS (Cross-
Site Scripting), les injections SQL ou les mauvaises configurations de sécurité. Ces deux
méthodes complémentaires, orchestrées dans un pipeline CI/CD automatisé, assurent une
couverture globale des tests de sécurité tout au long du développement logiciel.

4
 II. Partie 1 : SAST
1. Introduction
Le développement sécurisé des applications est devenu une priorité dans un contexte
où les cybermenaces sont omniprésentes. Le DevSecOps, qui intègre la sécurité dès les
premières étapes du cycle de vie du développement logiciel, est une pratique essentielle
pour garantir des applications sûres et robustes. Ce rapport met en lumière l'intégration des
outils d'analyse de sécurité statique (SAST) dans les pipelines CI/CD sur des plateformes
comme GitHub Actions et GitLab CI/CD. Nous avons utilisé l'outil Bandit, spécialisé dans la
détection des vulnérabilités spécifiques au code Python, afin d'identifier et d'analyser des
failles potentielles telles que des injections de commandes, des erreurs de désérialisation ou
encore des mauvaises pratiques dans l'utilisation de bibliothèques. Ce processus met en
avant les bonnes pratiques de configuration et les mécanismes permettant de réduire les
faux positifs et d'intégrer la sécurité de manière continue et automatisée dans les pipelines
de développement.
En examinant et en corrigeant les vulnérabilités identifiées par les scans, nous avons
démontré l'importance de l'automatisation dans la détection précoce des failles de sécurité.
Cette approche permet non seulement de renforcer la sécurité des applications mais aussi
d'améliorer l'efficacité des équipes en réduisant les coûts liés aux corrections tardives. Ce
travail se concentre également sur la mise en place de pipelines fonctionnels et adaptés aux
deux plateformes principales que sont GitHub et GitLab, tout en respectant les standards de
sécurité modernes.

2. Atelier 1 : SAST avec le projet [Link]/qamar16/DevSecOps-crash-course-

pygoat sur GitHub
1. Fork et importation de projet
La première étape étant de créer un fork du projet disponible sur GitHub sous l’URL :
[Link]

Une fois fait, on procède à la création du workflow qui sera exécuté par GitHub actions.
L’objectif étant d’intégrer la partie sas du cycle DevSecOps, ainsi que l’intégration de l’outil

5
« bandit » pour analyser le code en statique et détecter s’il y’a des vulnérabilités à corriger
avant de passer à la mise en production du projet en question.

2. Création du workflow
Le workflow nécessaire pour implémenter la partie sast dans le pipeline DevSecOps, se
décline comme suit :
name: Bandit Analysis

on:
push:
branches:
- main
pull_request:
branches:
- main

jobs:
bandit-scan:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3

- name: Setup Python

uses: actions/setup-python@v4
with:
python-version: '3.8'

- name: Install Bandit

run: |
python -m pip install --upgrade pip
pip install bandit

- name: Run Bandit

run: bandit -r pygoat/

Se workflow est contenue dans un fichier sous le nom de [Link], comme est
illustré dans la photo ci-après :

6
 3. Explication de la configuration
Voici une explication détaillée de ce workflow GitHub Actions nommé "Bandit
Analysis" :

a. Nom et Déclencheurs
name: Bandit Analysis
• Ce workflow est nommé "Bandit Analysis" et a pour objectif d'exécuter des analyses
de sécurité du code Python en utilisant l'outil Bandit.
on:
• push:
Ce workflow est déclenché lorsqu’un push est effectué vers la branche main.
• pull_request:
Il est également déclenché lorsqu’une pull request est créée ou mise à jour pour la
branche main.

b. Définition des Jobs

jobs: bandit-scan
• Ce job s’appelle bandit-scan. Il contient l’ensemble des étapes nécessaires pour
exécuter l’analyse de sécurité avec Bandit.

c. Exécution sur une Machine Virtuelle

runs-on: ubuntu-latest
• Le job est exécuté sur une machine virtuelle utilisant le système d'exploitation
Ubuntu (version la plus récente).

d. Étapes du Workflow
1. Checkout du Code
- name: Checkout code
uses: actions/checkout@v3
• Cette étape récupère le code source du dépôt GitHub afin qu'il puisse être analysé.

• Elle utilise une action préconfigurée de GitHub (actions/checkout@v3).

2. Configuration de Python
- name: Setup Python
uses: actions/setup-python@v4
with:
python-version: '3.8'
• Cette étape configure l’environnement Python nécessaire pour exécuter Bandit.

7
 • Elle utilise l'action GitHub actions/setup-python@v4 et spécifie la version Python 3.8.

3. Installation de Bandit
- name: Install Bandit
run: |
python -m pip install --upgrade pip
pip install bandit
• Cette étape installe Bandit, un outil d’analyse statique de sécurité pour le code
Python.
• La commande :
o python -m pip install --upgrade pip : Met à jour pip, le gestionnaire de
paquets Python.
o pip install bandit : Installe Bandit dans l’environnement Python.
4. Exécution de Bandit
- name: Run Bandit
run: bandit -r pygoat/
• Cette étape lance Bandit pour analyser le code source du projet, spécifiquement dans
le dossier pygoat/.
• -r : Signifie "récursivement", pour que Bandit analyse tous les fichiers dans le
répertoire et ses sous-dossiers.

e. Objectif Global
Ce workflow permet :
✓ Automatisation de l'analyse de sécurité : Les analyses de sécurité sont
automatiquement exécutées à chaque modification de code (push ou pull request).
✓ Détection des vulnérabilités : Bandit identifie les failles potentielles dans le code
Python, comme des mots de passe codés en dur, des mauvaises pratiques de gestion
des entrées, etc.
✓ Intégration continue : Ce workflow s’intègre dans une stratégie CI/CD pour garantir
un code sécurisé.
4. Aperçu de l’outil Bandit
Bandit est un outil d'analyse statique conçu spécifiquement pour examiner la sécurité
des projets Python. Il scanne le code source Python à la recherche de vulnérabilités
courantes, fournissant ainsi aux développeurs un moyen rapide et efficace de renforcer la
sécurité de leurs applications.

a. Fonctionnalités principales
i. Analyse de sécurité automatisée :

8
 o Bandit inspecte les fichiers Python d'un projet et détecte les vulnérabilités
potentielles ou les constructions de code risquées, telles que :
▪ Utilisation de fonctions dangereuses comme eval(), exec().
▪ Utilisation de modules non sécurisés comme pickle.
▪ Mauvaise gestion des fichiers YAML avec [Link]().
▪ Problèmes dans l’utilisation de bibliothèques cryptographiques,
comme les hachages non sécurisés (MD5, SHA1).
ii. Rapports détaillés :
o Les résultats de Bandit sont classés par niveau de gravité (faible, moyen,
élevé) et niveau de confiance (faible, moyen, élevé).
o Génération de rapports dans divers formats (TXT, JSON, HTML), ce qui facilite
son intégration dans des pipelines CI/CD.
iii. Flexibilité :
o Les utilisateurs peuvent configurer Bandit pour ignorer certains fichiers ou
règles spécifiques.
o Support pour l’ajout de tests personnalisés adaptés à des besoins particuliers.

b. Importance de Bandit
i. Amélioration proactive de la sécurité :
o Bandit permet de détecter les failles dès la phase de développement,
réduisant ainsi les risques d'exploitation en production.
o Il s’intègre parfaitement dans une stratégie de sécurité "Shift Left", où les
problèmes de sécurité sont traités au plus tôt.
ii. Adapté aux équipes DevSecOps :
o Son intégration facile dans les pipelines CI/CD (GitLab CI, GitHub Actions,
Jenkins, etc.) en fait un outil précieux pour les équipes DevSecOps.
o Permet de normaliser les bonnes pratiques de sécurité dans le cycle de
développement.

c. Avantages de Bandit
i. Spécialisé pour Python :
o Optimisé pour analyser le code Python, avec une connaissance approfondie
des spécificités et vulnérabilités de ce langage.
ii. Simplicité d’utilisation :
o Un simple appel à la commande bandit peut analyser un projet entier.
o Convient aussi bien aux développeurs débutants qu’aux experts en sécurité.

9
 iii. Open Source :
o Gratuit et maintenu par une communauté active, il bénéficie d’une évolution
continue et de contributions externes.
iv. Compatible avec CI/CD :
o Intégration aisée avec des outils comme GitLab CI, GitHub Actions, ou Jenkins
pour une détection automatique des failles à chaque commit.

d. Limites
• Bandit ne couvre que les vulnérabilités liées au code Python. Les problèmes liés à
l’infrastructure ou aux bibliothèques externes doivent être traités par d'autres outils.
• Nécessite une configuration avancée pour ignorer les faux positifs ou inclure des tests
spécifiques.

e. Cas d'utilisation typiques

i. Vérification continue de la sécurité :
o Intégré dans les pipelines CI/CD pour détecter les failles à chaque commit ou
build.
ii. Audits de sécurité :
o Utilisé pour analyser rapidement des projets existants ou des bibliothèques
open source.
iii. Formation à la sécurité des développeurs :
o Permet d’identifier et de corriger des failles courantes dans le code Python.

En résumé, Bandit est un outil essentiel pour tout projet Python qui vise à renforcer la
sécurité et à adopter les meilleures pratiques dès les premières phases du développement.
Son intégration dans les workflows modernes le rend indispensable pour les équipes axées
sur DevSecOps.

5. Résultats après exécution :

Apres exécution du workflow précité sur GitHub actions, Voilà le résultat affiché :

10
11
 6. Analyse des Résultats
a. Vulnérabilités détectées :
➔ [B105: Hardcoded password string]
o Localisation : Ligne 24 (SECRET_KEY) dans le fichier pygoat/[Link]
o Détail : Un mot de passe ou une clé secrète a été codé en dur dans le fichier
source :
SECRET_KEY = "lr66x-a!$km5ed@n5ug!tya5bv!0(qywa1tn!q%3m2nh%xoml"
o Gravité : Faible (Low).
Cela pourrait cependant poser un problème si le code est déployé en
production sans modification.
➔ [B105: Hardcoded password string]
o Localisation : Ligne 169 (SECRET_COOKIE_KEY) dans le fichier
pygoat/[Link].
o Détail : Une autre chaîne codée en dur :
SECRET_COOKIE_KEY = "PYGOAT"
o Gravité : Faible (Low).

b. Actions Correctives
1. Externaliser les secrets dans des variables d'environnement :
Au lieu de coder les mots de passe et clés directement dans le code source, utilisez des
variables d'environnement. Voici comment corriger ces vulnérabilités :

12
 Étape 1 : Modifier le fichier [Link]
• Remplacez les valeurs codées en dur par des lectures depuis des variables
d’environnement :
import os

SECRET_KEY = [Link]("SECRET_KEY", "default-secret-key-for-

dev")
SECRET_COOKIE_KEY = [Link]("SECRET_COOKIE_KEY", "default-
cookie-key-for-dev")
Étape 2 : Définir les variables d'environnement
• Dans votre machine locale ou dans le serveur de production, définissez les valeurs
dans les variables d'environnement :
export SECRET_KEY="votre-cle-secrete"
export SECRET_COOKIE_KEY="votre-cookie-cle"
7. Ajouter des clés par défaut pour les environnements de développement
Dans cette partie on va essayer de décortiquer les étapes nécessaires suivie pour la
configuration des différentes clés déclarée explicitement au niveau du code du projet comme
variables d’environnement.

Dans le rapport généré, la clé précédente a été déclarée explicitement dans le fichier
pygoat/[Link] comme suit :

Voici la partie du rapport généré par le workflow qui discute de cette partie :

13
 Une autre clé déclarée explicitement dans le code du projet est au niveau du même
fichier pygoat/[Link] :

Voici la partie du rapport qui montre que cette clé est déclarée explicitement dans le
code :

Et en procédant de la même démarche comme pour la première clé, on a créé une

nouvelle variable d’environnement comme suit :

8. Améliorations pour éviter les faux positifs

a. Configurer Bandit
On peut utiliser un fichier de configuration pour ignorer les vulnérabilités dans certains
cas de développement :
o Créez un fichier Et :
skips: ["B105"]
14
 b. Ajouter l’option dans le workflow
o Modifier la commande dans le fichier GitHub Actions pour inclure le fichier de
configuration :
- name: Run Bandit with Config
run: bandit -r pygoat/ -c [Link]

En plus de la détection des secrets, le rapport de bandit montre que beaucoup de

vulnérabilité ont été détecté dans le projet, cette vulnérabilité varie en termes de célérité,
dans la partie qui suit, se présente une explication détaillée de chaque vulnérabilité détectée
avec les corrections nécessaire pour chaque vulnérabilité.

9. Les vulnérabilités détectées par bandit avec corrections nécessaires

Voici une analyse des vulnérabilités trouvées dans votre rapport Bandit avec des
explications détaillées et des suggestions de corrections pour chaque type de problème :
➔ [B506:yaml_load]
Description :
• L'utilisation de [Link]() peut permettre la désérialisation d'objets arbitraires, ce
qui pourrait être exploité pour exécuter du code malveillant.
• Exemple dans le rapport :
data = [Link](stream)
Correction :
• Remplacez [Link]() par yaml.safe_load(), qui limite le chargement aux types de
base comme str, int, list, etc.
• Correction :
import yaml
data = yaml.safe_load(stream)

➔ [B303: Use of insecure hash function (MD5)]

Description :
• MD5 est un algorithme de hachage faible qui n'est plus considéré comme sûr en
raison de sa vulnérabilité aux collisions.
• Exemple dans le rapport :
password = md5([Link]()).hexdigest()
Correction :
• Utilisez un algorithme de hachage plus sûr comme SHA-256.
• Correction :
from hashlib import sha256
password = sha256([Link]()).hexdigest()
15
 ➔ [B307: Use of eval() function]
Description :
• eval() exécute du code arbitraire passé sous forme de chaîne, ce qui représente un
risque d'exécution de code malveillant.
• Exemple dans le rapport :
result = eval(expression)
Correction :
• Remplacez eval() par une méthode plus sûre, comme ast.literal_eval(), qui limite
l'évaluation aux types de données de base.
• Correction :
import ast
result = ast.literal_eval(expression)

➔ [B602: subprocess call with shell=True]

Description :
• L'utilisation de [Link] avec shell=True expose votre application à des
attaques d'injection de commandes.
• Exemple dans le rapport :
process = [Link](command, shell=True,
stdout=[Link], stderr=[Link])
Correction :
• Utilisez une liste d'arguments au lieu d'une chaîne de commande et évitez shell=True.
• Correction :
import subprocess
process = [Link](["command", "arg1", "arg2"],
stdout=[Link], stderr=[Link])

➔ [B301: Use of pickle for deserialization]

Description :
• pickle est vulnérable aux attaques d'exécution de code lorsqu'il désérialise des
données non fiables.
• Exemple dans le rapport :
admin = [Link](token)
Correction :
• Si possible, remplacez pickle par un format de sérialisation plus sûr comme JSON.
• Correction :

16
 import json
admin = [Link]([Link]('utf-8'))

➔ [B317: Use of [Link].make_parser]

Description :
• [Link].make_parser est vulnérable à des attaques XML (comme les attaques XXE) si
des données XML non fiables sont traitées.
• Exemple dans le rapport :
parser = make_parser()
Correction :
• Utilisez une bibliothèque sécurisée comme defusedxml pour analyser les fichiers
XML.
• Correction :
from [Link] import make_parser
parser = make_parser()

➔ [B319: Use of [Link]]

Description :
• [Link] est vulnérable à des attaques similaires à celles de
[Link].make_parser lorsqu'il traite des données XML non fiables.
• Exemple dans le rapport :
doc = parseString([Link]('utf-8'), parser=parser)
Correction :
• Remplacez [Link] par une fonction sécurisée de la
bibliothèque defusedxml.
• Correction :
from [Link] import parseString
doc = parseString([Link]('utf-8'))

a. Synthèse des Vulnérabilités et Corrections

Vulnérabilité Cause Solution

B506: [Link] Utilisation Remplacer par yaml.safe_load.

dangereuse de
[Link]

B303: MD5 (hash faible) Utilisation de Remplacer par un algorithme plus sûr
MD5 comme SHA-256.

B307: eval() Exécution de Remplacer par ast.literal_eval pour

17
 code arbitraire limiter les entrées aux types de base.

B602: shell=True dans Injection de Éviter shell=True et utiliser une liste

subprocess commandes d'arguments pour Popen.

B301: [Link] Désérialisation Remplacer par une alternative plus

non sécurisée sûre comme JSON.

B317: [Link].make_parser Vulnérabilité aux Utiliser une bibliothèque sécurisée

attaques XML comme [Link].make_parser.

B319: Vulnérabilité aux Remplacer par

[Link] attaques XML [Link].

b. Résumé :
Le rapport met en lumière des pratiques dangereuses courantes dans la manipulation
des données et l'exécution de commandes. Les corrections proposées utilisent des
alternatives sécurisées ou des bibliothèques spécialisées pour éliminer les risques associés.
Ces ajustements renforceront considérablement la sécurité du code tout en maintenant sa
fonctionnalité.
10. Corrections et améliorations du workflow
Après avoir corriger les vulnérabilités : et apporter les améliorations nécessaires
expliqué précédemment, surtout pour éviter les détections type « false positive », le
nouveau code YML se présente comme suit :

name: CI

on: [push]

jobs:
sast_scan:
name: Run Bandit Scan
runs-on: ubuntu-latest

steps:
- name: Checkout code
uses: actions/checkout@v3

- name: Set up Python

uses: actions/setup-python@v3
with:
python-version: 3.8

- name: Install Bandit

run: pip install bandit

- name: Run Bandit Scan with Metrics

run: bandit -ll -ii -r . -f txt -o [Link]
continue-on-error: true

18
 - name: Display Bandit Report
run: cat [Link]

Le nouveau fichier yml, est en fait enregistré dans un nouveau fichier nommé « main.
Yml », l’objectif derrière la création de ce nouveau fichier au lieu de garder l’ancien fichier
« bandit. Yml » est bien évidement de vire te toucher de près l’importance de cette nouvelle
configuration en comparaison avec l’ancienne configuration, surtout quand a des détections
« false positives ». Ceci est très important dans la mesure de nous permettre de se focaliser
sur les vraies vulnérabilités, plus particulièrement les « ture positives ».

11. Nouvelle Configuration : Explication

Ce workflow GitHub Actions est similaire aux précédents, mais il introduit des
améliorations et options supplémentaires pour l'analyse avec Bandit, notamment la gestion
des faux positifs et la génération de rapports. Voici une analyse détaillée :
a. Nom et Déclencheur
1. name: CI
o Le workflow est nommé "CI", indiquant qu'il fait partie d'un processus
d'intégration continue (CI).
2. on: [push]
o Ce workflow est déclenché à chaque push, quel que soit la branche cible
(contrairement aux configurations précédentes, qui étaient limitées à la
branche main).

b. Jobs et Étapes
3. jobs: sast_scan
o Ce job est nommé "Run Bandit Scan" et s'exécute sur une machine virtuelle
Ubuntu.
4. runs-on: ubuntu-latest
o Le job est exécuté sur la version la plus récente d'Ubuntu.

c. Étapes
1. Checkout code
- name: Checkout code
uses: actions/checkout@v3
• Télécharge le code source du dépôt pour permettre son analyse.

2. Set up Python

19
 - name: Set up Python
uses: actions/setup-python@v3
with:
python-version: 3.8
• Configure un environnement Python, en spécifiant explicitement la version Python
3.8 (similaire aux précédentes configurations).

3. Install Bandit
- name: Install Bandit
run: pip install bandit
• Installe Bandit via pip, permettant son utilisation dans l'environnement.

4. Run Bandit Scan with Metrics

- name: Run Bandit Scan with Metrics
run: bandit -ll -ii -r . -f txt -o [Link]
continue-on-error: true
• Commande Bandit utilisée :

o -ll : Affiche les détails les plus basiques des problèmes détectés (niveau de log
le plus bas).
o -ii : Ajoute des informations détaillées sur les vulnérabilités (comme les
recommandations et CWE associées).
o -r . : Scanne récursivement tout le répertoire (.).
o -f txt : Génère un rapport au format texte.
o -o [Link] : Enregistre le rapport dans un fichier nommé bandit-
[Link].
• continue-on-error: true :
o Permet au workflow de continuer, même si des vulnérabilités sont détectées.
o Cette option est particulièrement utile pour éviter que le pipeline CI échoue à
cause de faux positifs.

5. Display Bandit Report

- name: Display Bandit Report
run: cat [Link]
• Affiche le contenu du fichier de rapport [Link] dans les logs GitHub
Actions.
• Cela permet aux développeurs d'examiner les résultats directement depuis
l'interface.

20
 12. Comparaison avec les Configurations Précédentes

Élément Configurations Précédentes Nouvelle Configuration

Nom du Workflow "Bandit Analysis" "CI" : Général pour une intégration

continue.

Déclencheurs push et pull_request sur push sur toutes les branches.

main

Étapes Standard Code Checkout, Setup Identiques.

Python, Install Bandit

Commande Bandit bandit -r pygoat/ bandit -ll -ii -r . -f txt -o [Link]

(plus détaillée).

Gestion des Faux Non gérée directement. Utilise continue-on-error: true,

Positifs permettant de ne pas bloquer le
pipeline.

Rapport Généré Affichage uniquement dans Génère un fichier rapport (bandit-

les logs GitHub. [Link]).

Affichage des Simple affichage des logs de Affiche le contenu du fichier rapport
Résultats Bandit. dans les logs (plus clair).

13. Améliorations de la Nouvelle Configuration

a. Commande Bandit plus riche :
o La nouvelle configuration ajoute des arguments comme -ll (niveau de log bas) et -ii
(informations détaillées) pour fournir un rapport plus complet.
o Le format -f txt et l'export dans [Link] permettent de conserver les résultats
pour une analyse ultérieure ou un partage.
b. Gestion des Faux Positifs :
o L'option continue-on-error: true empêche le workflow d'échouer en cas de vulnérabilités
détectées. Cela est utile pour éviter que des faux positifs ou des alertes mineures
bloquent le développement.
c. Rapports :
o Contrairement aux configurations précédentes, cette version génère un fichier de
rapport (texte) qui peut être stocké, analysé ou archivé.
d. Couverture :
o Le scan est exécuté sur tout le répertoire (.), ce qui est plus générique que les
configurations précédentes qui se limitaient au répertoire pygoat/.

e. Traitement des Faux Positifs

• Configurations Précédentes :
o Ne gèrent pas explicitement les faux positifs.

21
o Les vulnérabilités détectées peuvent bloquer le pipeline.
• Nouvelle Configuration :
o Utilise continue-on-error: true, permettant au pipeline de continuer malgré les
vulnérabilités détectées.
o Fournit un fichier de rapport ([Link]), qui peut être analysé manuellement
pour valider ou ignorer les résultats signalés.

f. Conclusion
La nouvelle configuration est une version optimisée des précédentes :
• Elle est plus flexible grâce à continue-on-error: true.
• Elle offre des résultats plus détaillés avec des métriques précises.
• Elle génère un rapport exploitable, ce qui améliore la gestion des faux positifs et la
collaboration entre les équipes.

14. Résultat de l’exécution de la nouvelle configuration

Comme est clairement montré dans la photo, cette fois ci, le workflow passe sans
erreurs, ceci est dû au fait que la nouvelle configuration permet d’éviter la détection des
« false positives », aussi bien que la correction des vulnérabilités liées au secrets, en
appliquant bien sur les recommandations afférentes a ceci, il s’agit de supprimer les
déclarations explicites des secrets et les déclarer comme variables d’environnement dans
GitHub.

15. Différentes étapes du workflow :

Voici, une image décrivant les détails de l’exécution des différentes étapes de
l’exécution du workflow main.

22
 Apres avoir apporter les corrections nécessaires on voit clairement que les différentes
étapes du workflow passent sans échecs, ce qui montre bien évidement que les correctifs
apportés au projet marchent très bien et répondent exactement au besoins et nécessités
voulus, et ceci et très important pour justement rendre l’application moins vulnérable.

23
 3. Partie 2 : sast avec le projet [Link]/qamar16/DevSecOps-crash-course-pogota
sur gitlab
L’objectif de cette étape étant d’utiliser cette fois ci gitlab pour bien évidement tacler le
projet en utilisant le pipeline cid. Pour ce faire on doit d’abord importer le projet vie son lien
sur GitHub, vers gitlab et de créer un fichier de configuration yml, le lancer, voir les
vulnérabilités détectées et procéder par la suite à la correction de quelque vulnérabilité.
1. Importation de projet sur gitlab
Comme est déjà vue lors du premier TP, l’importation du projet nécessite le suivie d’un
certain nombre d’étapes, la première étant d’aller sur le bouton « new projet », par la suite
choisir l’option import Project comme illustré ci-après :

Ensuite choisir l’option « repository bu URL »

Entrer l’url du projet dans la zone réservée et cliquer sur cérate Project et c fini !

24
 L’importation in Progress …

Apres que l’importation est finie, le projet apparait comme suit :

Apres avoir créer me projet sur gitlab, vient l’étape de la création du fichier de
configuration yml.

2. Fichier de configuration yml

25
 stages:
- build
- test
- sast_scan
- deploy

variables:
DJANGO_SETTINGS_MODULE: [Link] # Updated with the
correct settings module name
PYTHONUNBUFFERED: 1

build_application:
stage: build
image: python:3.8
script:
- pip install -r [Link]
- python [Link] collectstatic --noinput --
ignore="fonts/*" --verbosity 2 || true
- python [Link] makemigrations || true
- python [Link] migrate || true
artifacts:
paths:
- staticfiles/
- [Link]

test_application:
stage: test
image: python:3.8
script:
- pip install -r [Link]
- python [Link] test || true

sast_scan:
stage: sast_scan
image: python:3.8
script:
- echo "Setting up environment for SAST scan..."
- python --version
- python -m ensurepip --upgrade
- pip install --upgrade pip
- pip install bandit
- echo "Running Bandit SAST scan..."
- bandit -ll -ii -r . -f txt -o [Link] || true
- cat [Link]
artifacts:
paths:
- [Link]
reports:
sast: [Link]
allow_failure: true

deploy_application:
stage: deploy
image: python:3.8

26
 script:
- echo "Skipping deployment stage as it's not critical for
this pipeline."
only:
- main # Deployment happens only on the main branch
allow_failure: true

3. Explication de la configuration
Voici une explication détaillée de la configuration YAML pour GitLab CI/CD :
a. Définition des étapes du pipeline (stages)
stages:
- build
- test
- sast_scan
- deploy
Les différentes étapes de ce pipeline sont :
• build : Étape pour préparer et construire l'application (par exemple, installer les
dépendances, collecter les fichiers statiques, etc.).
• test : Étape pour exécuter les tests de l'application et vérifier son bon
fonctionnement.
• sast_scan : Étape pour effectuer une analyse statique de sécurité (SAST - Static
Application Security Testing) en utilisant l'outil Bandit.
• deploy : Étape optionnelle de déploiement pour mettre l'application en production.
b. Définition des variables globales
variables:
DJANGO_SETTINGS_MODULE: [Link]
PYTHONUNBUFFERED: 1
• DJANGO_SETTINGS_MODULE : Variable d'environnement utilisée par Django pour
localiser le fichier de configuration ([Link]). Ici, elle est définie sur
[Link] (adapté à la structure de votre projet).
• PYTHONUNBUFFERED : Défini à 1 pour désactiver la mise en mémoire tampon de la
sortie Python. Cela garantit que les logs sont affichés en temps réel dans la console.
c. Job : build_application
build_application:
stage: build
image: python:3.8
script:
- pip install -r [Link]
- python [Link] collectstatic --noinput --
ignore="fonts/*" --verbosity 2 || true
- python [Link] makemigrations || true
- python [Link] migrate || true
artifacts:
paths:
- staticfiles/
- [Link]

27
• Étape : Ce job appartient à l'étape build.
• Image Docker : Le job s'exécute dans un conteneur basé sur l'image Docker
python:3.8, qui inclut Python 3.8.
• Script :
o pip install -r [Link] : Installe les dépendances spécifiées dans le
fichier [Link].
o python [Link] collectstatic : Collecte les fichiers statiques de l'application
Django (CSS, JS, etc.) dans un répertoire dédié. Le flag --ignore="fonts/*" évite
les erreurs liées aux fichiers manquants. || true permet au pipeline de
continuer même si cette commande échoue.
o python [Link] makemigrations : Prépare les migrations de base de
données nécessaires (ne bloque pas le pipeline en cas d'échec).
o python [Link] migrate : Applique les migrations pour synchroniser la
base de données avec les modèles Django.
• Artifacts : Les fichiers générés, comme staticfiles/ et [Link], sont
sauvegardés et rendus disponibles pour les étapes suivantes.
d. Job : test_application
test_application:
stage: test
image: python:3.8
script:
- pip install -r [Link]
- python [Link] test || true
• Étape : Appartient à l'étape test.

• Image Docker : Utilise également python:3.8.

• Script :
o pip install -r [Link] : Réinstalle les dépendances.
o python [Link] test : Exécute les tests unitaires définis dans le projet
Django. || true permet de continuer même si des tests échouent.
e. Job : sast_scan

sast_scan:
stage: sast_scan
image: python:3.8
script:
- echo "Setting up environment for SAST scan..."
- python --version
- python -m ensurepip --upgrade
- pip install --upgrade pip
- pip install bandit
- echo "Running Bandit SAST scan..."
- bandit -ll -ii -r . -f txt -o [Link] || true
- cat [Link]

28
 artifacts:
paths:
- [Link]
reports:
sast: [Link]
allow_failure: true
• Étape : Appartient à l'étape sast_scan.
• Image Docker : Utilise toujours python:3.8.
• Script :
o Initialisation : Met à jour pip et installe Bandit, un outil qui analyse le code
Python pour détecter les vulnérabilités.
o Exécution de Bandit : Analyse le code source à la recherche de vulnérabilités
potentielles. Le rapport est généré dans un fichier texte [Link]. La
commande utilise || true pour permettre au pipeline de continuer, même si
des problèmes de sécurité sont détectés.
o Affichage du rapport : Affiche le contenu de [Link] dans les logs.
• Artifacts :
o Sauvegarde le fichier [Link] pour consultation.
o Marque le rapport comme un rapport SAST, compatible avec l'interface
GitLab.
• allow_failure: true : Le job peut échouer sans interrompre le pipeline, car il est
souvent utilisé à titre informatif.
f. Job : deploy_application
deploy_application:
stage: deploy
image: python:3.8
script:
- echo "Skipping deployment stage as it's not critical for
this pipeline."
only:
- main # Déploiement uniquement à partir de la branche
principale
allow_failure: true
• Étape : Appartient à l'étape deploy.

• Image Docker : Utilise encore python:3.8.

• Script : Ce job affiche un message d'attente pour simuler le déploiement.
• only: main : Ce job ne s'exécute que lorsque les commits sont effectués sur la
branche principale.
• allow_failure: true : Le déploiement est facultatif ; une erreur à ce niveau
n'interrompt pas le pipeline.
g. Points Clés et Avantages de Cette Configuration

29
 i. Pipeline Structuré :
o Les étapes du pipeline sont bien définies, avec une séparation claire entre la
construction, les tests, l'analyse SAST et le déploiement.
ii. Flexibilité :
o Les commandes critiques (comme collectstatic, makemigrations)
n'interrompent pas le pipeline grâce à || true.
o Le déploiement est marqué comme optionnel (allow_failure: true).
iii. Analyse de Sécurité Intégrée :
o L'utilisation de Bandit dans l'étape sast_scan permet d'intégrer une
vérification de sécurité automatisée dans le pipeline CI/CD.
iv. Artifacts :
o Les fichiers générés (staticfiles/, [Link], etc.) sont sauvegardés et
peuvent être utilisés par les jobs suivants.
v. Compatible avec Django :
o Les commandes spécifiques à Django (collectstatic, migrate, etc.) sont bien
intégrées.

4. Pipeline résultat
Apres avoir commuter la configuration précitée, le pipeline CI-CD du gitlab s’exécute.
Les différents stages configurés passent sans échecs, comme est bien illustré ci-après :

Le stage sast-scan présente, comme convenue, un rapport détaillé sur les différentes
vulnérabilités que contient le projet.

5. Rapport généré

Dans cette configuration YAML, le stage sast_scan utilise Bandit pour analyser le code
Python à la recherche de vulnérabilités. Cependant, en l'état actuel, il n'inclut pas de
mécanisme explicite pour réduire ou éviter les faux positifs.
Le rapport global généré dans cette étape se décline comme suit :

30
 6. Améliorations pour Réduire les Faux Positifs
Pour réduire les faux positifs, on doit ajuster la configuration :
a. Utiliser un Profil Bandit Personnalisé :
• Bandit permet de définir un profil (--profile) pour inclure ou exclure des tests
spécifiques.
• Exemple : Exclure les tests connus pour générer des faux positifs.
sast_scan:
stage: sast_scan
image: python:3.8
script:
- echo "Setting up environment for SAST scan..."
- python --version
- python -m ensurepip --upgrade
- pip install --upgrade pip
- pip install bandit
- echo "Running Bandit SAST scan with custom profile..."
- bandit -ll -ii --skip B101,B303 -r . -f txt -o bandit-
[Link] || true
- cat [Link]
artifacts:
paths:
- [Link]
reports:
sast: [Link]
allow_failure: true
• --skip : Cette option permet de sauter des tests spécifiques (par exemple, B101 pour
assert ou B303 pour md5()).
b. Utiliser des Directives # nosec dans le Code :
• Pour les faux positifs connus, ajoutez # nosec dans votre code pour indiquer à Bandit
d'ignorer certaines lignes.
• Exemple :
password = md5(input_password.encode()).hexdigest() # nosec
• Avantage : Bandit n'inclura pas cette ligne dans son rapport.
31
 c. Utiliser l'Option --confidence :
• Vous pouvez ajuster le seuil de confiance des résultats pour afficher uniquement ceux
avec un niveau de confiance élevé.
• Exemple :
bandit -ll --confidence high -r . -f txt -o [Link] ||
true
• Cela limite les faux positifs en excluant les résultats de faible confiance.
d. Analyser les Résultats Avant Échec du Pipeline :
• Plutôt que de laisser le pipeline continuer à cause de || true, vous pouvez ajouter
une étape pour analyser et filtrer les résultats avant de décider si le pipeline doit
échouer.
• Exemple (analyser uniquement les vulnérabilités graves) :
bandit -ll -r . -f txt -o [Link]
grep -q "High" [Link] || echo "No critical issues
found"

e. Conclusion
Dans la configuration actuelle :
• Le stage sast_scan permet de détecter les vulnérabilités, mais il ne réduit pas
directement les faux positifs.
• Pour éviter les faux positifs, il est recommandé d'ajouter des options comme --skip, --
confidence, ou d'utiliser des directives # nosec dans le code.
7. Rapport après amélioration
Apres cette amélioration, le rapport des vulnérabilités généré contient bien moins de
vulnérabilité, et ceci est dû aux faites que la nouvelle configuration de ce job « généré »
permet de traiter au mieux les « false positives ». Le résultat est alors comme suit :

Les résultats entourés sont ceux qui ont connus des modifications apr. rapport a
l’ancien rapport, après cette dernière rectification.
8. Rapport sast_scan

32
 Le job sast scan est configuré de manière à faire appel à l’outil bandit, comme on a déjà
exploré l’importance de cet outil dans l’analyse des vulnérabilités existant dans un projet
python, on va passer directement à exposer et analyser le rapport généré par cet outil lors
de son exécution dans le cadre du job sast_scan configuré comme stage dans le pipeline CI-
CD.
a. Analyse du rapport bandit avec explication et corrections nécessaires pour
chaque vulnérabilité
Voici une explication de chaque vulnérabilité détectée avec la correction appropriée :
1. [B506: yaml_load]
• Description : L'utilisation de [Link] permet d'instancier des objets arbitraires, ce
qui peut être exploité pour exécuter du code malveillant.
• Correction : Utilisez yaml.safe_load pour charger les fichiers YAML de manière
sécurisée.
• Code corrigé :
import yaml
stream = open('/home/fox/[Link]', 'r')
data = yaml.safe_load(stream)

2. [B307: eval]
• Description : La fonction eval exécute des expressions Python passées sous forme de
chaînes de caractères. Elle est vulnérable à l'exécution de code arbitraire.
• Correction : Utilisez ast.literal_eval, qui évalue de manière sûre des littéraux Python.
• Code corrigé :
import ast
expression = [Link]('expression')
result = ast.literal_eval(expression)
3. [B602: subprocess_popen_with_shell_equals_true]
• Description : L'utilisation de [Link] avec shell=True peut permettre des
attaques d'injection de commande.
• Correction : Désactivez shell=True et transmettez les commandes sous forme de liste.
• Code corrigé :
import subprocess
command = ["ls", "-l"]
process = [Link](command, stdout=[Link],
stderr=[Link])
stdout, stderr = [Link]()

4. [B301: [Link]]
• Description : [Link] peut désérialiser des données non fiables, entraînant
l'exécution de code arbitraire.

33
• Correction : Évitez d'utiliser pickle pour désérialiser des données non fiables. Utilisez
un format sécurisé comme JSON.
• Code corrigé :
import json
admin = [Link](token)
if admin["admin"] == 1:
# Logique de traitement

5. [B317: [Link].make_parser]
• Description : [Link].make_parser est vulnérable aux attaques XML (XXE, entités
externes).
• Correction : Utilisez la bibliothèque defusedxml pour sécuriser l'analyse XML.
• Code corrigé :
from [Link] import make_parser
parser = make_parser()
[Link](feature_external_ges, True)

6. [B319: [Link]]
• Description : [Link] est également vulnérable aux attaques
XML.
• Correction : Utilisez defusedxml pour une analyse XML sécurisée.
• Code corrigé :
from [Link] import parseString
doc = parseString([Link]('utf-8'))

7. [B307: eval (encore)]

• Description : Une autre occurrence de eval. Le problème et la solution sont
identiques à la vulnérabilité 2.
• Correction : Utilisez ast.literal_eval.
• Code corrigé :
import ast
output = ast.literal_eval(val)

8. [B506: yaml_load (encore)]

• Description : Une autre occurrence de [Link]. Le problème et la solution sont
identiques à la vulnérabilité 1.
• Correction : Utilisez yaml.safe_load.
• Code corrigé :

34
 data = yaml.safe_load(file)
b. Résumé des corrections à apporter
1. Remplacer tous les appels à [Link] par yaml.safe_load.
2. Remplacer eval par ast.literal_eval.
3. Remplacer [Link] avec shell=True par des listes de commandes sans
shell=True.
4. Éviter pickle pour désérialiser et utiliser [Link].
5. Utilisez la bibliothèque defusedxml pour tout traitement XML.
Ces changements permettront de sécuriser le code contre les vulnérabilités détectées
et réduiront les risques d'exploitation.

4. Conclusion de la partie sast

Le DevSecOps, en intégrant la sécurité dans chaque étape du cycle de vie du
développement, s’impose comme une stratégie incontournable face aux menaces
croissantes en cybersécurité. Grâce à l’utilisation d’outils comme Bandit, combinés à des
pipelines CI/CD robustes sur GitHub Actions et GitLab CI/CD, nous avons démontré comment
les entreprises peuvent identifier et corriger efficacement les vulnérabilités dans leur code.
L’automatisation de ces processus permet de détecter les failles tôt dans le cycle de
développement, réduisant ainsi les coûts de correction et augmentant la fiabilité des
livrables.
Toutefois, l’intégration réussie de DevSecOps repose sur une adoption continue des
bonnes pratiques, telles que la personnalisation des configurations SAST pour limiter les faux
positifs, l’analyse approfondie des rapports de vulnérabilités, et l’éducation des équipes de
développement sur les principes de sécurité. Ce travail met également en évidence les défis
liés à l'adoption des outils et des configurations optimales, mais prouve que, lorsque ces
outils sont correctement intégrés, ils deviennent des atouts majeurs pour la sécurité des
applications modernes. En conclusion, l’intégration proactive de la sécurité dans les pipelines
DevOps n’est pas seulement une pratique technique, mais une démarche stratégique pour
construire un avenir numérique sécurisé.

35
III. Partie 2 : DAST
1. Introduction

Dans le cadre de l’intégration des pratiques DevSecOps dans notre pipeline CI/CD, la
mise en œuvre de tests de sécurité dynamiques (DAST - Dynamic Application Security
Testing) joue un rôle central. Cette démarche vise à identifier les vulnérabilités de sécurité
au sein des applications web pendant leur exécution. En complément de l’outil DAST natif de
GitLab, nous avons intégré OWASP ZAP, une solution open source reconnue pour son
efficacité dans l'analyse dynamique des applications. Cette configuration permet non
seulement de renforcer la robustesse de nos applications, mais aussi d’automatiser les tests
de sécurité, garantissant ainsi une détection proactive des failles, telles que les injections
SQL, les vulnérabilités XSS ou encore les configurations de sécurité inadéquates.

2. Atelier 1 dast avec Template sous image docker

La première étape de l’atelier consiste à l’importation du projet disponible sur GitHub
sous l’URL : [Link]
pour effectuer ceci, les aptes mentionnées dans la première partie (ci-haut, partie gitlab sast)
seront exécuter successivement et exactement de la même manière, le résultat de
l’importation se décline comme suit :

Une fois importé, l’étape qui suit s’agit bien évidement de la configuration du fichier
yml.

1. Configuration yml
L'objectif est de configurer un pipeline CI/CD intégrant une analyse DAST (Dynamic
Application Security Testing) afin de mieux comprendre et apprécier l'importance de cette
étape dans le domaine du DevSecOps. Ce processus vise à détecter les vulnérabilités de
sécurité dans les applications en temps réel, en les testant dans un environnement
opérationnel. L'intégration de DAST dans un pipeline CI/CD permet de renforcer la sécurité
des applications dès les phases initiales du développement, contribuant ainsi à livrer des
logiciels robustes et conformes aux exigences de sécurité.
2. Aperçu de l'analyse DAST (Dynamic Application Security Testing)

36
 L’analyse DAST (Dynamic Application Security Testing) est une méthode de test de
sécurité qui consiste à analyser les applications en cours d'exécution pour détecter des
vulnérabilités exploitables dans un environnement opérationnel. Contrairement aux outils
SAST (Static Application Security Testing) qui examinent le code source, DAST effectue des
tests "dynamiques" en simulant des attaques comme le ferait un attaquant.
a. Objectif principal :
• Identifier les vulnérabilités de sécurité dans une application en cours d'exécution,
telles que les failles XSS (Cross-Site Scripting), les injections SQL, ou les mauvaises
configurations.
• Garantir la sécurité des applications avant leur mise en production.
b. Importance et utilité :
i. Détection des vulnérabilités en temps réel :
o Permet de tester l’application dans un environnement réel, proche de celui de
production.
ii. Validation des mesures de sécurité :
o Vérifie que les configurations et les contrôles de sécurité (comme
l’authentification et les autorisations) fonctionnent correctement.
iii. Réduction des risques :
o Diminue les chances d'exploitation par des attaquants après le déploiement
de l’application.
c. Caractéristiques principales :
i. Analyse en boîte noire :
o Ne nécessite pas l’accès au code source de l’application.
o Simule les actions d’un attaquant externe.
ii. Approche dynamique :
o Analyse l'application lorsqu'elle est en cours d'exécution, en interagissant avec
ses interfaces.
iii. Portée étendue :
o Peut détecter des vulnérabilités liées à l’environnement, aux services tiers ou
aux erreurs de configuration.
d. Avantages :
• Indépendance du code source : Convient aux applications écrites dans différentes
technologies ou dans des environnements complexes.
• Réduction des faux positifs : Les vulnérabilités identifiées sont exploitables, ce qui
garantit une précision élevée.
• Tests réalistes : Simule des attaques réelles pour évaluer la robustesse de
l’application face à des menaces externes.
• Complémentarité avec d'autres tests : Combine bien avec SAST pour une couverture
complète des vulnérabilités.
37
 e. Limitations :
i. Accès limité à l'intérieur de l'application :
o Ne peut pas identifier les vulnérabilités liées à la logique métier ou au code
source.
ii. Tests dépendants de l'environnement :
o Les résultats peuvent varier selon l’environnement de test utilisé.
iii. Nécessité de configurations spécifiques :
o Des erreurs de configuration dans les tests DAST peuvent entraîner des faux
négatifs ou omettre certaines vulnérabilités.
iv. Délai de test :
o Les tests dynamiques peuvent être plus longs à exécuter, ce qui peut ralentir
le pipeline CI/CD si non optimisé.
f. Conclusion :
L'analyse DAST est un outil essentiel dans le cadre du DevSecOps, car elle permet de
sécuriser les applications en détectant des vulnérabilités critiques en temps réel. Bien qu'elle
présente certaines limitations, son intégration dans un pipeline CI/CD permet de renforcer la
sécurité globale des applications, en particulier lorsqu'elle est utilisée en complément
d'autres tests comme SAST et les tests de pénétration.
3. Le fichier de configuration yml
La configuration yml que nous proposons dans ce cas se décline comme suit :
stages:
- build
- test
- docker
- dast

# Build the jar

build_application:
stage: build
image: maven:3.8-openjdk-11
script:
- mvn clean package -DskipTests
artifacts:
paths:
- target/*.jar

# Run tests
test_application:
stage: test
image: maven:3.8-openjdk-11
script:
- mvn test
artifacts:
paths:
- target/*-reports/TEST-*.xml

38
 # Build and push docker image
docker_image:
stage: docker
image: docker:latest
services:
- docker:dind
variables:
DOCKER_TLS_CERTDIR: ""
script:
- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD
$CI_REGISTRY
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
artifacts:
paths:
- [Link]
when: always

# DAST scan
dast_scan:
stage: dast
image: [Link]/gitlab-org/security-
products/dast:latest
variables:
DAST_WEBSITE: [Link]
DAST_FULL_SCAN_ENABLED: "true"
DAST_HTML_REPORT: "true"
services:
- name: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
alias: app
script:
- curl -s [Link] || (echo "Target application is
not accessible" && exit 1)
- /analyze
- cp /app/zap/[Link] [Link] || echo "No DAST
HTML report generated"
artifacts:
paths:
- [Link]
- [Link]
reports:
dast: [Link]
only:
- main

4. Description de la configuration
Cette configuration GitLab CI/CD est destinée à automatiser les étapes de construction,
de test, de création d'image Docker et de tests de sécurité dynamique (DAST) pour une
application web. Elle repose sur une structure bien définie de pipelines visant à garantir à la
fois la qualité fonctionnelle et la robustesse sécuritaire du code.
a. Structure et rôles des étapes principales :
Étape 1 : Build
39
 • Objectif : Compiler le code source et générer un fichier exécutable .jar.
• Environnement : Utilise une image Docker contenant Maven et Java 11 (maven:3.8-
openjdk-11).
• Commandes exécutées :
o mvn clean package -DskipTests : Nettoie et compile le projet en générant un
fichier .jar sans exécuter les tests.
• Artefacts générés :
o Le fichier .jar compilé est sauvegardé pour être utilisé dans les étapes
suivantes.
Étape 2 : Test
• Objectif : Exécuter les tests unitaires pour garantir la fiabilité du code.
• Commandes exécutées :
o mvn test : Lance tous les tests unitaires définis dans le projet.
• Artefacts générés :
o Les résultats des tests sont sauvegardés sous forme de fichiers XML pour une
analyse ultérieure.
Étape 3 : Docker
• Objectif : Construire une image Docker contenant l'application et la déployer dans le
registre Docker GitLab.
• Services associés :
o docker:dind (Docker-in-Docker) permet de manipuler Docker dans le pipeline.
• Commandes exécutées :
o Construction de l'image Docker avec la commande :
docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
o Connexion au registre GitLab :

docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD

$CI_REGISTRY
o Déploiement de l'image Docker vers le registre GitLab :

docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

• Artefacts générés :

o L'image Docker est sauvegardée sous forme d'un fichier [Link].

Étape 4 : DAST (Dynamic Application Security Testing)
• Objectif : Analyser la sécurité dynamique de l'application en détectant des
vulnérabilités potentielles dans l'environnement de production simulé.
• Environnement utilisé : Une image Docker contenant l'outil DAST (basé sur OWASP
ZAP).

40
 • Services associés :
o L'image Docker de l'application (créée lors de l'étape Docker) est utilisée pour
déployer temporairement l'application sous l'alias app.
• Variables définies :
o DAST_WEBSITE : URL cible de l'application (dans ce cas, [Link]
o DAST_FULL_SCAN_ENABLED : Active un scan complet pour une couverture
exhaustive.
o DAST_HTML_REPORT : Génère un rapport HTML pour une consultation plus
facile.
• Commandes exécutées :
a. Vérification que l'application est accessible :
curl -s [Link] || (echo "Target application is not
accessible" && exit 1)
b. Exécution du scan DAST avec l'outil intégré :
/analyze
c. Copie du rapport généré :
cp /app/zap/[Link] [Link] || echo "No DAST HTML
report generated"
• Rapports générés :

o Rapport DAST au format JSON ([Link]) et éventuellement HTML

([Link]).
b. Fonctionnement de DAST et types de vulnérabilités analysées :
➔ DAST (Dynamic Application Security Testing) :
DAST est une méthode de test de sécurité qui analyse l'application en temps réel, c'est-
à-dire pendant qu'elle est en cours d'exécution. Contrairement aux analyses statiques (SAST),
qui examinent le code source, DAST s'appuie sur une simulation de l'application pour
identifier les vulnérabilités liées à son comportement dans l'environnement d'exécution.
L'outil intégré (OWASP ZAP, dans ce cas) fonctionne comme un scanner automatique
qui effectue des requêtes HTTP/HTTPS vers l'application cible et évalue les réponses pour
détecter des problèmes de sécurité.
➔ Types de vulnérabilités détectées par DAST :
i. Problèmes de sécurité des en-têtes HTTP :
o Exemple : Absence d'en-têtes de sécurité critiques comme X-Content-Type-
Options, Strict-Transport-Security ou Content-Security-Policy.
o Impact : Ces lacunes peuvent permettre des attaques comme le clickjacking
ou les injections de contenu malveillant.
o Mesures : Configurer correctement les en-têtes HTTP dans le serveur
d'application.
ii. Failles de sécurité liées aux sessions et cookies :
41
 o Exemple : Cookies non sécurisés (Secure, HttpOnly, SameSite absents).
o Impact : Risque d'attaques par vol de session (Session Hijacking).
o Mesures : Renforcer les cookies avec des attributs sécurisés.
iii. Failles de validation des entrées utilisateur :
o Exemple : Injection SQL, XSS (Cross-Site Scripting), ou injections de
commandes système.
o Impact : Permet l'exécution de commandes malveillantes ou l'accès non
autorisé à la base de données.
o Mesures : Mettre en place une validation stricte des entrées utilisateur et
utiliser des requêtes paramétrées.
iv. Exposition de données sensibles :
o Exemple : Réponses contenant des informations sensibles dans les en-têtes ou
le corps des réponses HTTP.
o Impact : Risque de fuite de données (Data Leakage).
o Mesures : Filtrer et masquer les données sensibles dans les réponses.
v. Failles d'authentification et d'autorisation :
o Exemple : Défauts dans la gestion des sessions ou des mécanismes
d'authentification.
o Impact : Permettre à des utilisateurs non authentifiés ou non autorisés
d'accéder à des ressources protégées.
o Mesures : Implémenter un mécanisme d'authentification robuste et limiter les
privilèges d'accès.
vi. Mauvaise configuration de sécurité :
o Exemple : Répertoires exposés, fichiers sensibles accessibles (.git, .env, etc.).
o Impact : Donne des informations aux attaquants sur la structure et les fichiers
sensibles du système.
o Mesures : Désactiver l'accès aux fichiers sensibles et restreindre les
autorisations au serveur.
vii. Attaques liées aux configurations TLS/SSL :
o Exemple : Faible niveau de cryptographie ou prise en charge de protocoles
obsolètes.
o Impact : Risques accrus d'attaque de l'homme du milieu (MITM).
o Mesures : Configurer des protocoles de cryptographie modernes comme TLS
1.2 ou 1.3.

42
 c. Conclusion :
Cette configuration CI/CD démontre une approche complète et moderne pour la
gestion des cycles de développement logiciel, en intégrant des contrôles de qualité et de
sécurité. L’étape DAST, en particulier, représente une valeur ajoutée essentielle, car elle
permet d’identifier les failles de sécurité avant que l’application ne soit déployée en
production. En combinant les tests dynamiques (DAST) avec les étapes de build, de test, et
de déploiement Docker, ce pipeline garantit que l'application est à la fois fonctionnellement
robuste et sécurisée contre les menaces courantes.
5. Pipeline résultat :
Le pipeline résultat de cette configuration est le suivant :

→ On voit que les différents stages du pipeline passent sans échec, cela montre que la
configuration est bien correcte,

6. Tableau de bord de sécurité

Ceci est le tableau de bord de sécurité issu du pipeline GitLab, présentant une vue
historique des vulnérabilités ouvertes dans la branche par défaut au fil du temps. Les points
clés sont :
• Catégories de vulnérabilités : Critique, Élevée, Moyenne, Faible, Info et Inconnue.
• Chronologie : Couvre la période du 2 novembre 2024 au 30 novembre 2024.

43
 • Résultats :
o Le 30 novembre 2024, une vulnérabilité de gravité "Faible" et un résultat dans
la catégorie "Info" ont été détectés.
o Aucune vulnérabilité n’a été classée comme Critique, Élevée, Moyenne ou
Inconnue sur toute la période.
• Tendance : Le statut de sécurité est resté stable, avec des vulnérabilités apparaissant
uniquement à la dernière date.
Ce tableau de bord fournit un aperçu de l'état de sécurité du projet, utile pour suivre et
corriger les risques potentiels.

7. Rapport de sécurité

Ce rapport de vulnérabilité, généré à partir du scan de sécurité « DAST », met en

évidence les points suivants :
• Résumé des vulnérabilités détectées :
o Critiques : 0
o Élevées : 0
o Moyennes : 0
o Faibles : 1
o Info : 0
o Inconnues : 0
• Détail de la vulnérabilité :
o Date détectée : 30 novembre 2024
o Gravité : Faible
o Description : "X-Content-Type-Options Header Missing"
o Identifiant : CWE-693
44
 o Outil utilisé : DAST (Dynamic Application Security Testing)
Ce tableau met en lumière une vulnérabilité mineure qui nécessite une analyse
supplémentaire ("Needs Triage"). Elle est associée à l'en-tête HTTP "X-Content-Type-
Options", souvent utilisé pour réduire les risques liés à l'interprétation incorrecte des types
MIME.
8. Rapport généré dans la phase DAST
L’analyse dast nous donne une idée sur les différentes vulnérabilités de l’application en
mode Dynamic, ceci est très important dans la mesure de nous permettre de savoir les
vulnérabilités pouvant être exploiter par des gens malveillants lorsque l’application est mise
en production.
a. Analyse détaillée des vulnérabilités détecté et les corrections nécessaires pour
chaque vulnérabilité
Voici une analyse détaillée de l’ensemble des vulnérabilités détectées avec les mesures
nécessaires à prendre envers chaque vulnérabilité pour en fin avoir une application robuste
en termes de sécurité surtout en mode dynamique :
Voici un résumé des vulnérabilités détectées et les mesures recommandées pour les
corriger :
➔ X-Content-Type-Options Header Missing
o Description : L'en-tête HTTP X-Content-Type-Options est manquant, ce qui
peut permettre aux navigateurs d'interpréter incorrectement les types MIME
des fichiers, exposant ainsi des risques de type MIME sniffing.
o Endpoints concernés :
▪ [Link]
▪ [Link]

b. Mesures recommandées pour corriger ces vulnérabilités :

➔ Ajouter l'en-tête X-Content-Type-Options :
o Configurez votre serveur web (comme Nginx, Apache, ou votre framework
backend) pour inclure l'en-tête HTTP suivant dans toutes les réponses :
X-Content-Type-Options: nosniff
o Exemple pour Nginx :

add_header X-Content-Type-Options "nosniff";

o Exemple pour Apache :

Header set X-Content-Type-Options "nosniff"

➔ Vérification des fichiers statiques :
o Assurez-vous que tous les fichiers statiques (CSS, JavaScript, images) disposent
d’un type MIME correct configuré dans le serveur.
➔ Tests de validation :

45
 o Après avoir implémenté l'en-tête, utilisez un outil tel que curl ou un scanner
de sécurité pour vérifier que l'en-tête est bien inclus dans toutes les réponses
HTTP.

9. Points positifs :
• L'application semble résistante à plusieurs types d'attaques :
o Aucune vulnérabilité détectée pour SQL Injection, XSS, Remote Command
Execution, et autres failles critiques.
o Bonnes pratiques observées dans les mécanismes de session et de gestion des
cookies.
• Les logs montrent que les plugins ZAP ont été bien chargés, et les scans actifs/passifs
ont couvert de nombreuses vulnérabilités potentielles.
3. Atelier 2 : dast avec intégration de OWASP ZAP
Dans cette partie du projet on va essayer de tacler le projet avec une autre approche
pour mieux comprendre et assimiler l’intégration de l’analyse DAST dans les projets.
l’objectif et étant de se focaliser sur l’analyse DAST avec l’intégration Dun outil fort dans ce
domaine, il s’agit de « OWASP ZAP ».
1. Aperçu sur OWASP ZAP
OWASP ZAP (Zed Attack Proxy) est un outil open source de test de sécurité des
applications web développé par le projet OWASP (Open Web Application Security Project). Il
est conçu pour détecter les vulnérabilités de sécurité dans les applications web de manière
dynamique, en simulant des attaques réelles sur une application en cours d'exécution.
a. Objectifs principaux :
• Identifier les vulnérabilités de sécurité dans les applications web.
• Permettre aux développeurs et aux testeurs de sécurité d’effectuer des analyses de
sécurité sans nécessiter des connaissances approfondies en sécurité.
• Automatiser les tests de sécurité dans des pipelines CI/CD pour une intégration
continue.
b. Fonctionnalités principales :
➔ Scan passif :
o Inspecte passivement les requêtes et réponses HTTP pour détecter des
vulnérabilités sans modifier ou perturber le comportement de l'application.
o Exemple : Vérification des en-têtes de sécurité, détection de fichiers ou
répertoires exposés.
➔ Scan actif :
o Simule des attaques sur l'application pour identifier les vulnérabilités
exploitables.
o Exemple : Injection SQL, XSS (Cross-Site Scripting), inclusion de fichiers, etc.

46
➔ Proxy intermédiaire (Man-in-the-Middle) :
o Fonctionne comme un proxy entre le client et le serveur pour intercepter,
analyser et modifier les requêtes/réponses HTTP.
o Idéal pour tester manuellement les comportements des applications web.
➔ Spidering (Crawling) :
o Explore automatiquement les pages et les ressources d'une application web
pour construire une vue complète de ses endpoints (URL accessibles).
o Utile pour détecter des endpoints oubliés ou non documentés.
➔ Ajout de scripts personnalisés :
o Supporte des langages comme Python ou JavaScript pour automatiser des
scénarios de tests personnalisés.
➔ Tests de sécurité automatisés :
o Intégration dans les pipelines CI/CD pour détecter automatiquement les
vulnérabilités à chaque build ou déploiement.
➔ Rapports de sécurité :
o Génère des rapports détaillés au format HTML, JSON ou XML, contenant les
résultats des scans.
c. Types de vulnérabilités détectées par OWASP ZAP :
➔ Failles d'injection :
o Exemples : Injection SQL, XSS, injection de commandes système.
o Impact : Exécution de commandes non autorisées ou accès à des données
sensibles.
➔ Exposition de données sensibles :
o Exemples : Réponses HTTP contenant des informations sensibles (emails,
tokens, identifiants).
o Impact : Fuite d'informations critiques.
➔ Mauvaise configuration de sécurité :
o Exemples : Absence d'en-têtes HTTP comme X-Content-Type-Options, Strict-
Transport-Security.
o Impact : Exploitation par des attaques de type clickjacking ou injection.
➔ Problèmes d'authentification et d'autorisation :
o Exemples : Session fixation, cookies non sécurisés.
o Impact : Prise de contrôle de sessions utilisateur.
➔ Failles de logique métier :
o Tests personnalisés pour détecter des comportements inattendus dans
l'application (exemple : transactions illégitimes).
47
 ➔ Attaques sur les APIs :
o Vérifie les endpoints des APIs REST ou SOAP pour détecter des vulnérabilités
liées à des injections ou des mauvaises configurations.
d. Points forts :
• Gratuit et open source : Accessible pour tous, y compris les petites entreprises et les
développeurs indépendants.
• Facilité d’utilisation : Interface intuitive et options pour les utilisateurs débutants ou
avancés.
• Personnalisation : Possibilité d’ajouter des plugins ou des scripts personnalisés.
• Intégration avec CI/CD : Compatible avec les pipelines de développement continu
comme GitLab CI/CD, Jenkins, etc.
• Communauté active : Supporté par une large communauté et constamment mis à
jour.
e. Cas d’utilisation typiques :
• Développeurs :
o Tester la sécurité des applications pendant le développement.
o Détecter les failles de sécurité courantes sans avoir besoin de compétences
approfondies en cybersécurité.
• Équipes DevSecOps :
o Automatiser les tests de sécurité dans les pipelines CI/CD pour détecter les
vulnérabilités dès les premières étapes du développement.
• Testeurs de sécurité (pentesters) :
o Utiliser ZAP comme outil complémentaire pour identifier des vulnérabilités
exploitables.
f. Conclusion :
OWASP ZAP est un outil puissant, polyvalent et accessible pour effectuer des analyses
de sécurité dynamiques sur les applications web. Son intégration dans les workflows
DevSecOps et sa capacité à détecter un large éventail de vulnérabilités en font un choix
incontournable pour les développeurs et les testeurs soucieux de sécuriser leurs applications
face aux menaces modernes.
2. Exécution
Dans le cadre de ce travail à faire, l'objectif principal était d'implémenter l'analyse de
sécurité DAST (Dynamic Application Security Testing) dans un pipeline GitLab, ainsi que
d'utiliser l'outil OWASP ZAP pour effectuer une analyse de vulnérabilité sur une application
Web. Voici les étapes clés suivies pour atteindre cet objectif :
a. Clonage du projet et mise en place de l'application
Tout d'abord, nous avons cloné le projet contenant l'application vulnérable en utilisant
la commande suivante :

48
 git clone git://[Link]/ScaleSec/vulnado
cd vulnado
Ensuite, nous avons utilisé Docker Compose pour faire tourner l'application en arrière-
plan, afin de simuler un environnement vulnérable pour l'analyse de sécurité :
docker-compose up
Une fois l'application en cours d'exécution, nous avons vérifié que l'application était
bien disponible à l'adresse [Link]

b. Rendre l'application accessible depuis Internet

Comme OWASP ZAP et le DAST de GitLab nécessitent que l'application soit accessible
via Internet, nous avons utilisé Ngrok pour exposer l'application localement à l'Internet.
Après avoir créé un compte sur Ngrok, nous avons installé l'outil sur notre machine et
ajouté un token d'authentification avec la commande :

curl -sSL [Link] |

sudo tee /etc/apt/[Link].d/[Link] >/dev/null
&& echo "deb [Link] buster
main" | sudo tee /etc/apt/[Link].d/[Link]
&& sudo apt update
&& sudo apt install ngrok

Ensuite, nous avons exécuté Ngrok pour exposer l'application à travers un tunnel HTTP :

ngrok config add-authtoken ******************

ngrok http 1337

49
 Cela a généré une URL publique [[Link] que
nous avons utilisée dans le pipeline pour les analyses de sécurité.

3. Configuration du pipeline GitLab pour DAST et ZAP

Pour implémenter les analyses de sécurité dans GitLab, nous avons utilisé le template
DAST fourni par GitLab et créé un fichier `.[Link]` personnalisé. Ce fichier contient deux
étapes principales :
1. DAST (GitLab's built-in DAST scan): Cette étape est automatiquement configurée
grâce à l'inclusion du template DAST. Elle permet de scanner dynamiquement l'application en
utilisant l'URL fournie par Ngrok.
2. OWASP ZAP (Custom ZAP scan stage) : Nous avons également ajouté une étape
personnalisée pour exécuter une analyse OWASP ZAP sur l'application, en utilisant Docker et
un script personnalisé pour lancer le scanner et générer un rapport.

4. Configuration yml
Voici la configuration yml :

50
 5. Explication de la configuration
Cette configuration GitLab CI/CD définit un pipeline d'intégration et de déploiement
continu avec deux étapes principales liées à des scans de sécurité DAST (Dynamic Application
Security Testing), utilisant GitLab et OWASP ZAP.
a. Déclaration des étapes (stages) :

stages:
- dast
- zap_scan
Deux étapes sont définies dans ce pipeline :
• dast : Étape où le scan DAST de GitLab est exécuté à l'aide de son modèle intégré.
• zap_scan : Étape personnalisée pour exécuter un scan de sécurité avec OWASP ZAP.
b. Inclusion du template GitLab DAST :

include:
- template: [Link]
• Cette ligne inclut un modèle GitLab préconstruit pour les scans DAST.

• Ce modèle contient une configuration standard pour exécuter des scans de sécurité à
l'aide de l'outil DAST intégré dans GitLab.
c. Déclaration des variables globales :

variables:
DAST_WEBSITE: [Link]

51
 • DAST_WEBSITE : Définit l'URL cible pour le scan de sécurité. Ici, l'application web
hébergée est accessible via un tunnel Ngrok.
d. Étape 1 : Scan DAST intégré de GitLab
dast:
stage: dast
variables:
DAST_WEBSITE: [Link]
• Cette étape utilise le modèle intégré GitLab pour exécuter un scan DAST.

• Le modèle analysera l'URL définie pour détecter les vulnérabilités dynamiques

(injections SQL, XSS, etc.).
• Les résultats du scan seront générés et visualisables dans GitLab.
e. Étape 2 : Scan personnalisé avec OWASP ZAP
zap_scan:
stage: zap_scan
image: maven:3.8.5-openjdk-17-slim
script:
apt-get update
apt-get -y install wget
wget
[Link]
4.0_Linux.[Link]
mkdir zap
tar -xvf ZAP_2.14.0_Linux.[Link]
cd ZAP_2.14.0
./[Link] -cmd -quickurl [Link]
[Link]/ -quickprogress -quickout ../zap_report.html
artifacts:
paths:
- zap_report.html

6. Détails de la configuration :
a. Image Docker utilisée :
o maven:3.8.5-openjdk-17-slim : L'image Docker contenant Maven et Java pour
exécuter des commandes, nécessaires pour OWASP ZAP.
b. Installation et téléchargement de ZAP :
o Les commandes téléchargent la version 2.14.0 de OWASP ZAP (outil de scan)
depuis GitHub, la décompressent et la préparent pour l'exécution.
c. Exécution du scan rapide (quick scan) :
o Commande :

./[Link] -cmd -quickurl [Link] -

quickprogress -quickout ../zap_report.html
▪ -cmd : Lance ZAP en mode commande (sans interface graphique).

▪ -quickurl : Spécifie l'URL cible à scanner.

▪ -quickprogress : Affiche la progression du scan.
▪ -quickout : Génère un rapport HTML contenant les résultats du scan.
52
 7. Rapports générés :
o Le fichier zap_report.html est enregistré comme artefact du pipeline. Il
contient les vulnérabilités détectées par ZAP.
a. Vulnérabilités détectées :
Avec cette configuration, OWASP ZAP peut identifier les vulnérabilités suivantes :
➔ Injection SQL : Analyse les points d'entrée des formulaires ou requêtes pour des
injections possibles.
➔ Cross-Site Scripting (XSS) : Détection des scripts malveillants injectés dans les pages
web.
➔ En-têtes HTTP manquants : Vérifie les en-têtes comme X-Content-Type-Options ou
Strict-Transport-Security.
➔ Fichiers et répertoires exposés : Identifie les fichiers accessibles publiquement (ex. :
.git, .env).
➔ Failles liées à l’authentification : Sessions vulnérables, cookies non sécurisés, etc.
➔ Configurations de sécurité faibles : Absence de politiques de sécurité comme CSP
(Content Security Policy).
b. Résumé
Ce pipeline CI/CD exploite deux approches de tests dynamiques de sécurité des
applications :
• L'étape DAST intégrée de GitLab fournit une analyse rapide, automatisée et simple à
intégrer dans des workflows CI/CD.
• L'étape personnalisée avec OWASP ZAP permet un contrôle plus fin, en
téléchargeant et en exécutant un outil reconnu pour sa flexibilité et son efficacité
dans la détection des vulnérabilités web.
Cette combinaison offre un environnement robuste pour détecter et corriger les
vulnérabilités dans les applications web avant leur déploiement en production, tout en
s'alignant sur les bonnes pratiques DevSecOps.
8. Résultats et rapports
Une fois le pipeline GitLab exécuté, un rapport de vulnérabilité a été généré à la fois
par le DAST de GitLab et par l'outil OWASP ZAP. Ce rapport contient des informations
détaillées sur les failles de sécurité identifiées dans l'application.

53
 Le rapport ZAP a été sauvegardé en tant qu'artifact HTML, ce qui nous permet de le
récupérer et de l'analyser pour les vulnérabilités détectées.

9. Conclusion de l’atelier
Ce travail a permis d'implémenter une analyse dynamique de sécurité (DAST) en
utilisant les outils GitLab et OWASP ZAP dans un pipeline CI/CD. Nous avons configuré un
environnement local accessible via Internet à l'aide de Ngrok, et avons utilisé GitLab pour
automatiser le processus de test de vulnérabilité sur l'application cible. Le rapport généré
fournit une vue d'ensemble complète des vulnérabilités de l'application, contribuant ainsi à
l'amélioration de sa sécurité.

54
 4. Conclusion de la partie dast
L’intégration combinée de l’outil DAST de GitLab et de OWASP ZAP dans notre pipeline
CI/CD nous a permis d’instaurer un environnement sécurisé et automatisé pour l’analyse des
vulnérabilités dynamiques des applications web. Grâce à cette approche, nous avons pu non
seulement détecter et documenter efficacement les failles potentielles, mais aussi mettre en
œuvre des mécanismes d’amélioration continue pour la sécurité des applications. Cette
stratégie s’inscrit dans une démarche DevSecOps proactive, favorisant la livraison
d’applications sûres et fiables tout en minimisant les risques en production. L’utilisation
d’OWASP ZAP, couplée aux capacités de GitLab DAST, constitue une solution robuste et
flexible pour répondre aux exigences de sécurité modernes.

55
IV. Conclusion Générale
L’intégration des analyses SAST et DAST dans un pipeline CI/CD constitue une solution
innovante et efficace pour relever les défis croissants de la sécurité des applications. Grâce à
l’analyse SAST, les vulnérabilités présentes dans le code source sont détectées dès les
premières étapes, réduisant ainsi les coûts et les délais liés à leur correction. Parallèlement,
l’analyse DAST, avec l’intégration d’OWASP ZAP, offre une évaluation complète en temps réel
des applications en environnement d’exécution, permettant de détecter des failles difficiles à
identifier dans un contexte purement statique.
L’automatisation de ces processus au sein du pipeline CI/CD a non seulement renforcé
la sécurité des applications, mais aussi favorisé un développement plus agile, en réduisant le
temps nécessaire pour identifier et corriger les problèmes. De plus, la capacité à produire
des rapports détaillés et exploitables a permis une meilleure collaboration entre les
développeurs et les équipes de sécurité. Ce projet démontre ainsi que l’intégration des tests
de sécurité au cœur du cycle de développement logiciel n’est pas seulement un impératif
technique, mais également une nécessité stratégique pour garantir des solutions robustes,
fiables et conformes aux standards de sécurité modernes. En adoptant une démarche
DevSecOps, les organisations peuvent anticiper les menaces et bâtir des applications
résilientes tout en répondant aux exigences de rapidité et de qualité dans un marché
compétitif.

56