Dein Blog zum Thema digitales Business

Die meisten Software-Teams kennen ihre Abhängigkeiten aus öffentlichen Registries: npm, PyPI, Maven Central. Was dabei oft übersehen wird, sind die eigenen internen Pakete, die unter einem hauseigenen Namen laufen. Genau dort sitzt eine Lücke, die 2021 reihenweise Konzerne wie Apple, Microsoft und PayPal getroffen hat. Sie heißt Dependency Confusion und ist bis heute in vielen Pipelines offen.

Was Dependency Confusion ist

Viele Firmen bauen Software mit internen Paketen, etwa einer Bibliothek namens firma-auth oder firma-utils. Diese Pakete liegen in einer privaten Registry und werden nie veröffentlicht. Der Sicherheitsforscher Alex Birsan zeigte 2021, dass man genau diese Namen kennen muss, um anzugreifen. Er lud öffentliche Pakete mit identischen Namen hoch, gab ihnen eine höhere Versionsnummer und wartete. In über 35 Unternehmen zog der Build automatisch das öffentliche Paket und führte fremden Code auf internen Servern aus.

Warum der Angriff funktioniert

Der Kern des Problems liegt darin, wie Paketmanager Versionen auflösen. Fragt der Build nach firma-utils und findet diesen Namen sowohl in der internen als auch in der öffentlichen Registry, gewinnt in der Standardkonfiguration meist die höhere Versionsnummer. Der Angreifer muss also nur den Namen erraten und Version 99.0.0 veröffentlichen. Kein Login, kein Zugang zum internen Netz, keine Lücke im Code selbst. Es reicht, dass der interne Name öffentlich nicht reserviert ist und die Build-Konfiguration beide Quellen gleichberechtigt durchsucht.

Woran du erkennst, ob du betroffen bist

Drei Fragen reichen für eine erste Einschätzung. Erstens: Tragen eure internen Pakete einfache Namen ohne Namespace, also firma-utils statt @firma/utils? Zweitens: Ist diese Build-Konfiguration so eingestellt, dass sie interne Pakete auch in der öffentlichen Registry sucht, falls sie intern nicht gefunden werden? Drittens: Sind eure internen Namen in npm oder PyPI als Platzhalter reserviert, oder stehen sie dort offen? Wer bei zwei der drei Fragen unsicher ist, sollte den Build genauer ansehen.

Was wirklich schützt

Der wirksamste Schutz ist eine klare Trennung der Quellen. Konfiguriert den Paketmanager so, dass interne Namen ausschließlich aus der internen Registry kommen dürfen. In npm geht das über scoped Packages mit einer festen Registry-Zuordnung pro Scope, in pip über einen expliziten Index statt eines zusätzlichen Extra-Index. Reserviert eure internen Namen zusätzlich als leere Platzhalter in der öffentlichen Registry, damit niemand sie besetzen kann. Lockfiles mit Integritäts-Hashes sorgen dafür, dass nicht plötzlich ein fremdes Artefakt durchrutscht. Diese Maßnahmen kosten wenig und schließen die Lücke fast vollständig.

Der nüchterne Blick

Dependency Confusion ist kein exotischer Spezialfall. Der Angriff ist billig, automatisierbar und trifft genau die Pakete, die im Sicherheitskonzept oft fehlen, weil sie als intern und damit als sicher gelten. Wer einmal nachschaut, wie der eigene Build interne Namen auflöst, hat den größten Teil des Risikos schon verstanden.

Der GitSecOps QuickCheck prüft genau solche Schwachstellen in deiner Pipeline: Wie werden Abhängigkeiten aufgelöst, wo liegen Secrets, welche Schritte sind ungeschützt. Ergebnis in 3 Werktagen, 1.990 € netto, konkrete Befunde statt Folienware. Anfrage an mm@crank.zone.