Ein Unternehmen nutzt in seinem internen Paketverzeichnis (private Registry) die nur intern verwendete Bibliothek acme-utils. Ein Angreifer hat im öffentlichen Paketverzeichnis ein Paket mit demselben Namen acme-utils und einer höheren Versionsnummer registriert; dabei stellte sich heraus, dass die interne Build-Umgebung je nach Build-Konfiguration das Paket des Angreifers übernimmt. Welche Maßnahme gegen diese „Dependency Confusion“ ist am besten geeignet?

Antwort: B. Interne Pakete in einem von der Organisation verwalteten Namensraum ablegen, sie so konfigurieren, dass sie nur aus dem internen Verzeichnis bezogen werden, und Versionen und Hashwerte in einer Lockfile festschreiben

Dependency Confusion ist eine Form des Software-Lieferkettenangriffs. Manche Paketverwaltungswerkzeuge sind so konfiguriert, dass sie mehrere Verzeichnisse abfragen und bei gleichem Namen das Paket mit der höheren Versionsnummer wählen; Angreifer nutzen das aus, um ein schädliches Paket mit demselben Namen wie ein internes einschleusen zu lassen. Abhilfe schafft, für interne Pakete einen von der Organisation verwalteten Namensraum (Scope) zu verwenden, diesen Namensraum nur an das interne Verzeichnis zu binden und ausdrücklich festzulegen, aus welchem Verzeichnis bezogen wird. Werden zusätzlich Versionen und Hashwerte der Abhängigkeiten in einer Lockfile festgeschrieben, lässt sich verhindern, dass sie unbemerkt durch etwas anderes ersetzt werden. Auch den Namensraum der Organisation vorab im öffentlichen Verzeichnis zu registrieren, hilft gegen Nachahmung.