Dependency Confusion und Typosquatting: Praktische Abwehr fuer Dev-Teams

2021 verdiente ein Forscher ueber 130 tausend Dollar Bug Bounty, indem er Pakete mit internen Namen von Apple, Microsoft, PayPal und dutzenden weiteren Firmen auf den oeffentlichen npm- und PyPI-Registries publizierte. Der Angriff brauchte keinen Zero-Day: er nutzte nur die Praezedenz, die Paketmanager der oeffentlichen Registry geben, wenn der Name auf beiden Seiten existiert. Fuenf Jahre spaeter finden Basilisk-Teams diesen Vektor noch in 7 von 10 auditierten Pipelines offen. Dependency Confusion und Typosquatting sind keine akademische Spielerei, sie sind die billige Eingangstuer, um einen kompletten Build zu kompromittieren und damit jeden Kunden, der dieses Artefakt erhaelt.

Der Mechanismus von Dependency Confusion ist simpel und brutal. Du hast ein internes Paket namens acme-payments-sdk auf einem privaten Nexus oder Artifactory. Ein Angreifer findet diesen Namen in einer geleakten package.json, einem Stack-Overflow-Post oder einer oeffentlichen Docker-Schicht und publiziert acme-payments-sdk@99.0.0 auf npmjs.com. Beim naechsten npm install ohne strikten Lockfile waehlt der Resolver die hoehere Version. Fertig, beliebiger Code laeuft in deinem CI mit AWS-Credentials, GitHub-Tokens und Zugriff auf die interne Registry. Wir haben das im Feld bei Assessments wie Pentest von REST und GraphQL APIs: Technische Checkliste fur legales Bug Bounty gesehen, wo die Build-Oberflaeche angreifbarer war als die API selbst.

Typosquatting spielt in einer anderen Liga. Statt den echten Namen zu uebernehmen, registriert der Angreifer colorss, requets, python-dateutill, lodahs. Phylum-Research katalogisierte 2024 ueber 11 tausend boesartige Pakete auf PyPI mit diesem Muster innerhalb von zwoelf Monaten. Die Payloads variieren: Diebstahl von Umgebungsvariablen, Mining, RAT-Installation, DNS-Exfiltration. Die erste Verteidigung ist kulturell: verpflichtendes Code-Review fuer jede Aenderung an Dependencies. Tools wie Socket, Snyk Advisor und deps.dev markieren bereits frisch veroeffentlichte Pakete, Pakete ohne Maintainer-Historie oder mit verdaechtigen Install-Script-Mustern.

Lockfiles loesen 80 Prozent des Problems, wenn man sie ernsthaft nutzt. package-lock.json, yarn.lock, pnpm-lock.yaml, poetry.lock, Cargo.lock und go.sum fixieren nicht nur die Version sondern den Hash. Konfiguriere npm ci, pnpm install --frozen-lockfile, pip install --require-hashes und cargo --locked in Pipelines. Kein loses npm install in Produktion. Kombiniert mit einer .npmrc die registry=https://nexus.intern/repository/npm-group/ und always-auth=true setzt, reduzierst du drastisch die Chance, dass der Resolver versehentlich zur oeffentlichen Registry abwandert. Das Denkmuster spiegelt das, was wir in Supply Chain Security: Sigstore-Signatur und echte SBOMs in CI/CD ueber SBOMs und Attestations behandeln.

Scoping ist die ultimative Waffe gegen Dependency Confusion im JavaScript-Oekosystem. Migriere alle internen Pakete zu @acme/payments-sdk, @acme/auth, @acme/billing. In .npmrc setze @acme:registry=https://nexus.intern/. Jetzt loest npm diesen Scope nur auf der internen Registry auf, selbst wenn jemand @acme/payments-sdk auf npmjs publiziert (Microsoft reserviert gaengige Scopes seit 2021). In Python nutze explizit getrennte Indizes mit pip --index-url fuer interne und --extra-index-url nur wenn noetig, oder besser, mirrore alles via devpi oder Artifactory. Fuer Go blockiert GOPRIVATE=git.acme.com Anfragen an proxy.golang.org. Dieses Hardening passt direkt zu Linux-Server-Hardening: CIS Benchmark Anwenden Ohne die Produktion zu Zerlegen und dem Least-Privilege-Prinzip.

Auf CI-Seite isoliere. Jeder Build-Job sollte mit ephemeren Tokens laufen, ohne Produktionszugriff, mit Netzwerk-Egress gefiltert durch einen Proxy, der nur interne Registry, github.com und bekannte Endpoints zulaesst. OIDC mit kurzlebigen Credentials in GitHub Actions oder GitLab CI eliminiert langlebige Secrets. Fuege einen Pre-Install-Verifikationsschritt hinzu: scripts/check-deps.sh fuehrt npm audit signatures aus, validiert dass keine Dependency in den letzten 7 Tagen ohne manuelle Freigabe publiziert wurde, und prueft Pakete gegen eine Allowlist. Das Datadog-Team veroeffentlichte 2025 einen Bericht, der zeigte dass 62 Prozent der Supply-Chain-Kompromittierungen mit diesen drei Regeln kombiniert blockiert worden waeren.

Kontinuierliches Monitoring schliesst den Kreis. Konfiguriere Sigstore-Rekor-Alarme fuer jede Veroeffentlichung mit deinem Organisationsnamen, registriere Typo-Squatting-Domains deines Produkts (acme-cloud, acme-coud, acmecloud), und pflege ein Inventar cosign-signierter SBOMs fuer jeden Release. Taucht ein verdaechtiges Paket auf, hast du bereits Evidenz fuer den Takedown und Daten fuer Incident Response, im Stil wie in DFIR unter Linux: Live-Triage mit UAC und Velociraptor. Trainiere das Team, jede neue Install-Script-Warnung zu melden statt sie reflexhaft zu ignorieren. Praktischer Takeaway: heute noch, auditiere deine .npmrc, .pip.conf und go env. Wenn du nicht in 30 Sekunden beantworten kannst, aus welcher Registry jede Dependency stammt, bist du bereits verwundbar.