Nexus Firewall analiza los archivos binarios, mientras que SecureChain los recompila a partir del código fuente

Principales conclusiones

• El análisis te indica qué contiene un archivo JAR, pero no si coincide con el código fuente que publica el proyecto.
• Una compilación manipulada con coordenadas válidas es la brecha que ni las firmas ni las bases de datos de alertas logran cerrar.
• Maven cuenta con herramientas maduras para la creación de compilaciones reproducibles, lo que hace que Java sea muy adecuado para la verificación independiente de las recompilaciones.
• SecureChain se sitúa antes del proxy de Nexus o Artifactory al que ya apuntan tus compilaciones.

Sonatype Repository Firewall (antes Nexus Firewall) detecta muchos problemas antes de que nada llegue a tu compilación. Puede bloquear vulnerabilidades conocidas, incumplimientos de políticas y componentes que sus sistemas de inteligencia y aprendizaje automático señalen como maliciosos o sospechosos, de acuerdo con las políticas que apliques en el proxy. Lo que nada de esto aclara es si el archivo JAR que acaba de inspeccionar se ha compilado realmente a partir del código fuente que publica el proyecto. Esa laguna es la razón por la que los equipos de seguridad empiezan a buscar una alternativa a Sonatype Nexus Firewall en cuanto se topan con un artefacto manipulado bajo unas coordenadas válidas, un problema para el que el análisis nunca se diseñó.

Esta guía explica qué puede y qué no puede verificar el análisis de archivos binarios, cuál es la postura de Sonatype Firewall y JFrog Xray al respecto, y cómo SecureChain recompila los paquetes Java a partir del código fuente, sin alterar tu configuración actual de Nexus o Artifactory.

Lo que el análisis binario puede y no puede responder

En la mayoría de las evaluaciones, tres cuestiones distintas se tratan como una sola, y separarlas hace que el resto de esta comparación resulte sencillo.

Maven Central no aceptará una versión que no cuente con una firma PGP. Sin embargo, Maven no verifica dichas firmas durante la resolución normal de dependencias. Comprueba las sumas de comprobación para garantizar la integridad de la transmisión, y el hecho de que una discrepancia provoque o no el fallo de la compilación depende de la configuración del repositorio. checksumPolicy configuración, cuyo valor por defecto es warn en lugar de fail.

Un artefacto malicioso firmado correctamente y uno legítimo firmado correctamente parecen idénticos en una compilación predeterminada, ya que la firma solo demuestra que lo ha creado alguien con la clave adecuada, no que la clave pertenezca al editor que esperabas.

Hemos analizado con mayor detalle los mecanismos de esta vulnerabilidad en nuestro análisis del incidente del «doble de Jackson», incluyendo cómo un atacante que simplemente controla su propia clave puede eludir el requisito de firma de Maven.

Gradle te permite un control más directo en este aspecto.

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

Ese comando genera metadatos de verificación y, una vez que los hayas revisado y validado como referencia de confianza, las compilaciones futuras fallarán ante cualquier elemento que no coincida. La fase de revisión es fundamental. Gradle realiza un arranque optimista a partir de lo que tus repositorios estén proporcionando en ese momento, por lo que el archivo generado registra lo que ya tienes, en lugar de demostrar que alguna vez fue fiable. Utilizado de esta forma, constituye un sólido control nativo.

La verificación de la firma y la verificación de la compilación no son el mismo control. Una cuenta de editor comprometida genera un archivo JAR firmado correctamente que contiene código que nunca ha estado presente en su propio repositorio de código fuente. La verificación de la firma confirma que el artefacto procede de esa cuenta. No indica en absoluto si la compilación de esa cuenta coincide con el código fuente que dice representar.

La clase de artefactos manipulados

Un atacante con acceso de publicación puede compilar un proyecto, introducir un cambio en el resultado compilado o compilar a partir de un árbol de trabajo modificado, y publicar con normalidad. Las sumas de comprobación se mantienen coherentes, ya que solo confirman que el archivo recibido coincide con el archivo que se está sirviendo. La firma puede seguir siendo válida si el atacante controla la clave de firma vinculada a esa cuenta. El repositorio de código fuente en GitHub permanece intacto, ya que nada de lo relacionado con el archivo JAR publicado requiere una confirmación correspondiente.

Es muy probable que un análisis de ese archivo JAR basado en vulnerabilidades o en firmas no detecte nada, ya que no existe ningún aviso sobre un paquete que nadie haya identificado todavía como comprometido. El análisis de comportamiento constituye una segunda capa real y puede señalar código sospechoso por sí solo, pero la cobertura varía considerablemente según el ecosistema. JFrog documenta que sus escáneres automatizados de paquetes maliciosos funcionan de forma continua con npm y PyPI, mientras que indica que la cobertura de Maven se limita únicamente a los paquetes maliciosos más conocidos. En cualquier caso, ninguno de los dos enfoques determina si el JAR publicado se corresponde con el código fuente del proyecto.

Ese es un ataque distinto del Un doble de Jackson que apareció en Maven Central en diciembre de 2025, que utilizaba la suplantación de espacio de nombres, un paquete publicado bajo un groupId a un prefijo de distancia de la biblioteca real. Este tipo de situaciones pueden detectarse mediante una política, siempre que se hayan configurado controles de espacio de nombres, ya que las propias coordenadas son erróneas. La política de espacio de nombres no puede identificar la manipulación en el caso de coordenadas que, por lo demás, son válidas, ya que ni las coordenadas ni una firma válida revelan la discrepancia en el origen.

Este artículo trata sobre las compilaciones manipuladas que se encuentran bajo coordenadas válidas. No es el único tipo de ataque del que deben preocuparse las empresas que utilizan Java, pero sí es aquel que el análisis habitual de binarios no puede resolver por sí solo, por lo que requiere un control específico, en lugar de una simple solicitud de funcionalidad para una herramienta ya existente.

Qué comprueban realmente Sonatype Repository Firewall y JFrog Xray

Sonatype Repository Firewall inspecciona los componentes en el momento en que entran en un repositorio. Su función «Release Integrity» aplica técnicas de aprendizaje automático a las nuevas versiones, señala cualquier comportamiento inusual en las mismas y remite cualquier elemento sospechoso al equipo de investigación de Sonatype, mientras que el propio Repository Firewall mantiene los componentes señalados en cuarentena hasta que dicha revisión los autorice. Se trata de un control real y útil, y es una operación distinta a la de confirmar que un artefacto coincide con su fuente.

Sonatype comercializa este servicio en dos niveles. El «Repository Firewall» completo se integra con un gestor de repositorios, cubriendo tanto Nexus Repository como las implementaciones compatibles de JFrog Artifactory, e incluye protección contra la cuarentena y la confusión de espacios de nombres en una amplia lista de formatos de paquetes. Firewall Pro es un servicio proxy SaaS más ligero que cubre npm, Maven, PyPI y NuGet, y permite o bloquea un componente directamente, en lugar de mantenerlo en estado de cuarentena. En la documentación de ninguno de los dos niveles se describe un paso de recompilación o de comparación de código fuente, que es la distinción que importa en este caso.

JFrog Xray indexa los artefactos y los correlaciona con información sobre vulnerabilidades y paquetes maliciosos; su sistema de detección de paquetes maliciosos combina el análisis automatizado y la validación por parte de investigadores para obtener una puntuación de malicia. Por otra parte, el Evidence Service de JFrog puede adjuntar certificados firmados que describen cómo se ha generado una compilación, lo que constituye una auténtica capacidad de trazabilidad de la cadena de suministro. Sin embargo, sigue basándose en la confianza en una declaración firmada, en lugar de en la verificación mediante una recompilación independiente. Alguien tiene que firmar el certificado, y la fiabilidad de este depende exclusivamente de la persona que lo haya elaborado.

SecureChain para Java aborda esto desde el otro extremo. En lugar de analizar el binario del editor, examina el código fuente y, a continuación, compila su propio artefacto a partir de ese código en un entorno aislado y reforzado, incluyendo junto con él la procedencia SLSA de nivel 3. No hay ningún binario de origen que analizar, ya que tu compilación nunca entra en contacto con el que habrían inspeccionado Sonatype o JFrog. Ese es, en la actualidad, el núcleo práctico de la seguridad de los repositorios de Maven. No se trata de qué logotipo de qué proveedor aparece en el panel de control, sino de qué pregunta responde realmente cada capa.

Por qué Java es un buen punto de partida para recompilar desde el código fuente

Los artefactos compilados parecen un mal objetivo para este tipo de verificación. De todos modos, Java lleva años desarrollando la infraestructura que permite gestionarlos, gracias a un auténtico esfuerzo por lograr compilaciones reproducibles dentro del ecosistema de Maven.

Configuración de la project.build.outputTimestamp Esta propiedad proporciona a los complementos compatibles una marca de tiempo fija que se incluye en los archivos generados, lo que elimina una de las principales fuentes de no determinismo en un JAR.

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

Con ese conjunto de propiedades y un entorno de compilación suficientemente controlado, la compilación del mismo código fuente puede generar archivos JAR idénticos al nivel de byte. A partir de Maven 4.0.0-beta-5, el modo de compilaciones reproducibles está activado por defecto sin necesidad de configurar ninguna propiedad; sin embargo, Maven 4 aún no ha alcanzado la disponibilidad general y la versión 3.9.x sigue siendo la línea de versiones en mantenimiento, por lo que los equipos que sigan compilando con Maven 3.x deben configurar la propiedad de forma explícita.

mvn artifact:check-buildplan
mvn artifact:compare

El primer comando te indica qué complementos hay que actualizar para que los resultados reproducibles funcionen correctamente. El segundo, el objetivo «compare» del complemento «maven-artifact-plugin», comprueba precisamente esto, comparando una compilación local con una compilación de referencia, que suele ser la publicada en Maven Central. Apache se cuida de señalar que una comparación en el mismo entorno no garantiza la reproducibilidad por parte de terceros, ya que ambas compilaciones pueden heredar la misma «filtración ambiental». Una verificación real implica volver a compilar en otro lugar.

Reproducible Central realiza un seguimiento de las versiones de Maven Central para las que se han intentado reconstrucciones independientes, y la cobertura es realmente parcial, en lugar de ser casi universal. Un estudio académico de 2024 señalaba que Reproducible Central había registrado intentos de reconstrucción para 2.547 versiones en 531 proyectos, frente a los más de 10 millones de versiones y los 479.000 identificadores de artefactos únicos que había en Maven Central según su instantánea de mayo de 2023. Esas cifras se refieren a esa instantánea y no al registro actual, y muestran lo parcial que era en aquel momento la cobertura verificada de forma independiente.

Go y Rust mitigan en parte el problema de la confianza en los binarios, ya que las dependencias suelen distribuirse en código fuente y están protegidas por mecanismos de integridad del ecosistema. Esto no es lo mismo que demostrar que un paquete publicado se corresponde con una revisión concreta del código fuente original. El ecosistema Maven de Java ha realizado una inversión comparable, centrada específicamente en la reproducibilidad de los binarios, situándose por delante de lo que suelen ofrecer hoy en día los «wheels» de Python con extensiones compiladas y los archivos tar creados por los editores de npm.

Lo que realmente requiere la compilación desde el código fuente del proyecto original

La comparación de compilaciones genera pruebas verificables que permiten determinar si la compilación coincide con su código fuente. Cuando la compilación de un proyecto sigue incluyendo marcas de tiempo variables u otros metadatos no deterministas, una comparación byte a byte dará error incluso aunque el código fuente subyacente no haya cambiado en absoluto, independientemente de quién la ejecute.

En el caso de esos artefactos, la comparación pasa de ser una prueba a ser un análisis. Las pruebas son necesariamente menos sólidas y su interpretación requiere más esfuerzo, algo que conviene tener en cuenta antes de planificar un despliegue en torno a ellas. Sigue siendo una señal significativa, pero no se trata de una coincidencia byte a byte.

Las dependencias ocultas y reubicadas complican aún más las cosas. Los complementos de ocultación reescriben los nombres de los paquetes y las dependencias en línea, lo que altera los elementos que se tienen en cuenta en una comparación estructural. Es algo que ocurre con tanta frecuencia en el ámbito del Java empresarial que merece la pena plantearlo directamente durante una evaluación.

Una alternativa a Sonatype Nexus Firewall no implica sustituir a Nexus

El repositorio proxy de un gestor de repositorios apunta a una URL remota. Esa URL suele ser https://repo1.maven.org/maven2/. Configurarlo para que apunte a otra dirección es un campo de configuración, no un proyecto de migración.

El flujo de trabajo de los desarrolladores no sufre cambios, y no es necesario modificar los archivos del proyecto siempre y cuando el gestor de repositorios siga siendo el punto final al que se dirige la compilación. Tus grupos, repositorios alojados y políticas de limpieza actuales se mantienen tal cual. El gestor de repositorios sigue encargándose del almacenamiento en caché, la disponibilidad y las políticas. La fuente de la que obtiene la información en caché pasa a ser una fuente filtrada y recompilada, en lugar de la pública.

Haz dos cosas al mismo tiempo que realizas el cambio. Mantén tus reglas de exclusión de espacios de nombres en el proxy, ya que impedir que tus propias coordenadas internas se resuelvan en el servidor principal es el control que resiste las desviaciones de configuración y no tiene nada que ver con el servidor principal al que estés conectado. A continuación, comprueba la configuración de tu espejo, ya que Maven respeta los repositorios declarados dentro del propio POM de una dependencia, y una dependencia transitiva puede añadir uno a tu conjunto de resolución sin que tú lo hayas declarado. A mirrorOf conjunto de reglas establecido únicamente en central no los interceptará, así que asegúrate de que la tuya cubra todos los repositorios externos que pretendas gestionar a través del gestor de repositorios. Nuestro artículo sobre La laguna del archivo «settings.xml» de Maven trata este modo de fallo concreto con mayor detalle. Compruébalo independientemente de cuál sea la dirección a la que apuntes tu proxy, ya que se trata de un riesgo preexistente en la configuración de Maven y no de algo que se derive del cambio de proveedores.

¿Qué configuración es la más adecuada?

Si estás valorando una alternativa a Sonatype Nexus Firewall precisamente por el temor a que se manipulen los artefactos, empieza por abordar directamente esa cuestión, en lugar de realizar una comparación general de características.

Los equipos que ya utilizan Nexus o Artifactory tienen el camino más fácil, ya que se trata de un cambio en la URL del proxy y una prueba piloto en un único repositorio de grupo. Si tu modelo de amenazas no incluye específicamente los artefactos manipulados, es posible que los análisis existentes ya sean suficientes; además, las reglas de exclusión de espacios de nombres y los metadatos de verificación de Gradle son controles gratuitos que abordan otras vías comunes de ataque a la cadena de suministro.

Los entornos regulados que requieren pruebas de procedencia sacan el máximo partido a la comparación de reconstrucciones, ya que esta genera pruebas auditables, y la cuestión de la reproducibilidad por dependencia es lo primero que hay que tener en cuenta. Y si gestionas varios ecosistemas además de Java, evalúa esto como una decisión a nivel de pila en lugar de como una simple adquisición, ya que un control limitado exclusivamente a Java deja al resto de la pila exactamente donde estaba.

Descubre qué es lo que reconstruye SecureChain antes de tomar una decisión

Si tu configuración de Nexus o Artifactory ya gestiona adecuadamente el almacenamiento en caché, la disponibilidad y las políticas, y la duda que te surge es si lo que circula por ese canal se corresponde realmente con su origen, para eso se ha creado SecureChain for Java, sin necesidad de modificar el gestor de repositorios que ya utilizas. El mismo registro sigue proporcionando correcciones de vulnerabilidades para tus dependencias una vez finalizado el mantenimiento de los desarrolladores originales, a través del servicio «Endless Lifecycle Support».

Solicita un presupuesto y te explicaremos cómo sería una prueba piloto con un repositorio de grupo en tu propio árbol de dependencias.

PREGUNTAS FRECUENTES

¿Qué alternativas hay a Sonatype Nexus Firewall?

Hay muchos productos que compiten con Nexus Firewall —ahora denominado Sonatype Repository Firewall— en lo que respecta al análisis y la curación. En este artículo, el término tiene un significado más específico: se refiere a un enfoque que responde a una cuestión adicional de confianza, a saber, si un artefacto publicado coincide con la fuente a partir de la cual afirma haberse compilado. La selección y la verificación de la recompilación suelen llevarse a cabo junto con un gestor de repositorios, en lugar de en su lugar, ya que este último sigue encargándose del almacenamiento en caché y la disponibilidad.

¿Puede el análisis binario detectar un archivo JAR manipulado?

A veces. Un escáner examina el contenido del artefacto, y el análisis de comportamiento puede detectar código sospechoso dentro de un archivo JAR manipulado sin que exista ningún aviso al respecto. Lo que el escáner no puede hacer por sí solo es determinar que el artefacto difiere de su código fuente declarado, y para ello es necesaria una comparación entre el código fuente y el artefacto.

¿Es posible realizar compilaciones reproducibles en Java?

Sí. Maven admite una propiedad de marca de tiempo de salida de la compilación que fija los metadatos del archivo, y el modo de compilaciones reproducibles está habilitado de forma predeterminada desde la versión Maven 4.0.0-beta-5. Con un entorno de compilación suficientemente controlado, el mismo código fuente puede generar archivos JAR idénticos hasta el último byte. La cobertura en Maven Central sigue siendo parcial, por lo que la reproducibilidad varía según el proyecto.

¿Maven verifica las firmas PGP de forma predeterminada?

No. Maven Central exige a los editores que proporcionen una firma en el momento de la publicación, pero el proceso habitual de resolución de dependencias de Maven verifica las sumas de comprobación en lugar de dichas firmas. La verificación de firmas requiere herramientas o complementos adicionales.

¿Tengo que sustituir Nexus o Artifactory para utilizar SecureChain?

No. El proxy de un gestor de repositorios apunta a una URL remota configurable, por lo que cambiar a SecureChain modifica el destino al que apunta el proxy, en lugar de eliminar el propio gestor de repositorios. Cuando el gestor de repositorios existente sigue siendo el punto final al que se dirigen las compilaciones, la configuración de los desarrolladores, los archivos de proyecto y los grupos existentes pueden permanecer sin cambios.

¿Qué ocurre con los artefactos que no se pueden reproducir en la fase inicial?

Una comparación byte a byte deja de ser posible en cuanto una compilación genera un resultado no determinista, por lo que la verificación recurre a análisis adicionales. Esa evidencia es menos sólida que una coincidencia exacta y reproducible, pero aún así aporta más información que un simple análisis del binario.

Resumen

Nombre del artículo

Alternativa a Sonatype Nexus Firewall que se compila a partir del código fuente

Descripción

Cómo una alternativa a Sonatype Nexus Firewall recompila paquetes Java a partir del código fuente, y por qué el análisis no puede garantizar la integridad del código fuente.

Autor

Tim Walker

Nombre del editor

TuxCare

Logotipo de la editorial