Dein Blog zum Thema digitales Business

Zehn Zeilen, ein ganzer Wald

Du schreibst eine package.json mit fünf, sechs Einträgen. Ein Web-Framework, ein HTTP-Client, ein Testrunner, vielleicht ein Linter. Überschaubar, dachtest du. Dann führst du npm install aus, und der node_modules Ordner füllt sich mit tausenden Dateien. Das Gleiche passiert bei einer requirements.txt mit einer Handvoll Paketen und pip install. Was du direkt ausgewählt hast, sind nur die Wurzeln. Was tatsächlich in deinem Projekt landet, ist ein Baum mit vielen Ebenen darunter, den du nie einzeln angeschaut hast.

Warum aus fünf Paketen hunderte werden

Jedes Paket, das du einbindest, hat selbst wieder Abhängigkeiten. Diese Abhängigkeiten haben wiederum eigene Abhängigkeiten. Man nennt das transitive Dependencies: Pakete, die du nie direkt in deiner Manifestdatei genannt hast, die aber trotzdem in deinem Projekt liegen und mitlaufen. Ein einzelnes populäres Utility-Paket kann leicht ein Dutzend weiterer Pakete mitziehen, und jedes davon zieht wieder eigene mit. Die Tiefe multipliziert sich schneller, als die Anzahl der Einträge in deiner Manifestdatei vermuten lässt.

Das Problem dabei ist nicht die Zahl an sich. Das Problem ist, dass niemand in deinem Team eine bewusste Entscheidung für die meisten dieser Pakete getroffen hat. Du hast entschieden, ein Framework zu nutzen. Wer entschieden hat, welche zehn kleinen Hilfspakete das Framework selbst benötigt, war jemand anderes, zu einem anderen Zeitpunkt, mit anderen Prioritäten.

Wie du dir tatsächlich einen Überblick verschaffst

Die gute Nachricht: Der komplette Baum steht bereits in deinem Projekt, du musst ihn nur lesen. Die package-lock.json bei npm oder ein per pip freeze erzeugtes Abbild bei Python listen jedes einzelne installierte Paket auf, inklusive exakter Version und, je nach Format, inklusive der Information, welches Paket welches andere nach sich gezogen hat. Das Lockfile ist kein Nebenprodukt, das man ignorieren kann. Es ist die einzige vollständige, verbindliche Liste dessen, was in deinem Build tatsächlich landet.

Für den schnellen Blick ins Detail hilft die Kommandozeile. npm ls zeigt dir den Abhängigkeitsbaum deines Projekts direkt im Terminal, npm ls --all auch die tiefsten Ebenen. Willst du wissen, warum ein bestimmtes Paket überhaupt installiert ist, zeigt dir npm ls <paketname>, wer es referenziert. Bei Python liefert pip show <paketname> die direkten Requires- und Required-by-Angaben eines Pakets, und pipdeptree stellt den gesamten Baum als Text dar, inklusive Konflikten zwischen Versionen, die verschiedene Pakete verlangen.

Wichtig ist der Unterschied zwischen den beiden Perspektiven. Deine Manifestdatei zeigt dir, was du gewählt hast. Das Lockfile und die Baum-Tools zeigen dir, was tatsächlich läuft. Nur die zweite Perspektive ist relevant, wenn du wissen willst, was in Produktion tatsächlich Code ausführt.

Warum das eine Lieferkettenfrage ist

Jedes Paket in diesem Baum, egal auf welcher Ebene, führt Code in deinem Prozess aus. Ein transitives Paket, das du nie bewusst ausgewählt hast, hat denselben Zugriff wie eines, das du sorgfältig geprüft hast: auf Dateisystem, Netzwerk, Umgebungsvariablen, je nach Laufzeitumgebung. Ein Angriff muss nicht dein Hauptframework treffen. Es reicht, wenn eine kleine Hilfsbibliothek drei Ebenen tiefer kompromittiert wird, die dein Framework für eine Nebensächlichkeit einbindet.

Genau deshalb lohnt sich der Blick in den Baum, bevor überhaupt die Frage nach einem Inventar der eigenen Software-Bestandteile aufkommt. Ein Inventar ist nur so gut wie das Verständnis dessen, was es abbildet. Wenn du nicht weißt, warum ein Paket in deinem Baum steht und wer es dorthin gezogen hat, hilft dir auch die schönste Liste nicht weiter. Die Übung, npm ls oder pipdeptree einmal komplett durchzugehen, für ein Projekt, das du gut kennst, verändert den Blick auf jede weitere Diskussion über Abhängigkeiten in deiner Lieferkette.

Solche Fragen tauchen in drei Feldern immer wieder auf: bei der Implementation selbst, bei der AI Governance, wenn KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen, und bei der Maintenance, wenn nach dem Go-Live nicht mehr klar ist, wem ein System eigentlich gehört. Ein festes Angebot daraus entsteht erst, wenn klar ist, was der Kunde wirklich braucht. Fragen dazu gehen an mm@mhm-dl.de.