Corriger les vulnérabilités dans les projets Maven

Maven reste le système de build le plus utilisé dans l’écosystème Java. Selon le rapport JVM 2020, Maven est l’outil de build le plus répandu dans cet écosystème, avec deux tiers des parts.

Il est donc important de comprendre le fonctionnement de Maven. Par exemple, si Snyk détecte des vulnérabilités dans votre projet Maven, comment les corriger ? Dans cet article, je vous explique comment corriger les vulnérabilités dans les bibliothèques tierces lorsque vous utilisez Maven, même si la solution n’est pas évidente.

Détecter les vulnérabilités

Si vous utilisez Maven pour compiler votre projet et gérer ses dépendances, vous pouvez analyser vos projets de plusieurs façons avec Snyk. Cela vaut quel que soit le langage de programmation utilisé : Java, Kotlin, Scala, Groovy ou tout autre langage conçu pour la machine virtuelle Java (JVM).

Vous pouvez analyser votre projet Maven à la recherche de vulnérabilités avec Snyk à l’aide de

• Snyk CLI

• Snyk GitHub Actions pour Maven

• Snyk Maven Plugin

• Snyk IDE plugin pour Eclipse ou IntelliJ IDEA

• en connectant votre dépôt à Snyk

Prenons l’exemple de la CLI : Snyk vous indique si vous pouvez corriger les vulnérabilités en mettant à jour les dépendances de premier niveau et comment procéder. Toutefois, si aucune version plus récente de ces dépendances n’est disponible, Snyk vous indique si une version plus récente d’une dépendance sous-jacente permet de corriger les vulnérabilités.

Corriger les vulnérabilités des dépendances de premier niveau

La façon la plus simple de corriger une vulnérabilité détectée par Snyk consiste à remplacer la bibliothèque de premier niveau, si possible. Si cette bibliothèque n’a aucune dépendance sous-jacente, la solution est assez évidente : passer à une version plus récente qui ne présente pas le problème en question. Il en va de même lorsqu’une dépendance sous-jacente présente un problème, mais qu’une version plus récente de la dépendance de premier niveau, qui ne présente pas ce problème, est déjà disponible.

Il existe plusieurs façons de changer de version. Commencez par repérer où la version est spécifiée. Pour les dépendances de premier niveau, vous pouvez généralement la trouver à l’un des endroits suivants :

• dans un POM parent

• dans une propriété

• directement au niveau de la dépendance

POM parent

Si la dépendance à mettre à jour est définie dans un POM parent, commencez par rechercher une version plus récente de ce POM. Prenons Spring Boot : si une version plus récente du POM parent est disponible, envisagez d’abord de passer à cette version et vérifiez si cela résout le problème. Vous mettrez ainsi à jour l’ensemble des dépendances qui, dans la plupart des cas, fonctionneront mieux ensemble que si vous n’en mettez à jour qu’une seule. Si vous ne pouvez pas remplacer ou modifier le parent, passez directement à l’approche directe.

<parent>
   <groupId>io.snyk</groupId>
   <artifactId>demo-parent</artifactId>
   <version>1.0.4.RELEASE</version>
</parent>

Propriétés

Si une propriété est utilisée, commencez par la mettre à jour. Cela peut également mettre à jour d’autres dépendances, mais, comme pour le POM parent, ce choix a une bonne raison d’être. Lorsque des bibliothèques sont publiées sous forme d’ensemble, elles fonctionnent mieux ensemble si elles utilisent la même version.

<dependency>
  <groupId>org.eclipse.collections</groupId>
  <artifactId>eclipse-collections</artifactId>
  <version>10.4.0</version>
</dependency>

Directement

Enfin, votre dépendance est déclarée dans la section dependencies de votre fichier POM Maven. Vous y spécifiez le groupId, l’artifactId et, dans de nombreux cas, la version. Si la version est déclarée à cet endroit, il vous suffit de la mettre à jour. Sinon, vous pouvez l’ajouter.

Notez qu’il s’agit du niveau le plus bas pour déclarer la version d’une dépendance, et que cette déclaration prend le pas sur toutes les autres façons de définir la version.

<dependency>
  <groupId>org.eclipse.collections</groupId>
  <artifactId>eclipse-collections</artifactId>
  <version>10.4.0</version>
</dependency>

Corriger les dépendances sous-jacentes

Supposons qu’aucune version plus récente de votre dépendance de premier niveau ne soit encore disponible, mais qu’une dépendance sous-jacente présente un problème à corriger. La CLI vous a déjà signalé qu’une version plus récente de cette dépendance sous-jacente, qui corrige le problème, est disponible.

Bill of Materials

De nombreux frameworks utilisent un Bill of Materials (BOM) pour gérer les dépendances sous-jacentes. Un BOM est un type particulier de POM qui sert à contrôler les versions des dépendances d’un projet et à fournir un emplacement central pour définir et mettre à jour ces versions.

Lorsqu’une dépendance sous-jacente doit être remplacée dans un framework comme Spring Boot, vérifiez si elle fait partie d’un BOM. Si c’est le cas, vérifiez s’il existe déjà une version plus récente de ce BOM et mettez-la à jour. Dans Spring Boot et de nombreux autres frameworks connus, les versions du BOM sont spécifiées sous forme de propriété. Vous pouvez remplacer cette propriété dans votre propre fichier POM Maven en y ajoutant une propriété.

Dans l’exemple ci-dessous, je remplace le BOM de Jackson dans mon projet Spring Boot :

<properties>
    <jackson.version>2.10.2.20200130</jackson.version>
</properties>

Gestion des dépendances

Dans un POM Maven, il est possible d’exclure et d’inclure des dépendances sous-jacentes spécifiques lors de la déclaration d’une dépendance de premier niveau. Cela peut toutefois poser problème lorsque deux bibliothèques partagent la même dépendance sous-jacente. Une bonne pratique avec Maven consiste à regrouper ces déclarations dans la section dependency management. Cette section permet aux auteurs d’un projet de spécifier directement les versions des artefacts à utiliser lorsqu’ils apparaissent dans des dépendances transitives. En plus de l’exemple ci-dessous, la documentation explique clairement comment utiliser dependencyManagement :

<dependencyManagement>
   <dependencies>
       <dependency>
           <groupId>org.yaml</groupId>
           <artifactId>snakeyaml</artifactId>
           <version>1.26</version>
       </dependency>
   </dependencies>
</dependencyManagement>

Conclusion

Comme vous pouvez le constater, il existe plusieurs façons d’atténuer les problèmes de sécurité dans les dépendances open source d’un projet basé sur Maven. Même si la mise à jour d’une dépendance de premier niveau ne permet pas de corriger directement le problème, vous pouvez exclure une dépendance transitive sous-jacente et la remplacer par une version plus récente disponible. Snyk Open Source vous indique la version vers laquelle effectuer la mise à jour. Cet article vous montre comment le configurer correctement dans votre projet Maven.