TP : Analyse de sécurité avec Trivy dans GitLab CI¶

Ce TP vous fait manipuler Trivy sur une application Node.js conteneurisée déjà existante

L'objectif est de partir d'une image Docker et d'un Dockerfile perfectibles, puis de renforcer progressivement votre pipeline GitLab CI

Objectifs du TP¶

• Utiliser Trivy pour scanner une image Docker avec trivy image
• Utiliser Trivy pour analyser un Dockerfile avec trivy config
• Identifier les vulnérabilités et les problèmes de configuration les plus importants
• Corriger une partie des problèmes détectés
• Intégrer un scan Trivy dans GitLab CI avec cache et seuil de sévérité

Pré-requis¶

• Un dépôt GitLab avec un projet applicatif déjà versionné
• Une application Node.js avec un Dockerfile
• Un fichier .gitlab-ci.yml fonctionnel
• Docker installé en local

Contexte¶

Vous disposez d'une application Node.js déjà prête à être construite en image Docker

Le dépôt contient déjà :

• le code de l'application
• un package.json
• un Dockerfile
• une pipeline GitLab CI minimale

Votre travail consiste à vérifier si l'image produite et le Dockerfile présentent des risques de sécurité, puis à améliorer la situation sans changer l'application elle-même

Point de départ commun recommandé¶

Si vous voulez que toute la classe travaille sur la même base, utilisez un Dockerfile volontairement perfectible comme point de départ

FROM node:16

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .

EXPOSE 3000

CMD ["npm", "start"]

Ce Dockerfile est intéressant pour le TP car il cumule plusieurs points de discussion :

• image de base ancienne
• absence d'utilisateur non privilégié
• usage de npm install au lieu de npm ci
• construction simple mais peu durcie

Si vous utilisez cette base, l'objectif n'est pas de tout réécrire mais de l'améliorer par petites étapes

Étape 1 : Construire et scanner l'image¶

Commencez par produire l'image Docker de votre application

1. Construisez l'image avec un tag explicite
2. Lancez un scan avec trivy image <nom-image>:<tag>
3. Repérez les vulnérabilités HIGH et CRITICAL
4. Identifiez au moins un package vulnérable provenant de l'image de base
5. Repérez si une version corrigée est proposée

Étape 2 : Lire et classer les résultats¶

À partir du rapport console de Trivy :

1. Distinguez ce qui semble venir :
   • de l'image de base
   • d'une dépendance applicative
2. Relevez une vulnérabilité qui vous paraît prioritaire
3. Relevez une vulnérabilité qui pourrait être traitée plus tard
4. Proposez un ordre de traitement réaliste

Étape 3 : Analyser le Dockerfile¶

Analysez maintenant le fichier de build lui-même

1. Lancez trivy config Dockerfile
2. Relevez les alertes liées aux bonnes pratiques Docker
3. Identifiez si le Dockerfile présente par exemple :
   • une image de base trop ancienne
   • l'utilisation implicite de root
   • des choix qui augmentent inutilement la surface d'attaque
4. Faites le lien entre les alertes trivy config et celles de trivy image

Étape 4 : Corriger une première fois¶

Apportez une ou deux corrections simples

Exemples possibles :

• changer le tag de l'image de base
• utiliser une image plus légère ou plus récente
• éviter une instruction risquée dans le Dockerfile

Travail demandé :

1. Modifiez le Dockerfile
2. Reconstruisez l'image
3. Relancez trivy image
4. Relancez trivy config Dockerfile
5. Comparez les résultats avant et après

Étape 5 : Intégrer Trivy dans GitLab CI¶

Automatisez ensuite le contrôle dans votre pipeline

1. Ajoutez un stage scan
2. Créez un job trivy_scan
3. Utilisez l'image aquasec/trivy:latest
4. Définissez TRIVY_CACHE_DIR avec la valeur .trivycache/
5. Ajoutez une section cache pour conserver .trivycache/
6. Dans le script, lancez un scan de l'image Docker avec :
   • --cache-dir $TRIVY_CACHE_DIR
   • --exit-code 1
   • --severity "HIGH,CRITICAL"
7. Ajoutez ensuite l'option --ignore-unfixed pour éviter de bloquer la pipeline sur des vulnérabilités qui n'ont pas encore de correctif disponible
8. Comparez le comportement du job avec et sans cette option

Étape 6 : Faire échouer puis corriger la pipeline¶

1. Exécutez le pipeline avec une image contenant encore des vulnérabilités importantes
2. Observez l'échec du job trivy_scan
3. Corrigez l'image ou le Dockerfile
4. Relancez le pipeline
5. Vérifiez que le pipeline redevient vert ou au moins qu'il remonte moins d'alertes critiques