Provetry
ENDEDemander l’accès anticipé
Test gratuit
Demander l’accès anticipé

Provetry ouvre en novembre 2026. Le test CRA gratuit, les outils et les guides sont disponibles dès maintenant.

SBOM pour Java : Maven et Gradle pour le CRA

7 min de lecture

Sur cette page
  1. Maven : le produire pendant le build
  2. Gradle : verrouiller, puis produire
  3. Spring Boot en fait une partie pour vous
  4. Ce que l’outil de build ne montre pas
  5. Du SBOM aux vulnérabilités
  6. Ce que fait Provetry
  7. Sources

Le Cyber Resilience Act demande à chaque fabricant de tenir une nomenclature des logiciels « dans un format couramment utilisé et lisible par machine couvrant au moins les dépendances de niveau supérieur des produits » (annexe I, partie II, point 1). Java a ici une difficulté particulière : Maven n’a pas de fichier de verrouillage, et seul l’outil de build connaît l’arbre complet des dépendances, une fois résolus les POM parents, les BOM et les conflits de versions. Le SBOM doit donc sortir du build lui-même.

Pour le règlement lui-même, voir Le SBOM pour le Cyber Resilience Act.

Maven : le produire pendant le build

Le plugin CycloneDX pour Maven résout l’arbre des dépendances exactement comme Maven et écrit le SBOM. Vous pouvez le lancer une fois sans toucher au POM :

mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

Ou le rattacher à la phase package, pour que chaque build en produise un :

<plugin>
  <groupId>org.cyclonedx</groupId>
  <artifactId>cyclonedx-maven-plugin</artifactId>
  <version>2.9.1</version>
  <executions>
    <execution>
      <phase>package</phase>
      <goals><goal>makeAggregateBom</goal></goals>
    </execution>
  </executions>
</plugin>

makeAggregateBom décrit un build multimodule en un seul fichier ; makeBom en écrit un par module. Les fichiers arrivent dans target/ (bom.json et bom.xml par défaut), et les versions 2.9 du plugin écrivent du CycloneDX 1.6. Par défaut, le plugin garde les portées compile, provided, runtime et system, et laisse de côté les dépendances de test.

Lire pom.xml seul ne suffit pas. Une version héritée d’un POM parent ou importée d’un BOM comme spring-boot-dependencies se trouve hors de votre dépôt, et les conflits entre versions transitives sont tranchés par la règle du « plus proche » de Maven. Tout ce qui lit le POM comme du texte manquera une partie de l’arbre.

Gradle : verrouiller, puis produire

Activez le verrouillage des dépendances, pour que les versions soient figées et visibles dans le dépôt :

dependencyLocking {
    lockAllConfigurations()
}

Appliquez-le à chaque projet (par exemple dans allprojects { }). ./gradlew dependencies --write-locks, lancé dans chaque projet, écrit ensuite un gradle.lockfile par projet, avec chaque composant résolu pour chaque configuration.

Pour le SBOM lui-même, appliquez le plugin CycloneDX pour Gradle :

plugins {
    id("org.cyclonedx.bom") version "3.4.0"
}

Depuis la version 3.0, ./gradlew cyclonedxDirectBom écrit un SBOM par projet (dans build/reports/cyclonedx-direct/) et ./gradlew cyclonedxBom rassemble un build multiprojet (dans build/reports/cyclonedx/). Limitez-le à ce qui est livré, en général runtimeClasspath, avec includeConfigs sur la tâche cyclonedxDirectBom.

Spring Boot en fait une partie pour vous

Depuis Spring Boot 3.3, il suffit d’ajouter le plugin CycloneDX : Spring Boot le configure, place le SBOM dans le jar exécutable sous META-INF/sbom/application.cdx.json et indique son emplacement dans le manifeste du jar. Le SBOM voyage alors avec chaque copie du jar. L’actuator peut aussi le servir sous /actuator/sbom ; si vous l’activez, gardez ce point d’accès hors de l’internet public : le CRA ne vous demande pas de publier votre SBOM, et les attaquants aiment connaître vos versions.

Ce que l’outil de build ne montre pas

  • Les fat jars et les jars relocalisés (« shaded »). Un jar relocalisé recopie dans le vôtre les classes d’autres bibliothèques, parfois sous un autre nom de paquet. Log4Shell (CVE-2021-44228) en a montré le coût : beaucoup d’équipes ignoraient que log4j-core se trouvait dans un jar qu’elles livraient. Produisez le SBOM à partir du build qui fabrique le jar, et vérifiez ce que vous y intégrez.
  • L’environnement d’exécution Java. Si vous livrez un JRE avec le produit (une image jlink, un installeur, une image de conteneur), sa version est un composant, avec des mises à jour de sécurité trimestrielles d’Oracle et des distributeurs d’OpenJDK.
  • Les serveurs d’applications et les agents. Un WAR déployé sur un Tomcat que vous livrez, ou un agent de supervision ajouté au démarrage, font aussi partie du produit.

Du SBOM aux vulnérabilités

Les plugins ne font que lister les composants ; un scanner comme OWASP Dependency-Check, ou tout outil qui lit CycloneDX, les rapproche des avis de sécurité. Regardez d’abord les vulnérabilités exploitées, qui peuvent déclencher le délai de signalement, et consignez dans une déclaration VEX pourquoi une classe vulnérable que votre code ne charge jamais ne touche pas le produit.

Ce que fait Provetry

La source la plus fiable est le SBOM écrit par le plugin CycloneDX pour Maven ou Gradle : envoyez-le, ou transmettez-le depuis votre CI, et Provetry le garde avec la version, le réécrit en SPDX avec les offres payantes et surveille chaque jour avec les offres payantes et chaque semaine avec l’offre gratuite chaque composant pour les vulnérabilités nouvelles et exploitées. Il lit aussi directement les fichiers gradle.lockfile, en traitant les configurations de test, de compilation seule et de traitement d’annotations comme des dépendances de développement. À partir d’un simple pom.xml, il ne lit que les dépendances directes qu’il peut résoudre dans votre dépôt, dit quelles versions il n’a pas pu résoudre, et marque le SBOM comme incomplet plutôt que de deviner. Il montre où votre code importe un paquet vulnérable, avec le fichier et la ligne, mais ne conclut jamais qu’un paquet Java est inutilisé : sans graphe complet des dépendances, il ne peut pas l’exclure.

Sources