TP : Analyse d'images et de projet avec Trivy¶

Objectifs pédagogiques¶

À la fin de ce TP, vous devez être capables de :

installer et utiliser Trivy en local
scanner une image conteneur avec trivy image
scanner un projet avec trivy fs
repérer la différence entre vulnérabilités et misconfigurations
filtrer les résultats et gérer un cas d'ignore raisonné
intégrer Trivy dans une pipeline CI/CD en mode audit puis en mode bloquant

Fil conducteur¶

L'objectif de ce TP est de manipuler Trivy comme un outil DevSecOps simple et concret :

construire une image volontairement imparfaite
scanner cette image
scanner aussi le projet et son Dockerfile
interpréter les résultats
intégrer Trivy dans une pipeline
passer d'un audit non bloquant à un contrôle bloquant

Choix recommandés pour le TP¶

Pour aller vite, prenez une petite application dans un langage simple :

Flask ou FastAPI
Node.js
Nginx avec quelques fichiers statiques

Le plus simple reste souvent une petite app Python ou Node.js avec un Dockerfile volontairement perfectible

Partie 1 : Préparer un projet de démonstration¶

Objectif¶

Créer une image conteneur que Trivy pourra analyser utilement

Travail demandé¶

Créez un petit projet avec :

un Dockerfile
un fichier de dépendances ou manifest si votre langage en a un
au moins un choix technique volontairement discutable pour faire remonter des résultats

Exemples de choix pédagogiques possibles :

image de base ancienne ou peu maintenue
conteneur exécuté en root
dépendance vulnérable
paquets système inutiles

Exemple minimal de Dockerfile imparfait¶

FROM python:3.9-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt

COPY . .
CMD ["python", "app.py"]

Ce Dockerfile est volontairement minimal et peut faire remonter :

des vulnérabilités liées à l'image de base
des vulnérabilités liées aux dépendances
des remarques de configuration selon le contenu réel du projet

Vérifications attendues¶

le projet build correctement
l'image est présente localement
vous avez un tag clair du type trivy-lab:local

Commandes utiles¶

docker build -t trivy-lab:local .
docker images

Partie 2 : Scanner une image conteneur avec Trivy¶

Objectif¶

Découvrir le scan d'image et apprendre à lire les résultats

Travail demandé¶

Lancez un premier scan de l'image construite localement

Commande de base :

trivy image trivy-lab:local

Puis relancez un scan plus ciblé :

trivy image --severity HIGH,CRITICAL trivy-lab:local

Puis un scan en ignorant les vulnérabilités sans correctif disponible :

trivy image --severity HIGH,CRITICAL --ignore-unfixed trivy-lab:local

Ce que vous devez observer¶

Trivy distingue les niveaux de sévérité
certaines vulnérabilités ont une version corrigée disponible
--ignore-unfixed modifie la lecture du risque mais ne fait pas disparaître le problème technique

Questions de synthèse¶

Quelle différence faites-vous entre une vulnérabilité LOW, HIGH et CRITICAL
Pourquoi une vulnérabilité sans correctif ne doit-elle pas être simplement ignorée d'un point de vue sécurité
Pourquoi le scan d'image est-il plus pertinent qu'une simple lecture manuelle du Dockerfile

Partie 3 : Scanner le projet et le Dockerfile¶

Objectif¶

Comparer plusieurs cibles d'analyse

Travail demandé¶

Scannez maintenant le projet local

Commande recommandée :

trivy fs --scanners vuln,secret,misconfig .

Si votre projet contient un Dockerfile ou des fichiers de configuration, observez les résultats de type misconfiguration

Vous pouvez aussi restreindre l'analyse :

trivy fs --scanners misconfig .

Ce que vous devez observer¶

trivy image analyse l'image construite
trivy fs analyse le projet local et ses fichiers
le même projet peut faire remonter à la fois :
des vulnérabilités de dépendances
des secrets
des misconfigurations

Questions de synthèse¶

Quelle différence faites-vous entre trivy image et trivy fs
Dans quel cas scanner le système de fichiers avant même de construire l'image est-il utile
Pourquoi les misconfigurations ne sont-elles pas de même nature que les CVE

Partie 4 : Produire un rapport exploitable¶

Objectif¶

Passer d'une lecture console à un artefact exploitable

Travail demandé¶

Générez au moins un rapport JSON et un rapport SARIF

Exemples :

trivy image --format json --output trivy-image-report.json trivy-lab:local
trivy fs --scanners vuln,misconfig --format sarif --output trivy-fs-report.sarif .

Ce que vous devez observer¶

le JSON est pratique pour l'automatisation et le post-traitement
le SARIF est utile pour l'intégration avec des plateformes et outils de sécurité

Questions de synthèse¶

Pourquoi conserver un rapport en artifact dans une pipeline
Quel format choisiriez-vous pour un humain, pour un script, puis pour une plateforme de sécurité

Partie 5 : Gérer un cas d'ignore sans masquer le problème¶

Objectif¶

Comprendre qu'un ignore est une décision de risque et non un effacement magique

Travail demandé¶

Choisissez une vulnérabilité ou un cas de faux positif et appliquez une stratégie d'ignore raisonnée

Vous pouvez commencer par tester :

trivy image --ignore-unfixed trivy-lab:local

Puis créer un fichier .trivyignore si vous avez un cas justifié dans votre contexte pédagogique

Point d'attention¶

N'utilisez pas .trivyignore pour masquer en masse des résultats gênants

Le but est de comprendre :

quand un ignore peut être justifié
quand il devient une dette de sécurité

Questions de synthèse¶

Quelle différence faites-vous entre --ignore-unfixed et .trivyignore
Pourquoi un fichier d'ignore doit-il être relu et limité dans le temps
Dans quels cas préférer corriger plutôt qu'ignorer

Partie 6 : Intégration CI/CD en mode audit¶

Objectif¶

Automatiser le scan sans bloquer immédiatement toute la chaîne

Travail demandé¶

Ajoutez un job Trivy dans votre pipeline GitLab CI/CD

L'objectif ici est :

de construire l'image
de la scanner
de conserver le rapport
de ne pas échouer immédiatement la pipeline

Exemple minimal GitLab CI/CD¶

stages:
  - build
  - security

build-image:
  stage: build
  image: docker:24-cli
  services:
    - name: docker:24-dind
      entrypoint: ["env", "-u", "DOCKER_HOST"]
      command: ["dockerd-entrypoint.sh"]
  variables:
    DOCKER_HOST: tcp://docker:2375/
    DOCKER_TLS_CERTDIR: ""
  script:
    - docker build -t trivy-lab:$CI_COMMIT_SHORT_SHA .
    - docker save trivy-lab:$CI_COMMIT_SHORT_SHA -o trivy-image.tar
  artifacts:
    paths:
      - trivy-image.tar

trivy-audit:
  stage: security
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  variables:
    TRIVY_NO_PROGRESS: "true"
    TRIVY_CACHE_DIR: ".trivycache/"
  dependencies:
    - build-image
  script:
    - trivy image --input trivy-image.tar --exit-code 0 --format json --output trivy-report.json
  cache:
    paths:
      - .trivycache/
  artifacts:
    when: always
    paths:
      - trivy-report.json

Ce que vous devez observer¶

la pipeline produit un rapport même si des problèmes sont présents
--exit-code 0 permet un audit initial sans blocage
le cache Trivy améliore les exécutions suivantes

Questions de synthèse¶

Pourquoi démarrer en mode audit est-il souvent plus réaliste qu'un blocage immédiat
Pourquoi conserver le rapport en artifact
Pourquoi scanner l'image construite dans la pipeline et non une image supposée équivalente

Partie 7 : Intégration CI/CD en mode bloquant¶

Objectif¶

Transformer Trivy en contrôle réellement applicable dans le pipeline

Travail demandé¶

Ajoutez un second comportement bloquant sur un seuil simple

Exemple :

trivy image --input trivy-image.tar --exit-code 1 --severity CRITICAL

Vous pouvez ensuite durcir progressivement :

d'abord CRITICAL
puis HIGH,CRITICAL
puis éventuellement plusieurs scanners selon le niveau du projet

Ce que vous devez observer¶

la pipeline échoue si le seuil défini est atteint
--exit-code 1 transforme Trivy en garde-fou
le bon seuil dépend du contexte et de la maturité de l'équipe

Questions de synthèse¶

Pourquoi bloquer dès CRITICAL est souvent un bon premier pas
Pourquoi bloquer sur tout dès le premier jour produit souvent du rejet
Quel seuil proposeriez-vous sur main puis sur les branches de travail

Critères de réussite du TP¶

Le TP est réussi si vous pouvez démontrer :

une image locale construite et scannée avec Trivy
un scan image et un scan fs
au moins un rapport exploitable produit par Trivy
un job CI/CD en mode audit
un job CI/CD capable de bloquer la pipeline sur un seuil explicite