Dependency-Manifest

Fast kein Programm wird komplett von Grund auf geschrieben. Entwicklerinnen und Entwickler bauen fertige Bausteine anderer Leute ein, etwa eine Sammlung von Rechenfunktionen oder ein Werkzeug zum Zeichnen von Diagrammen. Solche fremden Bausteine nennt man Abhängigkeiten, weil das eigene Programm ohne sie nicht läuft. Damit niemand von Hand nachhalten muss, welche davon gebraucht werden, gibt es eine eigene Datei dafür: das Dependency-Manifest. Darin steht Zeile für Zeile, welcher Baustein in welcher Version nötig ist. Ein Hilfsprogramm liest diese Liste und lädt alles Genannte automatisch aus dem Internet nach.

Warum eine Liste über Sicherheit entscheidet

Ein mittelgroßes Projekt hat schnell mehrere hundert Abhängigkeiten. Denn jeder eingebundene Baustein bringt oft selbst wieder eigene mit. Ohne Manifest wüsste niemand mehr, was eigentlich alles im fertigen Programm steckt. Genau diese Übersicht ist die Grundlage für alles Weitere.

Wird in einem verbreiteten Baustein eine Sicherheitslücke gefunden, muss jedes Unternehmen sofort wissen, ob es betroffen ist. Beim Fall der Java-Bibliothek Log4j Ende 2021 suchten Firmen weltweit tagelang danach. Wer gepflegte Manifeste hatte, konnte die Frage in Minuten beantworten. Andere brauchten Wochen.

Deshalb verlangen Behörden und Großkunden inzwischen häufig eine sogenannte Software Bill of Materials, kurz SBOM. Das ist eine Art Zutatenliste für Software, die aus den Manifesten erzeugt wird. Auch KI-Projekte sind betroffen, denn sie hängen an vielen Bibliotheken für Mathematik und Grafikkarten-Rechnung.

Was in der Datei steht und wer sie liest

Jede Programmiersprache hat ihr eigenes Format. In der Sprache JavaScript heißt die Datei package.json, bei Python meist requirements.txt oder pyproject.toml. Der Inhalt ist aber überall ähnlich: ein Name und eine Versionsangabe pro Zeile. Eine Angabe wie « numpy 1.26.4 » bedeutet, dass genau diese Version gewünscht ist.

Oft steht dort keine feste Version, sondern eine Spanne. « Mindestens 1.26, aber unter 2.0 » erlaubt kleine Aktualisierungen ohne Risiko. Der Nachteil: Zwei Personen könnten an verschiedenen Tagen leicht unterschiedliche Versionen bekommen. Deshalb gibt es zusätzlich eine Lockfile. Sie hält fest, welche Versionen tatsächlich installiert wurden, bis auf die letzte Ziffer genau.

Man kann sich das Manifest als Einkaufszettel vorstellen und die Lockfile als Kassenbon. Der Zettel sagt, was gebraucht wird. Der Bon sagt, was wirklich im Korb gelandet ist. Ein häufiger Irrtum ist, die Lockfile für überflüssig zu halten und nicht mitzuspeichern. Dann läuft das Programm auf dem eigenen Rechner, auf dem Server aber plötzlich nicht mehr.

Vom Schulprojekt bis zur Lieferketten-Attacke

Wer sich ein Open-Source-Projekt auf der Plattform GitHub ansieht, findet das Manifest fast immer direkt im Hauptverzeichnis. Ein einziger Befehl im Terminal genügt dann, um das Projekt lauffähig zu machen. Auch beim Ausprobieren von KI-Modellen begegnet man dem Prinzip ständig. Anleitungen beginnen typischerweise mit einer Zeile, die alle nötigen Bibliotheken auf einmal nachlädt.

In Nachrichten taucht der Begriff meist im Zusammenhang mit Angriffen auf die Lieferkette auf. Angreifer schleusen Schadcode in einen beliebten Baustein ein oder veröffentlichen ein Paket mit einem absichtlichen Tippfehler im Namen. Wer sich beim Eintrag im Manifest vertippt, installiert dann das falsche Paket. Diese Masche heißt Typosquatting und hat schon große Firmen getroffen.

Aus diesem Grund gehören automatische Prüfwerkzeuge heute zum Alltag. Sie durchsuchen die Manifeste eines Unternehmens laufend und melden bekannte Sicherheitslücken. Für Investoren ist das ein Markt für sich, denn ganze Firmen leben von dieser Art Software. Der schlichte Einkaufszettel ist damit zu einem zentralen Dokument der IT-Sicherheit geworden.