Nexus Firewall analyse les fichiers binaires tandis que SecureChain les recompile à partir du code source

Principaux enseignements

• L'analyse vous indique ce que contient un fichier JAR, mais pas s'il correspond au code source publié par le projet.
• Une version altérée sous des coordonnées valides constitue une faille que ni les signatures ni les bases de données d'alertes ne permettent de combler.
• Maven dispose d'outils de construction reproductibles et éprouvés qui font de Java un langage particulièrement adapté à la vérification indépendante des reconstructions.
• SecureChain se situe en amont du proxy Nexus ou Artifactory vers lequel vos builds pointent déjà.

Sonatype Repository Firewall (anciennement Nexus Firewall) intercepte de nombreuses menaces avant même qu’elles n’atteignent votre environnement de build. Il est capable de bloquer les vulnérabilités connues, les violations de politiques, ainsi que les composants que ses systèmes d’intelligence et d’apprentissage automatique signalent comme malveillants ou suspects, conformément aux politiques que vous appliquez au niveau du proxy. Mais tout cela ne permet pas de déterminer si le fichier JAR qu’il vient d’inspecter a bien été généré à partir du code source publié par le projet. C’est cette lacune qui pousse les équipes de sécurité à rechercher une alternative à Sonatype Nexus Firewall dès qu’elles détectent un artefact altéré sous des coordonnées valides, un problème pour lequel l’analyse n’a jamais été conçue pour apporter une réponse.

Ce guide explique en détail ce que l'analyse binaire permet et ne permet pas de vérifier, quelle est la position de Sonatype Firewall et de JFrog Xray sur cette question, et comment SecureChain recompose les paquets Java à partir du code source, sans modifier votre configuration Nexus ou Artifactory existante.

Ce que l'analyse binaire permet et ne permet pas de déterminer

Dans la plupart des évaluations, trois questions distinctes sont traitées comme une seule ; les distinguer permet de simplifier le reste de cette comparaison.

Maven Central n'accepte pas de version dépourvue de signature PGP. Maven ne vérifie toutefois pas ces signatures lors de la résolution normale des dépendances. Il vérifie les sommes de contrôle pour s'assurer de l'intégrité du transport, et le fait qu'une divergence entraîne ou non l'échec de la compilation dépend du checksumPolicy paramètre, dont la valeur par défaut est warn plutôt que fail.

Un artefact malveillant correctement signé et un artefact légitime correctement signé semblent identiques à une version par défaut, car la signature prouve uniquement qu’une personne disposant de la clé appropriée l’a généré, et non que cette clé appartient bien à l’éditeur auquel vous vous attendiez.

Nous avons abordé plus en détail les mécanismes de cette faille dans notre analyse de l’incident du sosie de Jackson, notamment la manière dont un attaquant qui contrôle simplement sa propre clé parvient à satisfaire l’exigence de signature imposée par Maven.

Gradle vous offre ici un contrôle plus direct.

./gradlew --write-verification-metadata sha256,pgp help

Cette commande génère des métadonnées de vérification ; une fois que vous les avez examinées et validées en tant que référence de confiance, les futures versions échoueront dès qu’elles présenteront des divergences. L’étape de vérification est cruciale. Gradle effectue un démarrage optimiste à partir de ce que vos référentiels fournissent à ce moment-là ; le fichier généré enregistre donc ce dont vous disposez déjà, sans pour autant prouver que ces données aient jamais été fiables. Utilisé de cette manière, il s’agit d’un contrôle natif très efficace.

La vérification de la signature et la vérification de la reconstruction ne constituent pas le même contrôle. Un compte d'éditeur compromis génère un fichier JAR correctement signé contenant du code que son propre référentiel source n'a jamais connu. La vérification de la signature confirme que l'artefact provient bien de ce compte. Elle ne permet toutefois pas de déterminer si la version compilée de ce compte correspond bien au code source qu'elle prétend représenter.

La classe des artefacts altérés

Un attaquant disposant d'un accès en publication peut compiler un projet, insérer une modification dans le fichier compilé ou compiler à partir d'un arborescence de travail modifiée, puis publier normalement. Les sommes de contrôle restent cohérentes, car elles vérifient uniquement que le fichier reçu correspond au fichier mis à disposition. La signature peut rester valide si l'attaquant contrôle la clé de signature associée à ce compte. Le dépôt source sur GitHub reste inchangé, car aucun élément du fichier JAR publié ne nécessite de commit correspondant.

Une analyse de ce fichier JAR, qu'elle soit basée sur les vulnérabilités ou sur les signatures, pourrait très bien ne rien détecter, car il n'existe aucun avis de sécurité pour un paquet que personne n'a encore identifié comme compromis. L’analyse comportementale constitue un véritable deuxième niveau de protection et peut signaler à elle seule du code suspect, mais sa couverture varie considérablement d’un écosystème à l’autre. JFrog indique que ses scanners automatisés de paquets malveillants fonctionnent en continu sur npm et PyPI, tandis que la couverture de Maven se limite aux paquets malveillants connus. Quoi qu’il en soit, aucune de ces deux approches ne permet de déterminer si le fichier JAR publié correspond bien au code source du projet.

Il s'agit d'une attaque différente de celle de la Un sosie de Jackson qui a fait sensation à Maven Central en décembre 2025, qui utilisait l'usurpation d'espace de noms, un paquet publié sous un groupId à un préfixe près de la bibliothèque authentique. Ce genre de problème peut être détecté par une politique, à condition que des contrôles d’espace de noms aient été configurés, car les coordonnées elles-mêmes sont erronées. Une politique d’espace de noms ne peut pas identifier une altération sous des coordonnées par ailleurs valides, car ni les coordonnées ni une signature valide ne révèlent la non-correspondance de la source.

Cet article traite des versions altérées sous des coordonnées valides. Ce n'est pas la seule menace dont les équipes Java doivent se préoccuper, mais c'est celle que l'analyse binaire classique ne peut pas résoudre à elle seule ; c'est pourquoi elle nécessite un contrôle spécifique plutôt qu'une simple demande de fonctionnalité pour un outil existant.

Ce que vérifient réellement Sonatype Repository Firewall et JFrog Xray

Sonatype Repository Firewall inspecte les composants au moment où ils entrent dans un référentiel. Sa fonctionnalité « Release Integrity » applique l'apprentissage automatique aux nouvelles versions, signale tout comportement inhabituel et transmet tout élément suspect à l'équipe de recherche de Sonatype, tandis que le Repository Firewall d'origine place les composants signalés en quarantaine jusqu'à ce que cette analyse les valide. Il s'agit là d'un contrôle réel et utile, dont le fonctionnement diffère de la simple vérification de la correspondance entre un artefact et sa source.

Sonatype propose deux niveaux de service. Le « Repository Firewall » complet s’intègre à un gestionnaire de référentiels, prenant en charge à la fois Nexus Repository et les déploiements JFrog Artifactory compatibles, et inclut une fonctionnalité de mise en quarantaine ainsi qu’une protection contre les confusions d’espaces de noms pour une longue liste de formats de paquets. Firewall Pro est un service proxy SaaS plus léger couvrant npm, Maven, PyPI et NuGet ; il autorise ou bloque purement et simplement un composant plutôt que de le placer en quarantaine. La documentation propre à aucun des deux niveaux ne décrit d’étape de reconstruction ou de comparaison des sources, ce qui constitue la distinction essentielle en l’occurrence.

JFrog Xray indexe les artefacts et les met en corrélation avec des informations sur les vulnérabilités et les paquets malveillants ; son système de détection des paquets malveillants combine une analyse automatisée et une validation par des chercheurs pour établir un score de malveillance. Par ailleurs, le service Evidence de JFrog permet d’associer des attestations signées décrivant comment une version a été produite, ce qui constitue une véritable fonctionnalité de traçabilité de la chaîne d’approvisionnement. Il s’agit toutefois d’une confiance accordée à une déclaration signée plutôt que d’une vérification par le biais d’une recompilation indépendante. Quelqu’un doit signer l’attestation, et celle-ci n’est fiable que dans la mesure où l’est la personne qui l’a produite.

SecureChain for Java aborde la question sous un angle différent. Plutôt que d’analyser le binaire de l’éditeur, il examine le code source, puis compile son propre artefact à partir de ce code dans un environnement sécurisé et isolé, en fournissant en parallèle une traçabilité SLSA de niveau 3. Il n’y a pas de binaire en amont à analyser, car votre build n’entre jamais en contact avec celui que Sonatype ou JFrog auraient inspecté. C’est là l’essence même de la sécurité des référentiels Maven à l’heure actuelle. Ce n’est pas le logo du fournisseur qui figure sur le tableau de bord qui importe, mais la question à laquelle chaque couche apporte réellement une réponse.

Pourquoi Java est un bon terrain d'essai pour la recompilation à partir du code source

Les artefacts compilés semblent être une cible peu adaptée à ce type de vérification. Java a toutefois passé des années à mettre en place l'infrastructure qui rend cette tâche gérable, grâce à un véritable effort en faveur des builds reproductibles au sein de l'écosystème Maven.

Configuration de la project.build.outputTimestamp Cette propriété fournit aux plugins compatibles un horodatage fixe à intégrer dans les archives générées, ce qui élimine l'une des principales sources de non-déterminisme dans un fichier JAR.

<properties>
  <project.build.outputTimestamp>2026-01-15T00:00:00Z</project.build.outputTimestamp>
</properties>

Une fois ce paramètre défini et dans un environnement de compilation suffisamment contrôlé, la compilation du même code source peut produire des fichiers JAR identiques à l'octet près. À partir de Maven 4.0.0-beta-5, le mode de compilation reproductible est activé par défaut sans qu'aucune propriété ne soit requise ; toutefois, Maven 4 n'est pas encore disponible au grand public et la version 3.9.x reste la branche maintenue. Les équipes qui utilisent encore Maven 3.x doivent donc définir explicitement cette propriété.

mvn artifact:check-buildplan
mvn artifact:compare

La première commande vous indique quels plugins doivent être mis à jour pour que la reproductibilité fonctionne correctement. La seconde, l’objectif « compare » du plugin maven-artifact-plugin, vérifie précisément cette affirmation en comparant une version locale à une version de référence, généralement celle publiée sur Maven Central. Apache prend soin de souligner qu’une comparaison dans un même environnement ne prouve pas la reproductibilité par des tiers, car les deux versions peuvent hériter des mêmes fuites environnementales. Une véritable vérification implique de recompiler ailleurs.

Reproducible Central recense les versions de Maven Central pour lesquelles des tentatives de recompilation indépendantes ont été effectuées ; sa couverture est toutefois véritablement partielle, loin d’être quasi universelle. Une étude universitaire de 2024 a relevé que Reproducible Central avait signalé des tentatives de recompilation pour 2 547 versions réparties sur 531 projets, alors que Maven Central comptait plus de 10 millions de versions et 479 000 identifiants d’artefacts uniques selon son instantané de mai 2023. Ces chiffres correspondent à cet instantané plutôt qu’à l’état actuel du registre, et ils montrent à quel point la couverture vérifiée de manière indépendante était partielle à l’époque.

Go et Rust atténuent en partie le problème de confiance dans les binaires, car les dépendances sont généralement distribuées sous forme de code source et protégées par des mécanismes garantissant l’intégrité de l’écosystème. Cela ne revient toutefois pas à prouver qu’un paquet publié correspond bien à une révision source en amont spécifique. L’écosystème Maven de Java a réalisé un investissement comparable, spécifiquement axé sur la reproductibilité des binaires, devançant ainsi ce que représentent généralement aujourd’hui les « wheels » Python avec extensions compilées et les archives tar créées par les éditeurs sur npm.

Ce que la recompilation à partir du code source exige réellement de la version en amont

La comparaison de versions permet d'obtenir des preuves vérifiables indiquant si la version compilée correspond bien à son code source. Lorsqu'une version compilée d'un projet intègre encore des horodatages variables ou d'autres métadonnées non déterministes, une comparaison octet par octet échouera même si le code source sous-jacent n'a absolument pas changé, quelle que soit la personne qui effectue la comparaison.

Pour ces artefacts, la comparaison passe du stade de la preuve à celui de l'analyse. Les indices sont nécessairement moins solides et leur interprétation demande davantage de travail, ce qu'il est utile de savoir avant de définir la portée d'un déploiement autour de ceux-ci. Il s'agit toujours d'un signal significatif, mais il ne s'agit pas d'une correspondance octet par octet.

Les dépendances masquées et déplacées compliquent encore davantage la tâche. Les plugins de masquage réécrivent les noms des paquets et les dépendances intégrées, ce qui modifie les éléments pris en compte lors d'une comparaison structurelle. Ce problème se pose suffisamment souvent dans le Java d'entreprise pour qu'il vaille la peine d'être abordé directement lors d'une évaluation.

Le fait de proposer une alternative à Sonatype Nexus Firewall ne signifie pas pour autant qu'il faille remplacer Nexus

Le référentiel proxy d'un gestionnaire de référentiels pointe vers une URL distante. Cette URL est généralement https://repo1.maven.org/maven2/. Le fait de la rediriger vers une autre adresse relève d'un paramètre de configuration et non d'un projet de migration.

Le workflow des développeurs reste inchangé, et les fichiers de projet n’ont pas besoin d’être modifiés tant que le gestionnaire de dépôts reste le point de terminaison utilisé pour la compilation. Vos groupes existants, vos dépôts hébergés et vos politiques de nettoyage restent inchangés. Le gestionnaire de dépôts continue de gérer la mise en cache, la disponibilité et les politiques. La source en amont à partir de laquelle il effectue la mise en cache devient une source filtrée et recompilée, au lieu de la source publique.

Effectuez deux opérations parallèlement à la migration. Conservez vos règles d’exclusion d’espaces de noms sur le proxy, car le blocage de la résolution de vos propres coordonnées internes en amont constitue le mécanisme de contrôle qui résiste aux dérives de configuration et n’a rien à voir avec le serveur en amont vers lequel vous êtes redirigé. Vérifiez ensuite la configuration de votre miroir, car Maven prend en compte les référentiels déclarés dans le fichier POM d’une dépendance, et une dépendance transitive peut en ajouter un à votre ensemble de résolution sans que vous l’ayez jamais déclaré. A mirrorOf ensemble de règles défini uniquement sur central ne les interceptera pas ; assurez-vous donc que votre configuration couvre tous les dépôts externes que vous comptez acheminer via le gestionnaire de dépôts. Notre article sur La lacune du fichier settings.xml de Maven traite ce mode de défaillance précis de manière plus approfondie. Vérifiez-le quelle que soit la destination de votre proxy, car il s’agit d’un risque lié à la configuration Maven préexistante et non d’un problème introduit par le changement de source en amont.

Quelle configuration choisir ?

Si vous recherchez une alternative à Sonatype Nexus Firewall précisément en raison de craintes liées à la falsification d'artefacts, commencez par vous poser directement cette question plutôt que de vous lancer dans une comparaison générale des fonctionnalités.

Les équipes qui utilisent déjà Nexus ou Artifactory ont la tâche la plus simple, car il s’agit d’un simple changement d’URL de proxy et d’un projet pilote sur un seul référentiel de groupe. Si votre modèle de menace n’inclut pas spécifiquement les artefacts altérés, les analyses existantes peuvent déjà suffire ; de plus, les règles d’exclusion d’espaces de noms ainsi que les métadonnées de vérification Gradle constituent des contrôles gratuits qui permettent de contrer d’autres vecteurs d’attaque courants de la chaîne d’approvisionnement.

Les environnements réglementés nécessitant des preuves de provenance tirent pleinement parti de la comparaison des versions reconstruites, car celle-ci génère des preuves vérifiables ; la question de la reproductibilité pour chaque dépendance est donc celle qu’il convient d’aborder en priorité. Et si vous exploitez plusieurs écosystèmes au-delà de Java, évaluez cette question comme une décision portant sur l’ensemble de la pile plutôt que comme un simple achat, car un contrôle limité à Java laisse le reste de la pile exactement dans la même situation qu’au départ.

Découvrez ce que SecureChain remanie avant de prendre votre décision

Si votre configuration Nexus ou Artifactory gère déjà efficacement la mise en cache, la disponibilité et les politiques, et que la question qui se pose est de savoir si ce qui transite par ce pipeline correspond bien à sa source, c'est précisément à cela que sert SecureChain for Java, sans que vous ayez à modifier le gestionnaire de référentiels que vous utilisez déjà. Ce même référentiel continue de fournir des correctifs de vulnérabilité pour vos dépendances même après la fin de la maintenance en amont, grâce au service « Endless Lifecycle Support ».

Demandez un devis et nous vous présenterons ensemble à quoi ressemblerait un projet pilote basé sur un référentiel unique, appliqué à votre propre arborescence de dépendances.

FAQ

Quelle est l'alternative à Sonatype Nexus Firewall ?

De nombreux produits font concurrence à Nexus Firewall, désormais appelé Sonatype Repository Firewall, en matière d'analyse et de gestion des artefacts. Dans cet article, ce terme désigne une notion plus restreinte : une approche qui répond à une question supplémentaire de confiance, à savoir si un artefact publié correspond bien à la source à partir de laquelle il prétend avoir été construit. L'analyse et la vérification de la reconstruction sont généralement effectuées en parallèle d'un gestionnaire de référentiel plutôt qu'à sa place, puisque ce dernier continue de gérer la mise en cache et la disponibilité.

L'analyse binaire permet-elle de détecter un fichier JAR altéré ?

Parfois. Un scanner examine le contenu de l'artefact, et une analyse comportementale peut signaler la présence de code suspect au sein d'un fichier JAR altéré, même en l'absence de toute alerte à ce sujet. Ce que l'analyse ne peut pas faire à elle seule, c'est établir que l'artefact diffère de la source déclarée ; pour cela, il faut procéder à une comparaison entre la source et l'artefact.

Est-il possible de réaliser des compilations reproductibles en Java ?

Oui. Maven prend en charge une propriété d'horodatage de la sortie de compilation qui fixe les métadonnées de l'archive, et le mode de compilation reproductible est activé par défaut depuis la version Maven 4.0.0-beta-5. Dans un environnement de compilation suffisamment contrôlé, un même code source peut produire des fichiers JAR identiques au niveau des octets. La couverture sur Maven Central reste toutefois partielle, de sorte que la reproductibilité varie d'un projet à l'autre.

Maven vérifie-t-il les signatures PGP par défaut ?

Non. Maven Central exige des éditeurs qu'ils fournissent une signature au moment de la publication, mais le processus standard de résolution des dépendances de Maven vérifie les sommes de contrôle plutôt que ces signatures. La vérification des signatures nécessite des outils ou des plugins supplémentaires.

Dois-je remplacer Nexus ou Artifactory pour utiliser SecureChain ?

Non. Le proxy d’un gestionnaire de référentiels pointe vers une URL distante configurable ; ainsi, le passage à SecureChain modifie simplement la destination du proxy, sans supprimer le gestionnaire de référentiels lui-même. Tant que votre gestionnaire de référentiels actuel reste le point de terminaison utilisé pour les builds, la configuration des développeurs, les fichiers de projet et les groupes existants peuvent rester inchangés.

Que devient-il des artefacts qui ne sont pas reproductibles en amont ?

Une comparaison au niveau des octets n'est plus possible dès lors qu'une compilation produit un résultat non déterministe ; la vérification doit alors s'appuyer sur une analyse complémentaire. Cette preuve est moins solide qu'une correspondance exacte et reproductible, mais elle apporte tout de même davantage d'informations qu'une simple analyse du fichier binaire.

Résumé

Nom de l'article

Une alternative à Sonatype Nexus Firewall permettant la recompilation à partir du code source

Description

Comment une alternative à Sonatype Nexus Firewall recompile les paquets Java à partir du code source, et pourquoi l'analyse ne permet pas de garantir l'intégrité du code source.

Auteur

Tim Walker

Nom de l'éditeur

de TuxCare

Logo de l'éditeur