Ein einziger Fehler in der Datei „settings.xml“ kann Ihren gesamten Maven-Build der „Dependency Confusion“ aussetzen

Wichtigste Erkenntnisse

• Bei festen Versionen durchsucht Maven die Repositorys der Reihe nach und übernimmt die Koordinaten aus dem ersten Repository, in dem diese vorhanden sind.
• Die eigene POM einer Abhängigkeit kann Repositorys zu Ihrem Build hinzufügen, und standardmäßig gibt es nichts, was dies verhindert.
• A mirrorOf Diese Zeile sperrt die Maven-Seite ab, aber Ihr Repository-Manager muss weiterhin dafür sorgen, dass öffentliche Repositories aus Ihrem Namensraum ferngehalten werden.

Viele Java-Entwicklungsabteilungen in Unternehmen verfügen über eine settings.xml Niemand hat sie seit Jahren angerührt. Sie funktioniert. Die Builds laufen, CI ist grün, niemand öffnet sie. Sie verdient es trotzdem, einmal unter die Lupe genommen zu werden. Diese Datei legt fest, woher jedes Artefakt stammt, und was darin festgehalten ist, ist oft großzügiger, als dem Team bewusst ist. Ein Build kann nur eine falsch platzierte Repository-Angabe davon entfernt sein, eine interne Koordinate außerhalb des öffentlichen Internets aufzulösen. Diese Lücke ist die Verwirrung bei den Maven-Abhängigkeiten, und sie funktioniert anders als bei npm und pip. Bei festen Versionen vergleicht Maven keine Versionsnummern. Es vergleicht, welches Repository dein Build zuerst abfragt.

Warum die Maven-Abhängigkeitsverwechslung anders funktioniert als bei npm und pip

pip kann über folgende Anweisung gleichzeitig auf mehrere Indizes verweisen: --index-url und --extra-index-url, und wählt dann aus allen die höchste Version aus, die die Anforderung erfüllt. Veröffentlichen internal-utils 99.0.0 ist öffentlich verfügbar und hat Vorrang vor einem intern gespeicherten Paket mit demselben Namen. npm verhält sich anders. Ein Paket wird aus einer einzigen Registry aufgelöst, je nachdem, welche für seinen Geltungsbereich konfiguriert ist, oder aus der öffentlichen, falls keine Geltungsbereichszuordnung vorliegt. Der npm-Angriff funktioniert, weil das interne Paket nie einem privaten Registry-Geltungsbereich zugeordnet wurde, sodass der Client nur mit der öffentlichen Registry kommuniziert – und nicht, weil npm die Versionen aggregiert und die höchste auswählt. Maven funktioniert bei einer festen Version nicht auf diese Weise. Es löst die Version aus der Abhängigkeitsdiagramm zuerst, dann sucht nach genau diesem groupId:artifactId:version, die GAV-Koordinate. Die Veröffentlichung einer höheren Version an sich bewirkt nichts, da niemand danach fragt. Es werden die Repositorys in der effektiven Repository-Reihenfolge, zuerst die Einstellungen, dann die POM-Hierarchie des Projekts, anschließend die Abhängigkeits-POMs, wobei die erste ausgewählt wird, die das Artefakt enthält.

Der Fall mit der festen Version ist der häufigste, und genau dieser bestimmt, wie Sie vorgehen müssen. Die Reihenfolge ist entscheidend, der exakte Abgleich der Koordinaten ist entscheidend, eine Versionsinflation spielt keine Rolle. Wenn ein öffentliches Repository vor Ihrem internen Repository existiert und Ihre Koordinaten dort vorhanden sind, erhalten Sie die öffentliche Kopie. Maven Central erschwert die grobe Umsetzung dieses Prinzips. Die Veröffentlichung unter einem Namespace bedeutet, dass Sie die Kontrolle über die entsprechende Domain mittels eines DNS-TXT-Eintrags oder über das entsprechende Konto für io.github Stil-Namespaces, damit niemand behauptet, com.yourcompany nur weil du es nie registriert hast. Die eigentliche Gefahr liegt woanders: in Namespaces, die du nicht kontrollierst, in Namespaces, deren zugehörige Domain stillschweigend abgelaufen ist und von anderen übernommen wurde, in Repositories mit weniger strengen Veröffentlichungsregeln als bei Central und in jedem Repository, das ein POM in deinem Verzeichnisbaum deklariert. JitPack erstellt unterstützte Git-Projekte auf Abruf, und ein Abhängigkeits-POM kann es ohne eigene Deklaration in deine Repository-Sammlung einfügen. Seine Koordinaten richten sich nach dem Git-Host und dem Konto, es handelt sich also nicht um ein offenes Feld, aber es ist ein Repository, dem du nie dein Vertrauen geschenkt hast. Versionsbereiche und SNAPSHOTs sind die Bereiche, in denen die Versionsaggregation tatsächlich greift. Bereiche ermöglichen Maven-Zusammenführungen maven-metadata.xml über verschiedene Repositorys hinweg und wählt den höchsten Wert aus, wodurch das versionsbasierte Hijacking wieder ins Spiel kommt. SNAPSHOTs bergen ein damit verbundenes Risiko, da die Metadaten die Basisversion einem zeitgestempelten Build zuordnen und jedes Repository in der Gruppe diese Zuordnung ändern kann. Vorsicht: Bereiche sehen nach Flexibilität aus und verhalten sich wie eine nicht festgelegte Abhängigkeit mit repositoryübergreifender Reichweite. Legen Sie genaue Versionen fest und überlassen Sie es einem Repository-Manager, Upgrades zu genehmigen.

Was Ihre „settings.xml“-Datei Maven tatsächlich mitteilt

Ein paar Blocks weiter settings.xml die Beschlussfassung oder deren Legitimation beeinträchtigen. <mirrors> leitet Anfragen weiter, <profiles> kann Repositorys hinzufügen, <activeProfiles> entscheidet, welche davon gelten, und <servers> sorgt für die Authentifizierung. Der entscheidende Punkt ist <mirrors>, denn ein Spiegel mit dem passenden Muster überschreibt jede Repository-Deklaration an allen anderen Stellen. Das ist der Maven-bezogene Teil der Lösung. Dem Repository-Manager muss noch mitgeteilt werden, dass er Ihren internen Namespace nicht aus öffentlichen Repositories bereitstellen soll – darum geht es im nächsten Abschnitt.

<mirrors>
  <mirror>
    <id>internal-repo</id>
    <name>Internal Repository Manager</name>
    <url>https://nexus.example.com/repository/maven-public/</url>
    <mirrorOf>*</mirrorOf>
  </mirror>
</mirrors>

<mirrorOf>*</mirrorOf> Das bedeutet, dass jede Repository-Anfrage an diese URL gesendet wird, unabhängig davon, was in einer POM-Datei angegeben ist. Genau das ist beabsichtigt. Hier ist jedoch, was in vielen Dateien stattdessen steht.

Nur Spiegelung central Das ist ein Fehler, der leicht unterläuft, weil es sich richtig anfühlt. Es deckt das Repository ab, an das jeder denkt – und lässt jedes in einer POM deklarierte Repository auf seine eigene URL verweisen. Finden Sie heraus, welche Variante bei Ihnen zutrifft.

mvn help:effective-settings

Dadurch werden globale und Benutzereinstellungen zusammengeführt und angezeigt, was Maven tatsächlich verwendet – einschließlich der Profilaktivierung. Führen Sie den Befehl sowohl auf einem CI-Agenten als auch auf einem Laptop aus, da es hier zu Abweichungen kommen kann.

Die transitive Repository-Injektion, die niemand konfiguriert hat

Das ist es, was einem zum Verhängnis wird Java-Entwickler die sich nicht auf die Suche begeben haben. Eine Abhängigkeit an sich POM kann Repositories deklarieren, und Maven berücksichtigt diese. Wenn Sie eine Bibliothek hinzufügen, kann dadurch ein Repository zu Ihrer Lösungsgruppe hinzugefügt werden. Dies ist ein dokumentiertes Verhalten, das schon seit Jahren besteht, und es gibt keine Standardeinstellung, die dies verhindert. Daher kann es vorkommen, dass Ihr Build Repositorys abfragt, von denen Sie noch nie gehört haben und die von einer transitive Abhängigkeit vier Ebenen tief, unter einer URL, die noch niemand überprüft hat.

mvn help:effective-pom | grep -A 8 '<repository>'

Darin wird die Liste angezeigt, die Ihre eigene POM-Hierarchie erzeugt, einschließlich übergeordneter Elemente und Profile. Was dabei fehlt, sind alle Elemente, die von einer Abhängigkeits-POM beigesteuert werden, da diese Repositorys erst zum Zeitpunkt der Auflösung zur Menge hinzugefügt werden und nicht in Ihre POM integriert werden. Um sich ein vollständiges Bild zu machen, sollten Sie sich einen echten Build ansehen.

mvn -X dependency:resolve 2>&1 | grep -E 'Using mirror|Repositories \(' | sort -u

Die Zeilen unter „Repositories“ geben die von Maven für Abhängigkeiten und Plugins verwendeten Repositories an, und die Zeilen unter „Using mirror“ zeigen an, welche Deklarationen umgeleitet wurden. Durch die Ausführung dieses Befehls können Repositories auftauchen, die niemand bewusst hinzugefügt hat. Realitätscheck: Dass Maven die von Ihren Abhängigkeiten deklarierten Repositorys berücksichtigt, stellt keine Sicherheitslücke dar und wird auch nicht verschwinden. Diese Vorgehensweise gab es bereits, bevor überhaupt jemand über Angriffe auf die Lieferkette nachdachte, und <mirrorOf>*</mirrorOf> Dies ist die standardmäßige Methode auf Einstellungsebene, um zu verhindern, dass diese Deklarationen ihre ursprünglichen URLs erreichen. Noch eine kleine Schwierigkeit. <pluginRepositories> ist ein separater Block von <repositories>, und ein Spiegel mit * deckt beides ab, während repositoryspezifische Mirrors dies in der Regel nicht tun. Plugins laufen mit vollem JVM-Zugriff, wodurch sie über höhere Berechtigungen verfügen als alle anderen Elemente in Ihrem Laufzeit-Classpath.

Überprüfen, was Ihr Build bereits zwischengespeichert hat

Der Cache ist weniger simpel, als sein Ruf vermuten lässt. Maven speichert Artefakte in ~/.m2/repository, und der erweiterte lokale Repository-Manager von Maven Resolver protokolliert, aus welchem Remote-Repository der jeweilige Download stammt. Wird dieses Artefakt in einem späteren Build angefordert, bei dem das ursprüngliche Repository nicht im Geltungsbereich liegt, behandelt Resolver die zwischengespeicherte Kopie als nicht vorhanden und führt eine erneute Auflösung über die Repositorys durch, die derzeit im Geltungsbereich liegen. Diese Nachverfolgung dient der Kontrolle und als Nachweis. Maven schreibt diese Herkunftsdaten neben jedes Artefakt.

find ~/.m2/repository -name '_remote.repositories' \
  -exec grep -L 'internal-repo' {} +

Darin sind Tracking-Dateien aufgeführt, die keinen Verweis auf die ID Ihres Mirrors enthalten. Betrachten Sie dies eher als grobe Vorauswahl denn als Provenienzangabe pro Artefakt, da eine Datei mehrere Artefakte umfassen kann und lokale Installationen einen leeren Ursprung verzeichnen. Eine unbekannte ID bedeutet, dass sie unter einer anderen Repository-Konfiguration aufgelöst wurde – es lohnt sich, dem nachzugehen. Prüfen Sie bei Ihren wichtigsten Koordinaten, ob diese öffentlich verfügbar sind.

curl -s -o /dev/null -w "%{http_code}\n" \
  https://repo.maven.apache.org/maven2/com/yourcompany/billing-core/

Ein Wert von 200 bedeutet, dass Central Inhalte unter diesem „groupId“- und „artifactId“-Pfad enthält. Wenn Sie erwartet haben, dass diese Inhalte privat sind, sollten Sie herausfinden, was sich dort befindet und wer den verifizierten Namespace-Anspruch hält. Profi-Tipp: Planen Sie solche Überprüfungen für Ihre wichtigen internen Koordinaten ein und richten Sie sie auf die anderen öffentlichen Repositorys aus, auf die Ihre Builds zugreifen können und in denen die Namespace-Regeln lockerer sind. Unerwartete Veröffentlichungen unter Koordinaten, auf die Sie sich verlassen, sollten Sie als Erstes aufspüren.

Eigene Koordinaten im Repository-Manager sperren

Behebung settings.xml leitet jede Anfrage über eine URL weiter, ohne jedoch zu bestimmen, was diese URL anschließend tut. Ein Administrator, der eine Gruppe verwaltet, die sowohl ein intern gehostetes Repository als auch einen Central-Proxy umfasst, muss sich dennoch entscheiden. Dabei spielen zwei Konfigurationen eine Rolle. Die erste betrifft die Reihenfolge. Im Nexus Repository werden die Gruppenmitglieder der Reihe nach durchsucht, und die erste Übereinstimmung hat Vorrang, sodass intern gehostete Repositorys vor dem Central-Proxy stehen. Artifactory löst virtuelle Repositorys ebenfalls der Reihe nach auf. „Internal-first“ bedeutet, dass Ihre Koordinaten intern aufgelöst werden, selbst wenn dieselben öffentlich vorhanden sind. Der zweite Punkt ist eine vollständige Sperrung Ihrer eigenen Koordinatenmuster am Central-Proxy. Nexus Repository tut dies mit Routing-Regeln, Artifactory mit Ausschlussmustern im Remote-Repository oder besser noch im virtuellen Repository, das dieses aggregiert. In jedem Fall wird eine Anfrage für com/yourcompany/** gelangt niemals ins öffentliche Internet. Diese zweite Kontrollinstanz schützt vor Fehlern. Die Reihenfolge hängt davon ab, dass die Konfiguration korrekt bleibt – ein expliziter Block in Ihrem Namensraum wird geschlossen.

Die Ausschlussregel und die Ausgangsbeschränkung sorgen dafür, dass Richtlinien in die Praxis umgesetzt werden. Es kommt zu Konfigurationsabweichungen, Basis-Images werden von einem anderen Team übernommen, und es gibt immer jemanden, der ein Repository hinzufügt, um eine Veröffentlichung am Freitag zu ermöglichen. Für den Artefaktverkehr sollte der ausgehende Datenverkehr von Build-Agenten standardmäßig blockiert und der zugelassene Repository-Manager auf die Zulassungsliste gesetzt werden, wodurch verhindert wird, dass Maven auf beliebige öffentliche Repositories zugreift. Das Blockieren eines einzelnen Central-Hostnamens reicht nicht aus, da Maven über mehr als einen Namen auf Central zugreift und Abhängigkeits-POMs völlig andere Hosts einführen können. Routing und Blockierung entscheiden darüber, woher Artefakte stammen. Keines von beiden prüft, ob das Artefakt sicher ist. Ein JAR ist eine Build-Ausgabe, und nichts schreibt vor, dass es mit dem Quell-Repository übereinstimmen muss, auf das das Projekt verweist. Das Scannen schließt diese Lücke nicht, da Scanner nur prüfen, was bereits vorliegt. Das Neubaue von Paketen aus verifizierter Quelle in einer kontrollierten Umgebung bietet Ihnen eine unabhängige Herkunftsnachweisbarkeit anstelle des Vertrauens in eine undurchsichtige Binärdatei, und wenn der Upstream-Build reproduzierbar ist, können Sie die Ergebnisse direkt vergleichen.

Gradle bietet hierfür bessere Grundfunktionen

Gradle handhabt die Repository-Einschränkung besser als Maven; nutzen Sie daher die nativen Funktionen von Gradle, anstatt Gewohnheiten aus Maven zu übernehmen. Durch die Inhaltsfilterung wird eingeschränkt, welche Koordinaten ein Repository bereitstellen darf. Fügen Sie diese Konfiguration in dependencyResolutionManagement in settings.gradle.kts, wobei derselbe Block auch Unterprojekte daran hindern kann, eigene zu deklarieren.

// settings.gradle.kts
dependencyResolutionManagement {
  repositoriesMode = RepositoriesMode.FAIL_ON_PROJECT_REPOS
  repositories {
    exclusiveContent {
      forRepository {
        maven { url = uri("https://nexus.example.com/repository/internal/") }
      }
      filter { includeGroupByRegex("com\\.yourcompany(\\..*)?") }
    }
    maven { url = uri("https://nexus.example.com/repository/maven-public/") }
  }
}

exclusiveContent bedeutet, dass Ihr Namensraum ausschließlich aus dem internen Repository aufgelöst wird, ohne dass weitere Quellen herangezogen werden. Das heißt Abhängigkeitsverwirrung durch die Konstruktion geschlossen, nicht durch die Reihenfolge. Beachten Sie die Verankerung in diesem regulären Ausdruck, da ein bloßes com\.yourcompany.* passt wunderbar dazu com.yourcompanyevil, genau den Beinaheunfall, für dessen Erfassung es geschaffen wurde. FAIL_ON_PROJECT_REPOS dann bricht der Build ab, wenn ein Unterprojekt eine eigene Erklärung enthält, wodurch die Entscheidung in einer einzigen Datei gebündelt wird. Maven verfügt zwar über kein einzeiliges Äquivalent, ist aber dennoch nicht hilflos. Das Enforcer-Plugin bietet bannedRepositories Die Regel überprüft die Repositorys der Build-Sitzung und kann als Whitelist ausgeführt werden. Insider-Tipp: Kombinieren exclusiveContent mit Gradle Überprüfung der Abhängigkeiten. Die Filterung legt fest, welches Repository eine Koordinate bereitstellen darf, und die Metadaten zur Verifizierung vergleichen Artefakte mit den erwarteten Prüfsummen sowie – sofern aktiviert – mit vertrauenswürdigen Signaturen. Zusammen decken sie das Routing und die Integrität ab, was keine einzelne Maven-Konfiguration leisten kann. Sich ändernde Abhängigkeiten wie SNAPSHOTs fallen nicht darunter – ein weiterer Grund für das Fixieren.

Die Datei „settings.xml“ von Gap lässt sich nicht schließen

All das beseitigt die Verwirrung um Maven-Abhängigkeiten auf der Routing-Ebene: die richtige mirrorOf Wert, Gruppierung, Ausschlussregeln, Ausgangskontrollen. Nichts davon beantwortet die nächste Frage, nämlich ob das Artefakt sicher ist, sobald es vom richtigen Ort eintrifft. Genau darum geht es SecureChain dafür entwickelt wurde. Es ersetzt die öffentliche Maven-Central-Auflösung durch eine verifizierte, aus dem Quellcode neu erstellte Alternative, bei der jede Komponente während der Abhängigkeitsauflösung überprüft wird, anstatt Artefakte erst nach ihrer Veröffentlichung zu scannen. Neue CVEs werden kontinuierlich behoben, und der Schutz endet nicht mit dem Ende des Lebenszyklus. Erfahren Sie mehr darüber, was SecureChain für Java Umschläge oder Eine Demo anfordern gegen deinen eigenen Build.

FAQ

Was ist eine Maven-Abhängigkeitsverwirrung?

Es handelt sich um einen Angriff, bei dem ein Build eine interne Koordinate aus einem öffentlichen Repository anstelle der internen auflöst. Bei festen Versionen resultiert die Sicherheitslücke aus der tatsächlichen Reihenfolge der Repositories – zuerst die Einstellungen, dann die POM-Hierarchie und schließlich die Abhängigkeits-POMs – und nicht aus einer Versionsinflation.

Wählt Maven die höchste Version aus allen Repositorys aus?

Gilt nicht für feste Versionen. Maven ermittelt die Version anhand des Abhängigkeitsgraphen und sucht dann genau diese Koordinate im ersten Repository, das sie enthält. Versionsbereiche und SNAPSHOTs werden repo-übergreifend abgeglichen, weshalb exakte Versionen sicherer sind.

Auf welchen Wert sollte „mirrorOf“ gesetzt werden?

Stelle es auf *, wodurch jede Repository-Anfrage über Ihren Repository-Manager geleitet wird, unabhängig davon, was in einer POM-Datei festgelegt ist. Wenn Sie diese Option auf central Es fängt nur Maven Central ab und lässt die in Projekt- oder Abhängigkeits-POMs deklarierten Repositories direkt aufgelöst werden.

Kann eine Abhängigkeit ein Repository zu meinem Build hinzufügen?

Ja. Maven berücksichtigt die in der POM einer Abhängigkeit angegebenen Repositorys, sodass eine transitive Abhängigkeit ein Repository zu Ihrer Auflösung hinzufügen kann. Ein Mirror, der auf * verhindert, dass Maven sie unter ihren ursprünglichen URLs kontaktiert.

Wie kann ich überprüfen, welche Repositories mein Maven-Build verwendet?

ausführen. mvn help:effective-settings für zusammengeführte Einstellungen und die Profilaktivierung, mvn help:effective-pom für die Liste, die Ihre POM-Hierarchie erzeugt, und mvn -X dependency:resolve um das Set zu sehen, das bei einem echten Bauvorhaben verwendet wurde.

Ist die Verschlüsselung von Passwörtern in der Datei „settings.xml“ sicher?

Nicht gegen jeden, der das Dateisystem lesen kann. Das Erbe von Maven 3 Passwortverschlüsselung speichert ein Hauptpasswort auf der Festplatte, das von jedem wiederhergestellt werden kann, der über die Sicherheitskonfigurationsdatei verfügt. Maven 4 fügt einen austauschbaren Dispatcher hinzu, der den Hauptschlüssel stattdessen aus einer Umgebungsvariable oder einem GPG-Agenten beziehen kann, wobei jedoch weiterhin jeder, der diesen Schlüssel besitzt, jeden Wert in settings.xml. In jedem Fall sollten die Anmeldedaten aus einem echten Geheimnisspeicher in CI eingefügt werden.