Maximize Page
Tech & DevOps HubEspace Tech & DevOps: Explorez le monde du Dev, du Cloud et des outils DevOps à travers nos articles et discussions Explore the world of development, the cloud and DevOps tools

Fixer les vulnérabilités Trivy d'une application Java Springboot

Date de l'article:06-09-2026
Trivy CI/CD Spring Boot
Il est important de comprendre comment corriger les vulnérabilités Trivy (du FileSystem et du Scan de l'image Docker) afin de libérer le pipeline au plus vite. Toutes ne peuvent pas toujours être fixées immédiatement et c'est ici que nous explorons donc les différents cas et leurs solutions.
Le contexte Spring Boot et ses dépendances
Spring Boot utilise un dependency management pour gérer automatiquement les versions de nombreuses dépendances utilisées par l'application. Avec : 
<parent> 
    <groupId>org.springframework.boot</groupId> 
    <artifactId>spring-boot-starter-parent</artifactId> 
    <version>3.5.14</version>
    <relativePath/> 
</parent>
Spring Boot (3.5.14) fournit donc un ensemble de versions compatibles entre elles.
Par exemple, lorsque l'on ajoute : 
<dependency> 
    <groupId>org.springframework.boot</groupId> 
    <artifactId>spring-boot-starter-web</artifactId> 
</dependency>
On ne renseigne pas directement la version de Tomcat par exemple.
Spring Boot la fournit via son dependency management
Alors pourquoi "overridé" une version déjà gérée par Spring Boot ?
Un override est généralement utilisé lorsqu'une dépendance gérée par la version actuelle de Spring Boot présente un problème qui nécessite une version plus récente.
Les cas typiques
  • une vulnérabilité de sécurité détectée par Trivy
  • un bug critique, corrigé dans une version plus récente
  • un correctif qui n'est pas encore intégré dans la version utilisée
  • une contrainte temporaire en attendant de pouvoir le mettre à jour
L'idée est donc :
Spring Boot fournit une version par défaut compatible, mais on peut exceptionnellement la remplacer lorsqu'une version plus récente est nécessaire
L'override doit cependant rester volontaire, documenté et contrôlé
La règle générale est d'utilisez les versions gérées par Spring Boot par défaut.
Un override est une exception, généralement justifiée par une vulnérabilité, un bug critique ou une contrainte temporaire. Dès qu'une version de Spring Boot intègre officiellement le correctif, l'override doit idéalement être supprimé.
Dans une application Java conteneurisée, Trivy peut trouver des vulnérabilités à plusieurs niveaux
Docker image
├── OS (Debian, Ubuntu, Alpine...)
├── librairies système
└── application Java
    └── app.jar
        ├── Spring
        ├── Tomcat
        ├── Jackson
        ├── Netty
        ├── Logback
        └── autres dépendances Maven
Et ce sont ces cas que nous allons explorer ainsi que ce à quoi il faut prêter attention en priorité et les questions à se poser.
Les cas d'usage abordés dans cet article:
Vulnérabilité Tomcat
Contexte
En général, tout commence par un job Failed. On reçoit un email, ou on constate que le pipeline ne passe pas la MR/PR
La première chose à faire est donc d'examiner les logs.
Ouvrir le job, examiner le rapport et regarder la Target et la Library concernée.
Les résultats du log indiquent:
  • La version installée: Installed: 10.1.55
  • La librairie touchée: tomcat.embed:tomcat-embed-core
  • La version corrigée: Fixed: 10.1.58 / 11.0.25
Le job "prod-trivy-image"
trivy-image failed
Ici, le problème est dans une dépendance Java embarquée dans l'application
Report Summary
┌───────────────────────────────────┬────────┬─────────────────┬─────────┐
│              Target               │  Type  │ Vulnerabilities │ Secrets │
├───────────────────────────────────┼────────┼─────────────────┼─────────┤
│ flashcards-prod.tar (debian 13.6) │ debian │        0        │    -    │
├───────────────────────────────────┼────────┼─────────────────┼─────────┤
│ app/app.jar                       │  jar   │        3        │    -    │
└───────────────────────────────────┴────────┴─────────────────┴─────────┘
Legend:
- '-': Not scanned
- '0': Clean (no security findings detected)

Java (jar)
==========
Total: 3 (HIGH: 0, CRITICAL: 3)
┌─────────────────────────────────────────────────────┬────────────────┬──────────┬────────┬───────────────────┬───────────────────────────┐
│                       Library                       │ Vulnerability  │ Severity │ Status │ Installed Version │       Fixed Version       │
├─────────────────────────────────────────────────────┼────────────────┼──────────┼────────┼───────────────────┼───────────────────────────┤
│ org.apache.tomcat.embed:tomcat-embed-core (app.jar) │ CVE-2026-65182 │ CRITICAL │ fixed  │ 10.1.55           │ 11.0.25, 10.1.58, 9.0.121 │
│                                                     │                │          │        │                   │                           │
│                                                     │                │          │        │                   │                           │
│                                                     ├────────────────┤          │        │                   │                           │
│                                                     │ CVE-2026-65905 │          │        │                   │                           │
│                                                     │                │          │        │                   │                           │
│                                                     │                │          │        │                   │                           │
│                                                     ├────────────────┤          │        │                   │                           │
│                                                     │ CVE-2026-68525 │          │        │                   │                           │
│                                                     │                │          │        │                   │                           │
│                                                     │                │          │        │                   │                           │
└─────────────────────────────────────────────────────┴────────────────┴──────────┴────────┴───────────────────┴───────────────────────────┘
Cleaning up project directory and file based variables
00:01
ERROR: Job failed: exit code 1
Processus de résolution pour la vulnérabilité Tomcat
1. Identifier la dépendance
Ouvrez le fichier pom.xml et rechercher la bibliothèque concernée ("tomcat")
Vous devriez trouver la même version que dans les logs,
Corriger la version en: 
<properties>
    <tomcat.version>11.0.25</tomcat.version>
</properties>
Dans mon cas, 10.1.58 était la correction proposée dans la branche Tomcat 10.1, mais cette version n'était pas disponible dans Maven Central au moment du build.
Le passage à la version 11.0.25 a fonctionné dans l'application et a été validé par les tests et la CI.
Il ne faut donc jamais supposer que la première “Fixed Version” proposée par Trivy est nécessairement la meilleure version à installer.
2. Valider la version depuis le terminal:
./mvnw dependency:tree -Dincludes=org.apache.tomcat.embed
J'utilise le Maven Wrapper dans ce projet, si vous ne l'utilisez pas, remplacez-la par: mvn
$ ./mvnw dependency:tree -Dincludes=org.apache.tomcat.embed

[INFO] Scanning for projects...
[INFO] 
[INFO] -----------------------< com.example:flashcards >-----------------------
[INFO] Building flashcards 1.1.0
[INFO]   from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- dependency:3.8.1:tree (default-cli) @ flashcards ---
[INFO] com.example:flashcards:jar:1.1.0
[INFO] \- org.springframework.boot:spring-boot-starter-web:jar:3.5.14:compile
[INFO]    \- org.springframework.boot:spring-boot-starter-tomcat:jar:3.5.14:compile
[INFO]       +- org.apache.tomcat.embed:tomcat-embed-core:jar:11.0.25:compile
[INFO]       +- org.apache.tomcat.embed:tomcat-embed-el:jar:11.0.25:compile
[INFO]       \- org.apache.tomcat.embed:tomcat-embed-websocket:jar:11.0.25:compile
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
Il faut vérifier: qu'elle est publiée, compatible avec la stack utilisée et disponible dans les repositories Maven configurés.
Trivy proposait plusieurs branches corrigées. Il faut privilégier une version corrigée appartenant à la branche compatible avec le framework utilisé.
3. Faire un rebuild complet
./mvnw clean verify
./mvnw dependency:tree -Dincludes=org.apache.tomcat.embed
Le dependency:tree vérifie la résolution Maven, mais il est utile de vérifier également le JAR final
4. Vérifier que la bonne version est dans le JAR
jar tf target/*.jar | grep "tomcat-embed"
devrait retourner: 
BOOT-INF/lib/tomcat-embed-core-11.0.25.jar
BOOT-INF/lib/tomcat-embed-el-11.0.25.jar
BOOT-INF/lib/tomcat-embed-websocket-11.0.25.jar
Confirme que la version corrigée est effectivement embarquée dans l'application
Après avoir reconstruit le JAR, il faut reconstruire l'image Docker. Sinon, Trivy pourrait analyser une ancienne image contenant l'ancien JAR.
Process 
pom.xml  → Maven  →  target/*.jar   
                          ↓
                    Docker build  
                          ↓
                    Image Docker / .tar
                          ↓
                        Trivy
5. Relancer Trivy
En local si vous avez trivy installé, vous pouvez lancer le même script que dans la CI: 
./ci-scripts/trivy-image.sh flashcards-prod.tar 1 .trivyignore.yaml
ou, directement via la CI/CD:
Le résultat attendu est que la vulnérabilité corrigée ne soit plus présente
Le résultat est déjà visible depuis la branche staging,
  Le job effectue la même commande, avec un exit-code 0
Vulnérabilités Jackson
Jackson, la bibliothèque Java de sérialisation/désérialisation JSON, est fréquemment présent dans les applications Spring Boot
et les vulnérabilités qui y sont liées sont extrêmement courantes dans les rapports Trivy.
Certaines vulnérabilités historiques concernent notamment la désérialisation polymorphique, mais leur exploitabilité dépend fortement de la configuration de Jackson et de la manière dont l'application traite les données non fiables.
En cas de faille, le rapport pourrait indiquer: 
com.fasterxml.jackson.core:jackson-databind
CVE-2020-36518
Severity: HIGH
Installed: 2.x.x
Fixed:     2.x.y
1. Identifier toutes les dépendances Jackson
Identifiez la version: 
./mvnw dependency:tree -Dincludes=com.fasterxml.jackson
Passez en mode debug avec -Dverbose s'il ne trouve pas la bonne version, ou: 
./mvnw help:effective-pom | grep -A2 jackson-databind
#output 
$ ./mvnw help:effective-pom | grep -A2 jackson-databind
        <artifactId>jackson-databind</artifactId>
        <version>2.22.1</version>
      </dependency>
Attention
Ne mettre à jour que "jackson-databind" sans regarder les autres composants peut créer un ensemble de versions incohérent!
Suivant ce qu'il vous est possible de faire, il y a 3 options possibles
2. La résolution (Recommandé)
Si Spring Boot gère Jackson via son BOM, il faut d'abord vérifier si une version plus récente de Spring Boot apporte déjà la correction
Mettre à jour le Framework Parent (Recommandé)
Si Jackson est amené par Spring Boot, mettre à jour Spring Boot vers une version plus récente qui intègre les derniers correctifs de sécurité.
Cela garantit la cohérence globale de l'écosystème
Si la résolution recommandée n'est pas possible, par exemple si la version du framework parent est "bloqué" ou, qu'il n'y a pas de version corrigée disponible, vous utilisez alors l'une des 2 autres options: l'override ou l'option d'ignorer la CVE temporairement.
2. Option A: L'override
Forcer la version de Jackson (Si le parent est bloqué)
Si un override est nécessaire, utiliser de préférence le BOM ou "dependencyManagement" plutôt que de multiplier les versions isolées
Par exemple : 
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.fasterxml.jackson</groupId>
            <artifactId>jackson-bom</artifactId>
            <version>VERSION_CORRIGEE</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>
2. Option B: L'Acceptation du Risque
Gérer le rapport Trivy
Si après analyse, le composant vulnérable n'est pas exposé, on peut documenter et ignorer l'alerte pour ne pas bloquer le pipeline CI/CD
Créez ou modifiez le fichier .trivyignore.yaml à la racine: 
vulnerabilities:
  - id: CVE-2020-36518
    expired_at: 2026-12-05
    statement: Temporary ignore until ...
Notez qu'avec ce format et avec "expired_at:" on peut définir une date d'expiration, il faut donc un peu "surveiller" ou faire des mises à jour dans ce sens.
Trivy considère la version yaml du .trivyignore.yaml comme une fonctionnalité expérimentale dans sa documentation actuelle, et selon la version utilisée, il peut être nécessaire d'ajouter l'option --ignorefile
Dans l'application Flashcards, Spring Boot 3.5.x est arrivé en fin de support open source avec la version 3.5.16, publiée en juin 2026.
Pour passer à Spring Boot 4.0 ou supérieur, les barrières de blocage sont immédiates si je tente de modifier la version du parent, une mise à niveau est prévue d'ici la fin de l'année 2026.
Vulnérabilités Spring Framework
Contrairement à Jackson (failles de désérialisation), les vulnérabilités touchant le cœur de Spring se répartissent généralement sur trois blocs majeurs.
Ces modules appartiennent à la même version de Spring Framework et doivent généralement rester alignés. Forcer individuellement une version peut provoquer des incompatibilités à l'exécution.
Ces vulnérabilités peuvent concerner ces bibliothèques: 
org.springframework:spring-web
org.springframework:spring-webmvc
org.springframework:spring-core
1. Identifier la chaîne
./mvnw dependency:tree -Dincludes=org.springframework
Avant de forcer individuellement une version, vérifier la version de Spring Boot
#pom.xml 
<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>...</version>
</parent>
Règle pratique
Si la vulnérabilité est corrigée par une nouvelle version: 
Spring Boot ancien
       ↓
Spring Framework vulnérable
il est généralement préférable de faire: 
Spring Boot mis à jour
       ↓
Spring Framework corrigé
plutôt que : 
Spring Boot ancien
       ↓
Spring Framework forcé manuellement
Un override manuel peut être utile comme solution temporaire, et il faut le documenter
On force l'ensemble du framework Spring vers une version patchée sécurisée.
À ajuster selon la version corrective cible de la CVE détectée
<spring-framework.version>VERSION_FIXEE</spring-framework.version>
Pour patcher spring-core, spring-web, et spring-webmvc d'un coup, il suffit d'utiliser la propriété maîtresse intégrée par Spring Boot.
Maven alignera automatiquement les versions: spring-core, spring-web, spring-webmvc sur la version renseignée.
Évaluation de l'exposition réelle
La plupart des grandes failles Spring demandent des conditions spécifiques :
L'application accepte-t-elle des données utilisateurs (dans des expressions SpEL)? ou, utilisez-vous des fonctionnalités spécifiques d'envoi/réception Multipart non sécurisées?
Si ces conditions ne sont pas présentes, la vulnérabilité peut être non exploitable dans le contexte de l'application. Cette conclusion doit toutefois être documentée et régulièrement réévaluée.
La gestion des dépendances, un équilibre permanent
Surcharger les propriétés comme <jackson.version> ou <spring-framework.version> permet de maintenir une image Docker propre face aux scans Trivy à court terme
La seule réponse pérenne face à l'obsolescence reste la planification régulière des montées de versions majeures
Vulnérabilités Logback
Si Trivy détecte une vulnérabilité liée à Logback (le framework de journalisation Java couramment inclus dans Spring Boot), voici ce qu'il faut savoir et comment résoudre le problème.
ch.qos.logback:logback-core
ch.qos.logback:logback-classic
Ne pas modifier uniquement `logback-core` sans vérifier `logback-classic`, car ces composants doivent rester compatibles
1. Identifier la version
./mvnw dependency:tree -Dincludes=ch.qos.logback
Puis vérifier si la correction vient :
  • d'une mise à jour de Spring Boot ou de Logback
  • ou d'un override temporaire
2. Ajoutez ou modifiez la propriété pour écraser la version transitivement embarquée par Spring Boot
#pom.xml 
<properties>
    <logback.version>1.5.13</logback.version> <!-- Ou une version supérieure propre, ex: 1.5.19+ -->
</properties>
Problèmes fréquents avec Trivy et Logback
Si Trivy continue de lever l'alerte après la mise à jour, deux cas de figure sont fréquents:
Erreur de détection dans l'image Docker
Si vous scannez une image de conteneur (trivy image), et si Trivy détecte encore l'ancienne version, vérifier d'abord que l'image analysée a bien été reconstruite et qu'elle contient réellement le nouveau JAR. Si nécessaire, vérifier également que les bases de vulnérabilités utilisées par Trivy sont à jour
La solution est de vider le cache avec "trivy clean --all" avant de re-scanner
Trivy can't find installed version when scanning images of SpringBoot app
Faux positif / Problème de base de données
Il arrive que des erreurs typographiques de versions corrigées apparaissent dans les bases de vulnérabilités amont.
Assurez-vous d'exécuter Trivy avec les bases de données de vulnérabilités les plus récentes.
logback-core: TYPO in a dependency fixed version
Vulnérabilité dans l'OS Docker
Trivy peut également trouver : 
Target: debian 13.x
Library: openssl
Severity: HIGH
La correction peut consister à:
  1. mettre à jour l'image de base
  2. Reconstruire l'image
  3. scanner
Dans ce cas, ce n'est pas Maven qui doit être modifié.
Il faut regarder le Dockerfile
La stratégie dépend toutefois de l'image utilisée
Par exemple: FROM eclipse-temurin:17-jre ou: FROM debian:13
* Seulement si nécessaire, installer et/ou mettre à jour explicitement certains packages
Dans l'application Flashcards j'utilise une image distroless,
Comme j'ai souvent des vulnérabilités, j'ai mis en place un pipeline programmé qui vérifie les nouvelles versions du digest de l'image.
Articles en lien: trivy-installation-failed-et-vulnerabilite-sur-l-image-docker | automatisation-complete-de-la-pr-watch-distroless
Pour chaque CVE, se poser ces questions:
La dépendance est-elle réellement utilisée ?
Une librairie peut être présente dans le JAR mais ne jamais être utilisée par le code ou par la configuration.
La fonctionnalité vulnérable est-elle activée/configurée?
Une CVE peut concerner une fonctionnalité particulière : 
DIGEST authentication
FORM authentication
XML parsing
deserialization
file upload
JNDI

Si cette fonctionnalité n'est jamais utilisée, le risque réel peut être différent.
L'application l'utilise-t-elle réellement dans un chemin exploitable ?
C'est particulièrement important pour les frameworks. 
Exemple: CVE → Tomcat DIGEST authentication
Si l'application utilise uniquement: 
OAuth2 / JWT / Basic Auth
et jamais DIGEST, le contexte d'exploitation n'est pas le même.
Par exemple, si une CVE concerne spécifiquement le mécanisme d'authentification DIGEST de Tomcat et que l'application n'utilise pas ce mécanisme, il faut alors analyser si les conditions d'exploitation de la CVE sont réellement réunies.
La correction reste préférable lorsqu'une version corrigée est disponible
Quand utiliser .trivyignore?
Utiliser un .trivyignore ne devrait pas être la première solution!
Mauvaise approche 
Trivy
 ↓
CVE trouvée
 ↓
ajouter la CVE dans .trivyignore
 ↓
pipeline vert
Le problème existe toujours
Approche préférable 
CVE
 ↓
identifier la dépendance
 ↓
chercher une version corrigée
 ↓
mettre à jour
 ↓
tester
 ↓
rebuild
 ↓
Trivy
→ .trivyignore peut être utilisé lorsqu'il existe une justification documentée:
faux positif; vulnérabilité non exploitable dans le contexte; correction non-disponible encore; contrainte temporaire de compatibilité
Documenter la raison de l'exception et lui donner une date de réévaluation.
L'application est-elle exposée ?
Une vulnérabilité sur une fonctionnalité HTTP accessible depuis Internet est généralement beaucoup plus préoccupante qu'une fonctionnalité uniquement accessible depuis un réseau interne.
Regarder : 
Internet
↓
Load Balancer
↓
Application
↓
Spring/Tomcat
versus: 
Réseau interne uniquement
↓
Application
La CVE nécessite-t-elle une authentification ?

Une vulnérabilité exploitable sans authentification est généralement à traiter en priorité

À l'inverse, une CVE nécessitant : 
authentification + rôle particulier + configuration spécifique
a un contexte d'exploitation différent.

Respectez l'ordre de priorité
Pour trier rapidement un rapport Trivy: 
1. CRITICAL + exploitable + exposé Internet
        ↓
2. CRITICAL  + fonctionnalité utilisée
        ↓
3. HIGH  + exploitable + exposé Internet
        ↓
4. HIGH / CRITICAL  nécessitant une configuration particulière
        ↓
5. Vulnérabilité non exploitable dans le contexte
        ↓
6. LOW / MEDIUM

Cette classification sert à prioriser, pas à ignorer automatiquement les vulnérabilités.

HIGH / CRITICAL ne signifie pas automatiquement «exploitable»
Une vulnérabilité non exploitable est une faille existante dans le code ou le package installé, mais les conditions techniques pour qu'un attaquant puisse l'activer ou en profiter ne sont pas réunies dans l'infrastructure.
La gravité est un indicateur de risque, mais il faut également regarder le contexte!
Les commandes essentielles — Cheat Sheet
Identifier une dépendance 
./mvnw dependency:tree -Dincludes=GROUP_ID
Exemples : 
./mvnw dependency:tree -Dincludes=org.apache.tomcat.embed

./mvnw dependency:tree -Dincludes=com.fasterxml.jackson

./mvnw dependency:tree -Dincludes=org.springframework

./mvnw dependency:tree -Dincludes=ch.qos.logback
Voir toutes les dépendances 
./mvnw dependency:tree
Rechercher les versions 
./mvnw dependency:tree -Dverbose
Rebuild complet 
./mvnw clean verify
Vérifier le contenu du JAR 
jar tf target/*.jar | grep "tomcat"
ou: 
jar tf target/*.jar | grep "jackson"
Vérifier une version précise 
./mvnw dependency:tree -Dincludes=org.apache.tomcat.embed:tomcat-embed-core
Étapes de correction rapide
  1. Modifier pom.xml
  2. ./mvnw clean verify
  3. ./mvnw dependency:tree -Dincludes=...
  4. Vérifier target/*.jar
  5. Rebuild Docker
  6. Scanner avec Trivy
  7. Vérifier que le CVE a disparu
La règle d'or est
Ne corrige jamais une vulnérabilité Trivy uniquement en regardant le nom du CVE
Toujours vérifier: 
CVE  → Library + Installed Version + Fixed Version
↓
Chemin Maven  + Fonctionnalité concernée
↓
Configuration  → Exposition  → Version corrigée
↓
Tests + Rebuild + Trivy
Le but est d'obtenir:
Une version corrigée
Une application fonctionnelle
Des dépendances compatibles
L'image reconstruite
Un scan Trivy propre
Laissez-moi un commentaire

En postant un commentaire anonyme, vous adhérez automatiquement aux conditions d'utilisation du site.