Was ist Dependency Confusion?

Dependency Confusion ist ein Supply-Chain-Angriff, bei dem ein Paketmanager eine öffentliche statt der vorgesehenen internen Abhängigkeit installiert. Kennt ein Angreifer den internen Paketnamen und veröffentlicht im öffentlichen Registry ein gleichnamiges Paket – häufig mit höherer Version –, kann sein Code während Build oder Installation ausgeführt werden.

Vereinfachtes Beispiel

{
  "dependencies": {
    "company-auth-utils": "^2.4.0"
  }
}

# Unsichere Konfiguration: interner und öffentlicher Registry sind Quellen,
# aber der interne Paketname ist öffentlich nicht reserviert.

Wird öffentlich company-auth-utils@99.0.0 veröffentlicht und der Resolver priorisiert die höchste Version, kann das fremde Paket gewinnen. Abhängig vom Ökosystem genügen auch eine falsche Registry-Reihenfolge, Fallbacks oder ein fehlender Scope.

Welche Informationen ermöglichen den Angriff?

• - Paketnamen in öffentlichen JavaScript-Dateien, Fehlermeldungen, Lockfiles oder Dokumentationen.
• - Metadaten aus versehentlich veröffentlichten Artefakten und Container-Images.
• - Buildskripte, Stellenanzeigen oder offene Repositorys mit internen Namespaces.

Sichere Konfiguration und Prozesse

# Beispiel npm: Scope fest an internen Registry binden
@company:registry=https://npm.company.example/repository/npm/
registry=https://registry.npmjs.org/

# Reproduzierbare Installation aus geprüftem Lockfile
npm ci

• - Eindeutige, organisationsgebundene Scopes oder Namespaces verwenden und öffentlich reservieren.
• - Interne Paketnamen explizit an interne Quellen binden; kein stiller öffentlicher Fallback.
• - Lockfiles prüfen, unverändert installieren und Quelle/Integrität des Pakets erfassen.
• - Installationsskripte in isolierten Buildumgebungen mit minimalen Secrets und Netzwerkrechten ausführen.
• - Neue Paketquellen, ungewöhnliche Versionssprünge und Maintainer-Wechsel kontrollieren.

Wie wird sicher getestet?

Organisationen sollten nicht ungefragt echte interne Namen in öffentlichen Registries registrieren: Das kann fremde Namespaces belegen oder produktive Builds beeinflussen. Ein sicherer Test verwendet eine isolierte Test-Registry, erfundene Paketnamen, einen kontrollierten Runner ohne produktive Secrets und einen harmlosen Installationsnachweis. Konfigurations- und Lockfile-Review ist meist aussagekräftiger als ein öffentlicher Proof of Concept.

Nützliche Open-Source-Werkzeuge

Confused sucht in Dependency-Dateien nach Paketen, die möglicherweise nur intern existieren. Ergebnisse sind Kandidaten, kein Beweis für Ausnutzbarkeit. Syft hilft, tatsächlich verbaute Komponenten und Quellen zu inventarisieren; Repository- und Paketmanager- Konfigurationen müssen zusätzlich manuell geprüft werden.