Nexus Firewall scannt Binärdateien, während SecureChain diese aus dem Quellcode neu kompiliert

Wichtigste Erkenntnisse

• Durch das Scannen erfahren Sie, was sich in einer JAR-Datei befindet, nicht jedoch, ob der Inhalt mit dem vom Projekt veröffentlichten Quellcode übereinstimmt.
• Ein manipulierter Build unter gültigen Koordinaten ist die Lücke, die weder Signaturen noch Advisory-Datenbanken schließen können.
• Maven verfügt über ausgereifte Werkzeuge für reproduzierbare Builds, wodurch sich Java gut für die unabhängige Überprüfung von Neubauprozessen eignet.
• SecureChain ist dem Nexus- oder Artifactory-Proxy vorgeschaltet, auf den Ihre Builds bereits verweisen.

Die Sonatype Repository Firewall (ehemals Nexus Firewall) fängt vieles ab, bevor es überhaupt Ihren Build erreicht. Sie kann bekannte Schwachstellen, Richtlinienverstöße und Komponenten blockieren, die von ihren Intelligence- und Machine-Learning-Systemen als bösartig oder verdächtig gekennzeichnet werden – entsprechend den Richtlinien, die Sie am Proxy durchsetzen. Was dabei jedoch nicht festgestellt wird, ist, ob die soeben geprüfte JAR-Datei tatsächlich aus dem vom Projekt veröffentlichten Quellcode erstellt wurde. Diese Lücke ist der Grund, warum Sicherheitsteams nach einer Alternative zur Sonatype Nexus Firewall suchen, sobald sie auf ein manipuliertes Artefakt unter gültigen Koordinaten stoßen – ein Problem, für dessen Lösung das Scannen nie ausgelegt war.

Dieser Leitfaden erläutert, was sich durch das Scannen von Binärdateien überprüfen lässt und was nicht, wie Sonatype Firewall und JFrog Xray in dieser Hinsicht abschneiden und wie SecureChain Java-Pakete stattdessen aus dem Quellcode neu erstellt, ohne Ihre bestehende Nexus- oder Artifactory-Konfiguration zu beeinträchtigen.

Was das binäre Scannen beantworten kann und was nicht

Drei separate Fragen werden in den meisten Bewertungen als eine einzige behandelt, und wenn man sie voneinander trennt, wird der Rest dieses Vergleichs übersichtlich.

Maven Central akzeptiert keine Releases ohne PGP-Signatur. Maven überprüft diese Signaturen jedoch nicht während der normalen Abhängigkeitsauflösung. Es überprüft die Prüfsummen auf die Integrität der Datenübertragung, und ob eine Nichtübereinstimmung tatsächlich zum Fehlschlagen des Builds führt, hängt von den Einstellungen des Repositorys ab. checksumPolicy Einstellung, deren Standardwert warn anstatt fail.

Ein korrekt signiertes bösartiges Artefakt und ein korrekt signiertes legitimes Artefakt sehen bei einer Standard-Erstellung identisch aus, da die Signatur lediglich belegt, dass jemand mit dem richtigen Schlüssel es erstellt hat – nicht jedoch, dass der Schlüssel dem erwarteten Herausgeber gehört.

In unserer Analyse des Vorfalls mit dem Jackson-Doppelgänger haben wir die Funktionsweise dieser Sicherheitslücke ausführlicher behandelt, darunter auch, wie ein Angreifer, der lediglich seinen eigenen Schlüssel kontrolliert, die Signaturanforderung von Maven umgehen kann.

Gradle bietet Ihnen hier eine direktere Kontrolle.

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

Dieser Befehl generiert Metadaten zur Verifizierung. Sobald Sie diese überprüft und als vertrauenswürdige Baseline festgeschrieben haben, schlagen zukünftige Builds bei allen Abweichungen fehl. Der Überprüfungsschritt ist entscheidend. Gradle führt einen optimistischen Bootstrap-Vorgang anhand der Daten durch, die Ihre Repositorys zu diesem Zeitpunkt bereitstellen. Die generierte Datei hält also lediglich fest, was bereits vorhanden ist, anstatt zu belegen, dass diese Daten jemals vertrauenswürdig waren. Auf diese Weise genutzt, stellt dies eine starke native Kontrollmöglichkeit dar.

Die Überprüfung der Signatur und die Überprüfung des Builds sind nicht dasselbe Kontrollverfahren. Ein kompromittiertes Publisher-Konto erzeugt eine korrekt signierte JAR-Datei, die Code enthält, der im eigenen Quellcode-Repository nie vorhanden war. Die Überprüfung der Signatur bestätigt, dass das Artefakt von diesem Konto stammt. Sie sagt jedoch nichts darüber aus, ob der Build dieses Kontos mit dem Quellcode übereinstimmt, den er angeblich repräsentiert.

Die Klasse der manipulierten Artefakte

Ein Angreifer mit Veröffentlichungsrechten kann ein Projekt erstellen, eine Änderung in die kompilierte Ausgabe einfügen oder aus einem modifizierten Arbeitsverzeichnis heraus erstellen und anschließend wie gewohnt veröffentlichen. Die Prüfsummen bleiben konsistent, da sie lediglich bestätigen, dass die eingegangene Datei mit der bereitgestellten Datei übereinstimmt. Die Signatur kann gültig bleiben, wenn der Angreifer den mit diesem Konto verknüpften Signaturschlüssel kontrolliert. Das Quell-Repository auf GitHub bleibt unberührt, da für die veröffentlichte JAR-Datei kein entsprechender Commit erforderlich ist.

Ein auf Schwachstellen oder Signaturen basierender Scan dieser JAR-Datei könnte durchaus keine Probleme aufzeigen, da noch keine Sicherheitswarnung für ein Paket vorliegt, das bisher von niemandem als kompromittiert identifiziert wurde. Die Verhaltensanalyse stellt eine echte zweite Schutzebene dar und kann verdächtigen Code eigenständig kennzeichnen, doch die Abdeckung variiert je nach Ökosystem stark. JFrog dokumentiert, dass seine automatisierten Scanner für bösartige Pakete kontinuierlich npm und PyPI überprüfen, während die Abdeckung für Maven lediglich auf bekannte bösartige Pakete beschränkt ist. In jedem Fall lässt sich mit keinem der beiden Ansätze feststellen, ob die veröffentlichte JAR-Datei mit dem Quellcode des Projekts übereinstimmt.

Das ist eine andere Art von Angriff als der Ein Jackson-Doppelgänger, der im Dezember 2025 in Maven Central auftauchte, das die Namespace-Identitätsübernahme nutzte, ein unter einem groupId nur ein Präfix von der echten Bibliothek entfernt. So etwas lässt sich durch Richtlinien abfangen, vorausgesetzt, Sie haben Namespace-Kontrollen konfiguriert, da die Koordinaten selbst falsch sind. Namespace-Richtlinien können Manipulationen bei ansonsten gültigen Koordinaten nicht erkennen, da weder die Koordinaten noch eine gültige Signatur die Diskrepanz bei der Quelle offenbaren.

In diesem Beitrag geht es um manipulierte Builds unter gültigen Koordinaten. Dies ist zwar nicht die einzige Angriffsmethode, vor der sich Java-Anwender in Acht nehmen müssen, aber es ist diejenige, die durch gewöhnliche Binärdatei-Scans allein nicht abgewehrt werden kann. Aus diesem Grund bedarf es einer eigenen Kontrollmaßnahme und nicht nur einer Funktionsanforderung an ein bestehendes Tool.

Was Sonatype Repository Firewall und JFrog Xray tatsächlich überprüfen

Die Sonatype Repository Firewall überprüft Komponenten bei ihrer Aufnahme in ein Repository. Ihre Funktion „Release Integrity“ wendet maschinelles Lernen auf neue Releases an, kennzeichnet ungewöhnliches Release-Verhalten und leitet verdächtige Fälle an das Forschungsteam von Sonatype weiter, wobei die ursprüngliche Repository Firewall die gekennzeichneten Komponenten so lange in Quarantäne hält, bis sie nach der Überprüfung freigegeben werden. Dies ist eine echte, nützliche Kontrollmaßnahme, die sich von der Überprüfung der Übereinstimmung eines Artefakts mit seiner Quelle unterscheidet.

Sonatype bietet dies in zwei Stufen an. Die vollständige Repository-Firewall lässt sich in einen Repository-Manager integrieren und deckt sowohl Nexus Repository als auch unterstützte JFrog Artifactory-Bereitstellungen ab; sie umfasst zudem Quarantäne- und Namespace-Verwechslungsschutz für eine Vielzahl von Paketformaten. Firewall Pro ist ein schlankerer SaaS-Proxy-Dienst, der npm, Maven, PyPI und NuGet abdeckt und Komponenten entweder direkt zulässt oder blockiert, anstatt sie in Quarantäne zu halten. In den Informationsmaterialien beider Tarife wird kein Schritt zum Neuaufbau oder zum Quellcodevergleich beschrieben – und genau dieser Unterschied ist hier entscheidend.

JFrog Xray indexiert Artefakte und gleicht sie mit Informationen zu Sicherheitslücken und bösartigen Paketen ab, wobei das System zur Erkennung bösartiger Pakete automatisierte Scans und die Validierung durch Forscher zu einem „Maliciousness Score“ kombiniert. Unabhängig davon kann der Evidence Service von JFrog signierte Bescheinigungen anhängen, die beschreiben, wie ein Build erstellt wurde – eine echte Funktion zur Rückverfolgbarkeit in der Lieferkette. Dabei handelt es sich jedoch nach wie vor um das Vertrauen in eine signierte Aussage und nicht um eine Verifizierung durch einen unabhängigen Neuaufbau. Jemand muss die Bescheinigung signieren, und die Bescheinigung ist nur so vertrauenswürdig wie die Person, die sie erstellt hat.

SecureChain for Java geht das Problem von der anderen Seite an. Anstatt die Binärdatei des Herausgebers zu scannen, überprüft es den Quellcode und kompiliert anschließend in einer gehärteten, isolierten Umgebung ein eigenes Artefakt aus diesem Quellcode, das mit einer SLSA-Provenienz der Stufe 3 ausgeliefert wird. Es gibt keine vorgelagerte Binärdatei, die gescannt werden müsste, da Ihr Build niemals mit der Binärdatei in Berührung kommt, die Sonatype oder JFrog überprüft hätten. Das ist derzeit der praktische Kern der Sicherheit von Maven-Repositorys. Es geht nicht darum, welches Anbieterlogo auf dem Dashboard zu sehen ist, sondern darum, welche Frage jede Ebene tatsächlich beantwortet.

Warum Java eine gute Grundlage für die Neuerstellung aus dem Quellcode ist

Kompilierte Artefakte scheinen für diese Art der Verifikation kein geeignetes Ziel zu sein. Java hat jedoch über Jahre hinweg eine Infrastruktur aufgebaut, die dies dennoch machbar macht – und zwar durch echte Bemühungen um reproduzierbare Builds innerhalb des Maven-Ökosystems.

Einstellung der project.build.outputTimestamp Diese Eigenschaft stellt kompatiblen Plugins einen festen Zeitstempel zur Verfügung, den sie in die generierten Archive einfügen können, wodurch eine der größten Ursachen für Nichtdeterminismus in einer JAR-Datei beseitigt wird.

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

Wenn diese Einstellung vorgenommen wurde und eine ausreichend kontrollierte Build-Umgebung vorliegt, kann das Kompilieren desselben Quellcodes zu byte-identischen JAR-Dateien führen. Ab Maven 4.0.0-beta-5 ist der Modus für reproduzierbare Builds standardmäßig aktiviert, ohne dass eine Eigenschaft festgelegt werden muss. Da Maven 4 jedoch noch nicht allgemein verfügbar ist und 3.9.x weiterhin die gepflegte Release-Reihe ist, müssen Teams, die noch mit Maven 3.x arbeiten, die Eigenschaft explizit festlegen.

mvn artifact:check-buildplan
mvn artifact:compare

Der erste Befehl zeigt Ihnen an, welche Plugins aktualisiert werden müssen, bevor reproduzierbare Ergebnisse einwandfrei funktionieren. Der zweite Befehl – das „compare“-Ziel des „maven-artifact-plugin“ – überprüft genau diese Aussage, indem er einen lokalen Build mit einem Referenz-Build vergleicht, bei dem es sich in der Regel um den in Maven Central veröffentlichten Build handelt. Apache weist ausdrücklich darauf hin, dass ein Vergleich innerhalb derselben Umgebung die Reproduzierbarkeit durch Dritte nicht belegt, da beide Builds dieselben Umgebungsbeeinträchtigungen aufweisen können. Eine echte Überprüfung erfordert daher einen Neuaufbau an einem anderen Ort.

Reproducible Central erfasst, bei welchen Maven-Central-Releases unabhängige Neuerstellungsversuche unternommen wurden, wobei die Abdeckung eher lückenhaft als nahezu vollständig ist. Eine wissenschaftliche Studie aus dem Jahr 2024 stellte fest, dass Reproducible Central Neuaufbauversuche für 2.547 Releases in 531 Projekten meldete, verglichen mit den über 10 Millionen Releases und 479.000 eindeutigen Artefakt-IDs auf Maven Central gemäß dessen Snapshot vom Mai 2023. Diese Zahlen beziehen sich auf diesen Snapshot und nicht auf den aktuellen Stand des Registers; sie zeigen, wie lückenhaft die unabhängig verifizierte Abdeckung zu jenem Zeitpunkt war.

Go und Rust mindern das Problem des Vertrauens in Binärdateien teilweise, da Abhängigkeiten in der Regel als Quellcode verteilt und durch Mechanismen zur Gewährleistung der Integrität des Ökosystems geschützt werden. Das ist jedoch nicht dasselbe wie der Nachweis, dass ein veröffentlichtes Paket einer bestimmten Quellcode-Revision des Upstream-Entwicklers entspricht. Das Maven-Ökosystem von Java hat vergleichbare Anstrengungen speziell im Hinblick auf reproduzierbare Binärausgaben unternommen und liegt damit weiter fortgeschritten als Python-Wheels mit kompilierten Erweiterungen und die von Anbietern erstellten Tarballs von npm, wie sie heute allgemein üblich sind.

Was „Rebuild From Source“ tatsächlich vom Upstream erfordert

Ein Rebuild-Vergleich liefert nachprüfbare Nachweise dafür, ob der Build mit seiner Quelle übereinstimmt. Wenn der Build eines Projekts weiterhin unterschiedliche Zeitstempel oder andere nichtdeterministische Metadaten enthält, schlägt ein Byte-für-Byte-Vergleich fehl, selbst wenn sich die zugrunde liegende Quelle überhaupt nicht geändert hat – unabhängig davon, wer den Vergleich durchführt.

Bei diesen Artefakten verliert der Vergleich seinen Charakter als Beweis und wird zur Analyse. Die Beweiskraft ist zwangsläufig geringer, und die Interpretation erfordert mehr Aufwand – das sollte man wissen, bevor man eine Einführung darauf aufbaut. Es handelt sich zwar immer noch um ein aussagekräftiges Signal, aber es ist keine Byte-für-Byte-Übereinstimmung.

Durch „Shaded“ und „Relocated“ Dependencies wird dies noch schwieriger. „Shade“-Plugins schreiben Paketnamen und Inline-Dependencies um, wodurch sich die Grundlage für einen strukturellen Vergleich ändert. Da dies im Enterprise-Java-Bereich häufig vorkommt, lohnt es sich, dieses Thema bereits während einer Evaluierung direkt anzusprechen.

Eine Alternative zur Sonatype Nexus Firewall bedeutet nicht, dass Nexus ersetzt wird

Das Proxy-Repository eines Repository-Managers verweist auf eine Remote-URL. Diese URL lautet normalerweise https://repo1.maven.org/maven2/. Die Umleitung auf eine andere Adresse erfolgt über ein Konfigurationsfeld und ist kein Migrationsprojekt.

Der Entwickler-Workflow bleibt unverändert, und an den Projektdateien müssen keine Änderungen vorgenommen werden, solange der Repository-Manager weiterhin als Endpunkt für den Build-Prozess fungiert. Ihre bestehenden Gruppen, gehosteten Repositorys und Bereinigungsrichtlinien bleiben unverändert. Der Repository-Manager ist weiterhin für das Caching, die Verfügbarkeit und die Richtlinien zuständig. Der Upstream, von dem aus er cacht, wird anstelle der öffentlichen Quelle zu einer gefilterten, neu erstellten Quelle.

Führen Sie parallel zum Austausch zwei Maßnahmen durch. Behalten Sie Ihre Regeln zum Ausschluss von Namespaces auf dem Proxy bei, da die Blockierung der Auflösung Ihrer eigenen internen Koordinaten im Upstream die Kontrollmaßnahme ist, die Konfigurationsabweichungen standhält und nichts damit zu tun hat, auf welchen Upstream Sie gerade verweisen. Überprüfen Sie anschließend Ihre Mirror-Konfiguration, da Maven Repositorys berücksichtigt, die im POM einer Abhängigkeit deklariert sind, und eine transitive Abhängigkeit kann Ihrem Auflösungssatz ein Repository hinzufügen, ohne dass Sie es jemals deklariert haben. A mirrorOf Regelsatz nur auf central Diese werden nicht abgefangen; stellen Sie daher sicher, dass Ihre Konfiguration alle externen Repositorys abdeckt, die Sie über den Repository-Manager weiterleiten möchten. Unser Artikel zu Die Lücke in der „settings.xml“-Datei von Maven behandelt genau diesen Fehlerfall ausführlicher. Überprüfen Sie dies unabhängig davon, worauf Ihr Proxy verweist, da es sich um ein bereits bestehendes Risiko in der Maven-Konfiguration handelt und nicht um ein Problem, das durch den Wechsel des Upstreams verursacht wird.

Welche Konfiguration passt?

Wenn Sie eine Alternative zur Sonatype Nexus Firewall speziell aufgrund von Bedenken hinsichtlich manipulierter Artefakte in Betracht ziehen, sollten Sie direkt mit dieser Frage beginnen, anstatt zunächst einen allgemeinen Funktionsvergleich anzustellen.

Für Teams, die bereits Nexus oder Artifactory einsetzen, ist der Weg am einfachsten, da es sich hierbei um eine Änderung der Proxy-URL und einen Pilotversuch für ein Gruppen-Repository handelt. Wenn Ihr Bedrohungsmodell manipulierte Artefakte nicht ausdrücklich berücksichtigt, reichen möglicherweise bereits bestehende Scans aus, und Regeln zum Ausschluss von Namespaces sowie Gradle-Verifizierungsmetadaten sind kostenlose Kontrollmaßnahmen, die andere häufige Angriffspfade in der Lieferkette abdecken.

Regulierte Umgebungen, in denen Nachweise zur Herkunft erforderlich sind, profitieren am meisten vom Vergleich der Neuaufbauten, da dieser überprüfbare Nachweise liefert und die Frage der Reproduzierbarkeit pro Abhängigkeit als Erstes geklärt werden muss. Und wenn Sie neben Java noch mehrere andere Ökosysteme betreiben, sollten Sie dies als Entscheidung auf Stack-Ebene und nicht als Einzelkauf betrachten, da eine ausschließlich auf Java beschränkte Kontrolle den Rest des Stacks genau dort belässt, wo er ursprünglich war.

Informieren Sie sich darüber, was SecureChain neu aufbaut, bevor Sie sich entscheiden

Wenn Ihre Nexus- oder Artifactory-Konfiguration Caching, Verfügbarkeit und Richtlinien bereits gut abdeckt und die Frage ist, ob die Daten, die diese Pipeline durchlaufen, tatsächlich mit ihrer Quelle übereinstimmen, dann ist SecureChain for Java genau dafür gedacht – ohne den von Ihnen bereits genutzten Repository-Manager zu verändern. Dieselbe Registry liefert Ihnen auch nach Ende der Upstream-Wartung weiterhin Schwachstellenkorrekturen für Ihre Abhängigkeiten – dank des „Endless Lifecycle Support“.

Fordern Sie ein Angebot an, und wir zeigen Ihnen anhand Ihres eigenen Abhängigkeitsbaums, wie ein Pilotprojekt mit einem zentralen Repository aussehen würde.

FAQ

Was ist eine Alternative zur Sonatype Nexus Firewall?

Es gibt zahlreiche Produkte, die mit der Nexus Firewall – die mittlerweile Sonatype Repository Firewall heißt – in den Bereichen Scannen und Kuratierung konkurrieren. In diesem Artikel hat der Begriff eine engere Bedeutung: Er bezeichnet einen Ansatz, der eine zusätzliche Vertrauensfrage beantwortet, nämlich ob ein veröffentlichtes Artefakt mit der Quelle übereinstimmt, aus der es angeblich erstellt wurde. Das Screening und die Überprüfung des Neuaufbaus werden in der Regel parallel zu einem Repository-Manager durchgeführt und nicht an dessen Stelle, da der Repository-Manager weiterhin für das Caching und die Verfügbarkeit zuständig ist.

Kann ein binäres Scanverfahren eine manipulierte JAR-Datei erkennen?

Manchmal. Ein Scanner untersucht den Inhalt des Artefakts, und im Rahmen einer Verhaltensanalyse kann verdächtiger Code in einer manipulierten JAR-Datei identifiziert werden, ohne dass dazu eine entsprechende Sicherheitswarnung vorliegt. Was ein Scan allein nicht leisten kann, ist festzustellen, ob das Artefakt von der angegebenen Quelle abweicht; dazu ist ein Vergleich zwischen Quelle und Artefakt erforderlich.

Sind reproduzierbare Builds in Java möglich?

Ja. Maven unterstützt eine Eigenschaft für den Zeitstempel der Build-Ausgabe, die die Metadaten des Archivs festlegt, und der Modus für reproduzierbare Builds ist seit Maven 4.0.0-beta-5 standardmäßig aktiviert. In einer ausreichend kontrollierten Build-Umgebung können aus demselben Quellcode Byte-identische JAR-Dateien erzeugt werden. Die Abdeckung in Maven Central ist jedoch noch unvollständig, sodass die Reproduzierbarkeit je nach Projekt variiert.

Überprüft Maven PGP-Signaturen standardmäßig?

Nein. Maven Central verlangt von den Verlegern, dass sie zum Zeitpunkt der Veröffentlichung eine Signatur bereitstellen, doch bei der normalen Abhängigkeitsauflösung von Maven werden Prüfsummen und nicht diese Signaturen überprüft. Die Überprüfung der Signaturen erfordert zusätzliche Tools oder Plugins.

Muss ich Nexus oder Artifactory ersetzen, um SecureChain nutzen zu können?

Nein. Der Proxy eines Repository-Managers verweist auf eine konfigurierbare Remote-URL. Durch den Wechsel zu SecureChain ändert sich also lediglich die Zieladresse des Proxys, der Repository-Manager selbst wird jedoch nicht entfernt. Solange Ihr bestehender Repository-Manager weiterhin als Endpunkt für den Build-Prozess dient, können die Entwicklerkonfiguration, die Projektdateien und die bestehenden Gruppen unverändert bleiben.

Was passiert mit Artefakten, die im Upstream nicht reproduzierbar sind?

Ein byte-identischer Vergleich ist nicht mehr möglich, sobald ein Build nichtdeterministische Ergebnisse liefert; daher greift die Verifizierung auf zusätzliche Analysen zurück. Diese Beweislage ist zwar schwächer als eine exakte, reproduzierbare Übereinstimmung, liefert aber dennoch mehr Informationen als eine reine Überprüfung der Binärdatei.

Zusammenfassung

Artikel Name

Eine Alternative zur Sonatype Nexus Firewall, die aus dem Quellcode neu kompiliert wird

Beschreibung

Wie eine Alternative zur Sonatype Nexus Firewall Java-Pakete aus dem Quellcode neu kompiliert und warum ein Scan die Integrität des Quellcodes nicht nachweisen kann.

Autor

Tim Walker

Name des Herausgebers

TuxCare

Logo des Herausgebers