Université Mohammed V – Rabat

Ecole Mohammadia d’Ingénieurs

Département Génie Informatique

Génie Informatique Troisième Année

Option TI

Cours de DevSecOps

Atelier 2

Élèves : Encadré par :

TALEB Nawal Pr. A. RETBI
TINAKA Kibalo Jules

Année scolaire : 2023-2024

 Sommaire
1. Introduction
2. Déployer l’application
2.1. Utilisez un conteneur Docker pour votre application.
2.2. Générez l'image de votre application
2.3. Ajoutez l'image à votre registre de conteneurs
3. Utilisez l'image comme service dans votre configuration .gitlab-ci.yml
3.1. Configuration .gitlab-ci.yml
3.2. Analyse des résultats
4. Utilisation de Dast
4.1. Dans la section services de la tâche DAST, utilisez l'alias pour définir le nom d'hôte d'accès au
service
4.2. Exécutez la tâche DAST pour analyser le service déployé à l'aide de l'image Docker
5. ZAP
5.1. Configuration dans .gitlab.ci.yml
5.2. Rapport obtenu
6. BURPSUITE
6.1. Prérequis
6.2. Étapes d'intégration avec Gitlab
6.3. Avantages de l'intégration
6.4. Démarrer un Scan sur le site Owasp
6.5. Créer Gitlab issue
6.6. Affichage des issues sur Gitlab
7. Conclusion

Sommaire 1
 1. Introduction
Ce rapport expose notre expérience et notre apprentissage lors de l'atelier DevSecOps. L'objectif
principal de cet atelier était d'explorer les meilleures pratiques pour intégrer la sécurité dans notre
processus de développement logiciel. Dans un environnement numérique en constante évolution,
nous avons reconnu l'importance d'adopter une approche proactive pour garantir la sécurité de
notre application dès les premières étapes du développement.
Au cours de cet atelier, nous nous sommes concentrés sur des aspects clés tels que l'utilisation de
conteneurs Docker, l'intégration continue avec GitLab CI, ainsi que la mise en œuvre de tests de
sécurité dynamique (DAST) avec Zed Attack Proxy (ZAP).
Ce rapport détaillera notre parcours à travers ces différentes étapes, mettant en lumière les outils
utilisés et les leçons tirées de l'intégration de pratiques DevSecOps dans notre processus de
développement. Nous examinerons comment ces pratiques ont renforcé la sécurité de notre
application tout en préservant l'efficacité opérationnelle et la rapidité de déploiement.

2. Déployer l’application
2.1. Utilisez un conteneur Docker pour votre application.
Dans le cadre de l'atelier DevSecOps, nous avons débuté par la création d'un conteneur Docker
pour notre application Java. Le fichier Dockerfile fourni définit l'environnement de construction
de l'image

FROM maven:3-jdk-8-alpine

VOLUME /tmp
COPY target/*.jar app.jar

ENV PORT 5000

EXPOSE $PORT
ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom -Dserver.port=${PORT}","-ja
r","/app.jar"]

Sommaire 2
 2.2. Générez l'image de votre application
Après avoir défini notre Dockerfile, nous avons automatisé le processus de génération de l'image
Docker à l'aide d'un pipeline GitLab CI. Voici ce que nous avons ajouté au fichier .gitlab-
ci.yml pour cette étape :

variables :
CONTAINER_TEST_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG

build_image:
services:
- name: docker:dind
alias: dind
image: docker:20.10.16
stage: container-scanning
script:
- docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
- docker pull $CI_REGISTRY_IMAGE:latest || true
- docker build --tag $CONTAINER_TEST_IMAGE --tag $CI_REGISTRY_IMAGE:latest .
- docker push $CONTAINER_TEST_IMAGE
- docker push $CI_REGISTRY_IMAGE:latest
needs:
- build_job

Sommaire 3
 2.3. Ajoutez l'image à votre registre de conteneurs
Une fois que l'image de notre application a été générée, nous avons procédé à son ajout dans le
registre de conteneurs. Cette étape assure la centralisation et la gestion efficace de nos images
Docker.

3. Utilisez l'image comme service dans votre

configuration .gitlab-ci.yml
Une fois notre image Docker générée et ajoutée au registre de conteneurs, nous avons intégré
cette image dans notre pipeline GitLab CI en tant que service. Cette intégration permet
d'appliquer des analyses de sécurité sur l'image à chaque étape du processus de développement.

3.1. Configuration .gitlab-ci.yml

Le fichier de configuration .gitlab-ci.yml a été étendu pour inclure un template de sécurité
dédié. La section concernée du fichier de configuration est la suivante :

include:
- template: Security/Container-Scanning.latest.gitlab-ci.yml

container_scanning:
variables:
CS_IMAGE: $CONTAINER_TEST_IMAGE

Sommaire 4
 3.2. Analyse des résultats
Une fois l'analyse de sécurité déclenchée, nous avons examiné les résultats pour identifier toute
vulnérabilité ou problème de sécurité potentiel dans notre image Docker. L'interface graphique
de GitLab CI présente de manière claire et détaillée les résultats de l'analyse, permettant une
action rapide pour remédier aux éventuelles failles de sécurité.

4. Utilisation de Dast
Dans le cadre de notre démarche de sécurité, nous avons mis en œuvre un test de sécurité
dynamique (DAST) pour évaluer la sécurité de notre application déployée à l'aide de l'image
Docker que nous avons générée.

Sommaire 5
 4.1. Dans la section services de la tâche DAST, utilisez l'alias
pour définir le nom d'hôte d'accès au service
La configuration du DAST dans le fichier .gitlab-ci.yml est cruciale pour définir les
paramètres nécessaires à l'analyse de sécurité dynamique. La section pertinente du fichier est
présentée ci-dessous :

dast:
services:
- name: $CONTAINER_TEST_IMAGE
alias: demoApp

variables:
CONTAINER_TEST_IMAGE: "$CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG"
DOCKER_IMAGE: "$CONTAINER_TEST_IMAGE"
DAST_WEBSITE: "http://demoApp:8080/"
DAST_FULL_SCAN_ENABLED: "true"

Cette configuration comprend deux parties essentielles :

1. services: La tâche DAST utilise le service correspondant à notre image Docker en lui
attribuant un alias ( demoApp ). Cet alias est ensuite utilisé pour définir le nom d'hôte d'accès
au service dans les tests de sécurité.

2. variables: Des variables sont définies pour faciliter la configuration du DAST.

CONTAINER_TEST_IMAGE: Spécifie le chemin complet de l'image Docker utilisée

dans le registre de conteneurs.

DOCKER_IMAGE: Alias pour l'image Docker.

DAST_WEBSITE: L'URL de notre application à tester. L'utilisation de l'alias

précédemment défini assure que le nom d'hôte est correctement résolu.

DAST_FULL_SCAN_ENABLED: Indique si un scan complet est activé.

4.2. Exécutez la tâche DAST pour analyser le service déployé à

l'aide de l'image Docker
Après avoir configuré le DAST, nous avons exécuté la tâche pour lancer l'analyse de sécurité
dynamique sur le service déployé. L'interface graphique de GitLab CI offre une visibilité claire
sur l'avancement de la tâche et permet d'accéder facilement aux résultats détaillés du scan.

Sommaire 6
 5. ZAP

Dans le cadre de notre stratégie de sécurité, nous avons configuré et exécuté un scan de sécurité
avec ZAP (Zed Attack Proxy). Cela nous permet de détecter et de remédier aux vulnérabilités
potentielles dans notre application.

5.1. Configuration dans .gitlab.ci.yml

La configuration de ZAP dans le fichier .gitlab-ci.yml définit les paramètres nécessaires pour
lancer le scan de sécurité. Voici la section pertinente du fichier :

variables :
ZAP_WEBSITE: "https://demo.owasp-juice.shop"

run-dast-job:
image: maven:latest
stage: runDASTScanUsingZAP
script:
- apt-get update -qy
- apt-get install -y wget
- wget https://github.com/zaproxy/zaproxy/releases/download/v2.14.0/ZAP_2.14.0_Linux.t
ar.gz
- tar -zxvf ZAP_2.14.0_Linux.tar.gz

Sommaire 7
 - ./ZAP_2.14.0/zap.sh -cmd -quickurl $ZAP_WEBSITE -quickout ../zap_report.html
artifacts:
paths:
- zap_report.html

1. variables: La variable ZAP_WEBSITE spécifie l'URL de l'application à tester avec ZAP.

2. run-dast-job: Cette tâche est définie pour exécuter le scan ZAP. Les points clés sont :

image: Utilise l'image Maven pour exécuter la tâche.

stage: Identifie la phase du pipeline où la tâche doit être exécutée (ici,

runDASTScanUsingZAP ).

script: Contient les commandes à exécuter pour installer ZAP et lancer le scan.

apt-get: Met à jour le système et installe wget.

wget: Télécharge l'archive ZAP.

tar: Extrait l'archive.

./ZAP_2.14.0/zap.sh: Lance ZAP en mode commande, pointant vers l'URL

spécifiée.

3. artifacts: Définit les artefacts générés par la tâche, dans ce cas, le rapport ZAP.

5.2. Rapport obtenu

Après l'exécution du scan ZAP, nous avons obtenu un rapport détaillé sur les vulnérabilités
identifiées dans notre application. Le rapport, présenté ci-dessous, offre une vue complète des
risques potentiels et constitue une ressource essentielle pour prendre des mesures correctives.

Sommaire 8
 6. BURPSUITE
6.1. Prérequis
Accès à Burp Suite Enterprise Edition en tant qu'administrateur.

Accès à l'instance GitLab en tant qu'administrateur.

Rôle de Mainteneur ou Propriétaire pour les projets GitLab où les issues seront créées.

6.2. Étapes d'intégration avec Gitlab

Installation de la version entreprise de BurpSuite

Sommaire 9
 Activation de la licence

Sommaire 10
 Configuration du token d'intégration avec GitLab

Sommaire 11
 • Connexion de Burp Suite Enterprise Edition à GitLab

Se connecter à l'interface administrateur de Burp Suite Enterprise Edition.

Accéder aux paramètres et sélectionner l'option "Intégrations".

Sommaire 12
 Configurer l'intégration en spécifiant l'URL de l'API GitLab et en utilisant le token
d'intégration créé précédemment.

Configuration des options de création d'issues

Activer la création manuelle d'issues depuis Burp Suite Enterprise Edition en sélectionnant
les projets GitLab et les types d'issues disponibles.

Configurer la création automatique d'issues en spécifiant les niveaux de gravité et de

confiance minimum pour déclencher la création d'issues sur GitLab.

Sommaire 13
 6.3. Avantages de l'intégration
Automatisation de la création d'issues : Réduction du temps nécessaire à la création
manuelle d'issues pour chaque vulnérabilité détectée.

Suivi amélioré des vulnérabilités : Facilitation de la communication et du suivi des

problèmes de sécurité détectés par Burp Suite Enterprise Edition.

Cette intégration entre Burp Suite Enterprise Edition et GitLab offre une solution efficace pour
automatiser la gestion des vulnérabilités, renforçant ainsi la sécurité des applications développées

Sommaire 14
 au sein de l'écosystème GitLab.

6.4. Démarrer un Scan sur le site Owasp

Sommaire 15
 6.5. Créer Gitlab issue

Sommaire 16
Sommaire 17
 6.6. Affichage des issues sur Gitlab

Sommaire 18
 7. Conclusion
L'atelier DevSecOps a été une plongée immersive dans l'intégration de la sécurité au sein de
notre processus de développement logiciel. En adoptant des conteneurs Docker, nous avons
assuré la portabilité et la reproductibilité de notre application, simplifiant ainsi le déploiement sur
différentes plates-formes.

L'intégration continue avec GitLab CI a automatisé la construction, les tests et le déploiement,

renforçant l'efficacité tout en introduisant des analyses de sécurité statique via le container
scanning.
Les tests de sécurité dynamique (DAST) ont été intégrés au pipeline, évaluant la sécurité de notre
application avec des attaques simulées. L'utilisation d'aliases a simplifié la configuration,
améliorant la fluidité du processus.

Zed Attack Proxy (ZAP) a enrichi notre boîte à outils de sécurité en automatisant les tests de
sécurité dynamique. Son intégration dans le pipeline nous a permis de détecter et de remédier
rapidement aux vulnérabilités.
Les rapports générés à chaque étape ont été des guides essentiels, offrant une visibilité
approfondie sur les enjeux de sécurité spécifiques à notre application.
En conclusion, cet atelier nous a équipés pour intégrer la sécurité de manière transparente,
renforçant la confiance des utilisateurs et assurant la pérennité de notre application dans un
paysage numérique en constante évolution.

Sommaire 19