O Nexus Firewall verifica os arquivos binários, enquanto o SecureChain os recompila a partir do código-fonte

Principais conclusões

• A verificação informa o que há dentro de um JAR, e não se ele corresponde ao código-fonte publicado pelo projeto.
• Uma compilação adulterada com coordenadas válidas é a lacuna que nem as assinaturas nem os bancos de dados de alertas conseguem preencher.
• O Maven possui ferramentas maduras para compilação reproduzível, o que torna o Java bem adequado para a verificação independente de recompilações.
• O SecureChain fica a montante do proxy do Nexus ou do Artifactory para o qual suas compilações já apontam.

O Sonatype Repository Firewall (anteriormente conhecido como Nexus Firewall) detecta muitas ameaças antes que elas cheguem à sua compilação. Ele é capaz de bloquear vulnerabilidades conhecidas, violações de políticas e componentes que seus sistemas de inteligência e aprendizado de máquina sinalizam como maliciosos ou suspeitos, de acordo com as políticas que você aplica no proxy. O que nada disso determina é se o JAR que acabou de ser inspecionado foi realmente compilado a partir do código-fonte publicado pelo projeto. Essa lacuna é o motivo pelo qual as equipes de segurança começam a procurar uma alternativa ao Sonatype Nexus Firewall assim que se deparam com um artefato adulterado sob coordenadas válidas — um problema para o qual a verificação nunca foi projetada para dar resposta.

Este guia explica o que a verificação binária pode e não pode verificar, qual é a posição do Sonatype Firewall e do JFrog Xray em relação a essa questão e como o SecureChain recompila pacotes Java a partir do código-fonte, sem alterar sua configuração existente do Nexus ou do Artifactory.

O que a varredura binária pode e não pode responder

Três questões distintas são tratadas como uma única na maioria das avaliações, e separá-las torna o restante desta comparação mais simples.

O Maven Central não aceita uma versão sem uma assinatura PGP. No entanto, o Maven não verifica essas assinaturas durante a resolução normal de dependências. Ele verifica as somas de verificação para garantir a integridade da transmissão, e o fato de uma incompatibilidade realmente causar a falha na compilação depende do repositório checksumPolicy configuração, cujo valor padrão é warn em vez de fail.

Um artefato malicioso assinado corretamente e um artefato legítimo assinado corretamente parecem idênticos a uma compilação padrão, já que a assinatura apenas comprova que alguém com a chave correta o produziu, e não que a chave pertença ao editor que você esperava.

Abordamos os mecanismos dessa vulnerabilidade com mais detalhes em nossa análise do incidente envolvendo o sósia de Jackson, incluindo como a exigência de assinatura do Maven pode ser contornada por um invasor que simplesmente controla sua própria chave.

O Gradle oferece um controle mais direto nesse aspecto.

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

Esse comando gera metadados de verificação e, depois que você os revisar e os confirmar como uma linha de base confiável, as compilações futuras falharão sempre que houver alguma discrepância. A etapa de revisão é fundamental. O Gradle inicia de forma otimista a partir do que quer que seus repositórios estejam disponibilizando naquele momento; portanto, o arquivo gerado registra o que você já possui, em vez de comprovar que ele já foi confiável. Usado dessa forma, é um forte mecanismo de controle nativo.

A verificação de assinatura e a verificação da compilação não são o mesmo controle. Uma conta de editor comprometida gera um JAR assinado corretamente, contendo código que nunca esteve presente em seu próprio repositório de código-fonte. A verificação da assinatura confirma que o artefato veio dessa conta. Ela não indica se a compilação dessa conta corresponde ao código-fonte que ela alega representar.

A Classe de Artefatos Adulterados

Um invasor com acesso de publicação pode compilar um projeto, inserir uma alteração na saída compilada ou compilar a partir de uma árvore de trabalho modificada e publicar normalmente. As somas de verificação permanecem consistentes, uma vez que apenas confirmam se o arquivo recebido corresponde ao arquivo que está sendo servido. A assinatura pode permanecer válida se o invasor controlar a chave de assinatura vinculada àquela conta. O repositório de código-fonte no GitHub permanece inalterado, pois nada no JAR publicado requer um commit correspondente.

Uma verificação desse JAR com base em vulnerabilidades ou assinaturas pode muito bem não detectar nada, pois não existe nenhum aviso para um pacote que ainda não tenha sido identificado como comprometido. A análise comportamental é uma verdadeira segunda camada e pode sinalizar códigos suspeitos por conta própria, mas a cobertura varia significativamente de acordo com o ecossistema. A JFrog documenta que seus scanners automatizados de pacotes maliciosos operam continuamente no npm e no PyPI, enquanto indica que a cobertura do Maven se limita apenas a pacotes maliciosos já conhecidos. De qualquer forma, nenhuma das duas abordagens determina se o JAR publicado corresponde ao código-fonte do projeto.

Esse é um ataque diferente do Um sósia de Jackson que apareceu no Maven Central em dezembro de 2025, que utilizava a suplantação de namespace, um pacote publicado sob um groupId a apenas um prefixo de distância da biblioteca real. Esse tipo de situação pode ser detectado pela política, desde que você tenha controles de namespace configurados, pois as próprias coordenadas estão incorretas. A política de namespace não consegue identificar adulterações em coordenadas que, de outra forma, seriam válidas, pois nem as coordenadas nem uma assinatura válida revelam a incompatibilidade de origem.

Este artigo trata de compilações adulteradas sob coordenadas válidas. Esse não é o único tipo de ataque com o qual as equipes de Java precisam se preocupar, mas é aquele que a verificação comum de binários não consegue resolver por si só; por isso, requer um mecanismo de controle específico, em vez de uma solicitação de recurso para uma ferramenta já existente.

O que o Sonatype Repository Firewall e o JFrog Xray realmente verificam

O Sonatype Repository Firewall inspeciona os componentes no momento em que eles entram em um repositório. Seu recurso “Release Integrity” aplica aprendizado de máquina às novas versões, sinaliza comportamentos incomuns e encaminha qualquer elemento suspeito para a equipe de pesquisa da Sonatype, enquanto o Repository Firewall original mantém os componentes sinalizados em quarentena até que a análise os libere. Esse é um controle real e útil, e trata-se de uma operação diferente da confirmação de que um artefato corresponde à sua fonte.

A Sonatype comercializa esse serviço em dois níveis. O Repository Firewall completo se integra a um gerenciador de repositórios, abrangendo tanto o Nexus Repository quanto as implantações compatíveis do JFrog Artifactory, e inclui quarentena e proteção contra confusão de namespaces em uma longa lista de formatos de pacotes. O Firewall Pro é um serviço de proxy SaaS mais leve, que abrange npm, Maven, PyPI e NuGet, e permite ou bloqueia um componente diretamente, em vez de mantê-lo em quarentena. Os materiais de nenhum dos dois planos descrevem uma etapa de recompilação ou comparação de código-fonte, o que é a diferença que importa neste contexto.

O JFrog Xray indexa artefatos e os correlaciona com informações sobre vulnerabilidades e pacotes maliciosos; seu sistema de detecção de pacotes maliciosos combina varreduras automatizadas e validação por pesquisadores para gerar uma pontuação de malícia. Separadamente, o Evidence Service da JFrog pode anexar atestados assinados descrevendo como uma compilação foi produzida, o que constitui um recurso genuíno de proveniência da cadeia de suprimentos. Trata-se, ainda assim, de confiança em uma declaração assinada, em vez de verificação por meio de uma recompilação independente. Alguém precisa assinar o atestado, e a confiabilidade do atestado depende inteiramente de quem o produziu.

O SecureChain para Java aborda essa questão por outro ângulo. Em vez de verificar o binário do editor, ele analisa o código-fonte e, em seguida, compila seu próprio artefato a partir desse código-fonte em um ambiente isolado e fortificado, fornecendo, junto com ele, a proveniência SLSA Nível 3. Não há nenhum binário de origem para ser verificado, pois sua compilação nunca entra em contato com aquele que a Sonatype ou a JFrog teriam inspecionado. Esse é, atualmente, o cerne prático da segurança do repositório Maven. Não se trata de qual logotipo de fornecedor aparece no painel, mas de qual pergunta cada camada realmente responde.

Por que o Java é uma boa opção para recompilar a partir do código-fonte

Artefatos compilados parecem ser um alvo inadequado para esse tipo de verificação. De qualquer forma, a Java passou anos construindo a infraestrutura que torna isso viável, por meio de um esforço genuíno de compilações reproduzíveis dentro do ecossistema do Maven.

Configurando o project.build.outputTimestamp Essa propriedade fornece aos plug-ins compatíveis um carimbo de data e hora fixo para ser inserido nos arquivos gerados, o que elimina uma das maiores fontes de não determinismo em um JAR.

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

Com essa configuração e um ambiente de compilação suficientemente controlado, a compilação do mesmo código-fonte pode produzir JARs com o mesmo conteúdo em bytes. A partir do Maven 4.0.0-beta-5, o modo de compilações reproduzíveis está ativado por padrão, sem a necessidade de definir nenhuma propriedade; no entanto, o Maven 4 ainda não atingiu a disponibilidade geral e a versão 3.9.x continua sendo a linha de versões mantida; portanto, as equipes que ainda utilizam o Maven 3.x precisam definir a propriedade explicitamente.

mvn artifact:check-buildplan
mvn artifact:compare

O primeiro comando indica quais plug-ins precisam ser atualizados para que a saída reproduzível funcione corretamente. O segundo, o objetivo “compare” do maven-artifact-plugin, verifica exatamente essa afirmação, comparando uma compilação local com uma compilação de referência — normalmente aquela publicada no Maven Central. A Apache faz questão de ressaltar que uma comparação no mesmo ambiente não comprova a reprodutibilidade por terceiros, pois ambas as compilações podem herdar o mesmo vazamento ambiental. A verificação real significa recompilar em outro lugar.

O Reproducible Central rastreia quais versões do Maven Central tiveram tentativas de recompilação independentes, e a cobertura é genuinamente parcial, em vez de ser quase universal. Um estudo acadêmico de 2024 observou que o Reproducible Central relatou tentativas de recompilação para 2.547 versões em 531 projetos, em comparação com os mais de 10 milhões de versões e 479.000 IDs de artefatos únicos no Maven Central, conforme o snapshot de maio de 2023. Esses números referem-se a esse snapshot específico, e não ao registro atual, e mostram o quão parcial era a cobertura verificada de forma independente naquela época.

O Go e o Rust reduzem em parte o problema da confiança em binários, pois as dependências são comumente distribuídas como código-fonte e protegidas por mecanismos de integridade do ecossistema. Isso não é o mesmo que provar que um pacote publicado corresponde a uma revisão específica do código-fonte do upstream. O ecossistema Maven do Java fez um investimento comparável especificamente em resultados binários reproduzíveis, estando à frente do que os wheels do Python com extensões compiladas e os tarballs criados por editores do npm geralmente oferecem atualmente.

O que a opção “Recompilar a partir do código-fonte” realmente exige do upstream

A comparação de reconstrução gera evidências auditáveis sobre se a compilação corresponde ao seu código-fonte. Quando a compilação de um projeto ainda incorpora carimbos de data/hora variáveis ou outros metadados não determinísticos, uma comparação byte a byte falhará mesmo que o código-fonte subjacente não tenha sofrido nenhuma alteração, independentemente de quem a esteja executando.

No caso desses artefatos, a comparação passa de uma prova para uma análise. As evidências são necessariamente mais fracas e exigem mais trabalho para serem interpretadas, o que vale a pena saber antes de definir o escopo de uma implementação com base nelas. Ainda é um sinal significativo, mas não se trata de uma correspondência byte a byte.

As dependências ocultadas e realocadas tornam isso ainda mais difícil. Os plug-ins do Shade reescrevem os nomes dos pacotes e as dependências embutidas, o que altera o próprio objeto de análise de uma comparação estrutural. Isso ocorre com frequência suficiente no Java corporativo a ponto de valer a pena abordar o assunto diretamente durante uma avaliação.

Uma alternativa ao Sonatype Nexus Firewall não significa substituir o Nexus

O repositório proxy de um gerenciador de repositórios aponta para uma URL remota. Essa URL é normalmente https://repo1.maven.org/maven2/. Definir um outro destino é uma opção de configuração, não um projeto de migração.

O fluxo de trabalho do desenvolvedor permanece o mesmo, e os arquivos do projeto não precisam ser alterados, desde que o gerenciador de repositórios continue sendo o ponto de conexão para a compilação. Seus grupos, repositórios hospedados e políticas de limpeza existentes permanecem inalterados. O gerenciador de repositórios continua responsável pelo cache, pela disponibilidade e pelas políticas. O repositório upstream do qual ele armazena em cache passa a ser uma fonte filtrada e recompilada, em vez da fonte pública.

Faça duas coisas ao mesmo tempo que realiza a troca. Mantenha suas regras de exclusão de namespace no proxy, já que impedir que suas próprias coordenadas internas sejam resolvidas no servidor upstream é o mecanismo de controle que resiste a desvios de configuração e não tem nada a ver com o servidor upstream para o qual você está direcionado. Em seguida, verifique sua configuração de espelho, pois o Maven respeita os repositórios declarados dentro do próprio POM de uma dependência, e uma dependência transitiva pode adicionar um a seu conjunto de resolução sem que você precise declará-lo. A mirrorOf conjunto de regras definido apenas para central não irá interceptá-los; portanto, verifique se a sua configuração abrange todos os repositórios externos que você pretende rotear por meio do gerenciador de repositórios. Nosso artigo sobre A lacuna no arquivo settings.xml do Maven aborda esse modo de falha específico com mais detalhes. Verifique isso independentemente de para onde seu proxy esteja direcionado, já que se trata de um risco pré-existente na configuração do Maven, e não de algo introduzido pela mudança de fornecedores.

Qual configuração é a mais adequada?

Se você estiver avaliando uma alternativa ao Sonatype Nexus Firewall especificamente devido à preocupação com artefatos adulterados, comece diretamente por essa questão, em vez de fazer uma comparação geral de recursos.

As equipes que já utilizam o Nexus ou o Artifactory têm o caminho mais fácil, pois se trata de uma alteração na URL do proxy e de um projeto-piloto em um único repositório do grupo. Se o seu modelo de ameaças não incluir especificamente artefatos adulterados, a verificação já existente pode ser suficiente; além disso, as regras de exclusão de namespace e os metadados de verificação do Gradle são controles gratuitos que abordam outras rotas comuns de ataque à cadeia de suprimentos.

Ambientes regulamentados que exigem comprovação de proveniência tiram o máximo proveito da comparação de reconstruções, uma vez que ela gera evidências auditáveis, e a questão da reprodutibilidade por dependência é o que deve ser definido em primeiro lugar. E se você estiver operando vários ecossistemas além do Java, avalie isso como uma decisão no nível da pilha, em vez de uma única aquisição, já que um controle restrito apenas ao Java deixa o restante da pilha exatamente onde estava.

Veja o que o SecureChain reconstrói antes de tomar uma decisão

Se sua configuração do Nexus ou do Artifactory já lida bem com cache, disponibilidade e políticas, e a questão em aberto é se o que está passando por esse pipeline realmente corresponde à sua fonte, é para isso que o SecureChain para Java foi criado, sem interferir no gerenciador de repositórios que você já utiliza. O mesmo registro continua fornecendo correções de vulnerabilidades para suas dependências após o término da manutenção do upstream, por meio do Suporte de Ciclo de Vida Ilimitado.

Solicite um orçamento e vamos explicar como seria um projeto-piloto com um repositório único para um grupo, aplicado à sua própria árvore de dependências.

Perguntas frequentes

O que é uma alternativa ao Sonatype Nexus Firewall?

Existem diversos produtos que competem com o Nexus Firewall — agora chamado de Sonatype Repository Firewall — nas áreas de verificação e curadoria. Neste artigo, o termo tem um significado mais restrito: uma abordagem que responde a uma questão adicional de confiança, a saber, se um artefato publicado corresponde à fonte a partir da qual alega ter sido construído. A triagem e a verificação da reconstrução geralmente são executadas em conjunto com um gerenciador de repositório, e não em seu lugar, já que o gerenciador de repositório continua sendo responsável pelo armazenamento em cache e pela disponibilidade.

A verificação binária consegue detectar um arquivo JAR adulterado?

Às vezes. Um scanner examina o conteúdo do artefato, e a análise comportamental pode sinalizar a presença de código suspeito dentro de um JAR adulterado, mesmo que não haja nenhum aviso relacionado a ele. O que a verificação por si só não consegue fazer é determinar se o artefato difere da fonte declarada, e para isso é necessária uma comparação entre a fonte e o artefato.

É possível realizar compilações reproduzíveis em Java?

Sim. O Maven oferece suporte a uma propriedade de carimbo de data e hora da saída da compilação que fixa os metadados do arquivo, e o modo de compilações reproduzíveis está habilitado por padrão desde o Maven 4.0.0-beta-5. Com um ambiente de compilação suficientemente controlado, o mesmo código-fonte pode produzir JARs com conteúdo byte a byte idêntico. A cobertura no Maven Central ainda é parcial, portanto, a reprodutibilidade varia de acordo com o projeto.

O Maven verifica assinaturas PGP por padrão?

Não. O Maven Central exige que os editores forneçam uma assinatura no momento da publicação, mas a resolução normal de dependências do Maven verifica as somas de verificação, e não essas assinaturas. A verificação de assinaturas requer ferramentas ou plug-ins adicionais.

Preciso substituir o Nexus ou o Artifactory para usar o SecureChain?

Não. O proxy de um gerenciador de repositório aponta para uma URL remota configurável; portanto, a migração para o SecureChain altera o destino do proxy, em vez de remover o próprio gerenciador de repositório. Quando o gerenciador de repositório existente continua sendo o ponto de extremidade para a compilação, a configuração dos desenvolvedores, os arquivos de projeto e os grupos existentes podem permanecer inalterados.

O que acontece com os artefatos que não são reproduzíveis no upstream?

Uma comparação byte a byte deixa de ser possível quando uma compilação produz uma saída não determinística; assim, a verificação recorre a análises adicionais. Essa evidência é mais fraca do que uma correspondência exata e reproduzível, mas ainda assim fornece mais informações do que uma simples varredura do binário.

Resumo

Nome do artigo

Alternativa ao Sonatype Nexus Firewall que é recompilada a partir do código-fonte

Descrição

Como uma alternativa ao Sonatype Nexus Firewall recompila pacotes Java a partir do código-fonte e por que a verificação não pode comprovar a integridade do código-fonte.

Autor

Tim Walker

Nome da editora

TuxCare

Logotipo da editora