Abhängigkeiten und Paketquellen kontrollieren

Abhängigkeiten und Paketquellen kontrollieren

0:00 Wir schließen den ersten Tag mit dem Thema ab, das mengenmäßig das größte ist. Der weit überwiegende Teil dessen, was Sie ausliefern, wurde nie von jemandem in Ihrem Team gelesen — und in vielen Fällen auch nie bewusst ausgewählt. Das ist kein Vorwurf, das ist moderne Softwareentwicklung. Aber es lohnt sich, den Bestand einmal wirklich anzusehen.

0:20 Erfahrungsgemäß ist der Moment, in dem ein Team zum ersten Mal seinen vollständigen Abhängigkeitsbaum ausgibt, einer der lehrreichsten des ganzen Seminars.

Abhängigkeiten und Paketquellen kontrollieren

0:29 Drei Schritte liegen vor uns. Zuerst schauen wir uns an, was der Unterschied zwischen dem ist, was Sie auswählen, und dem, was am Ende im Artefakt landet. Dann geht es um die Quellen — also darum, wer eine Anfrage nach einem Paketnamen überhaupt beantworten darf. Und zum Schluss um die Bewertung: Woran erkennt man eigentlich, ob ein fremdes Projekt vertrauenswürdig genug ist?

0:51 Für die letzte Frage gibt es ein nützliches Werkzeug, das uns allerdings weniger abnimmt, als sein Ergebnis vermuten lässt.

Direkte und transitive Abhängigkeiten

0:58 Beginnen wir mit einer schlichten Zählung. Wie viele Abhängigkeiten hat Ihr Projekt? Die meisten Teams nennen eine Zahl aus der Projektdatei — und liegen damit um eine Größenordnung daneben. Das ist kein Versäumnis, sondern die Natur der Sache: Der größte Teil kommt gar nicht durch eine Entscheidung ins Projekt, sondern durch die Auflösung.

1:17 In diesem Kapitel schauen wir uns an, wo genau die Entscheidung aufhört und der Automatismus beginnt. Der Unterschied ist schnell erklärt und in seinen Folgen groß. Direkte Abhängigkeiten stehen in Ihrer Projektdatei; sie sind eine Entscheidung, jemand hat sie getroffen. Transitive Abhängigkeiten zieht die Auflösung nach — sie stehen nirgends und sind trotzdem im Artefakt.

1:40 Ein Bild dazu: Sie laden zwanzig Gäste ein, und jeder bringt Begleitung mit, die ihrerseits Begleitung mitbringt. Am Ende stehen vierhundert Personen im Raum, und Sie kennen zwanzig davon. Die OWASP Top Ten zählen diese verschachtelten Abhängigkeiten auf allen Ebenen ausdrücklich zur Lieferkette. Drei Befehle, und der erste ist der wichtige — er gibt den vollständigen Baum aus, inklusive der Konflikte und der Frage, wer wen mitgebracht hat.

2:05 Führen Sie ihn einmal in Ihrem eigenen Projekt aus, bevor Sie heute nach Hause gehen. Der zweite Befehl verfolgt gezielt eine einzelne Bibliothek nach oben: Wer hat sie eigentlich hereingeholt? Diese Frage wird in Modul elf wichtig, wenn eine Schwachstelle gemeldet wird und Sie wissen müssen, ob Sie die Komponente überhaupt selbst loswerden können.

2:25 Die Fußzeile beschreibt den Effekt ganz gut — für viele Teams ist das der erste Blick auf das, was sie ausliefern. Der erste Satz fasst das Problem zusammen: Sie wählen eine Version, die nächste Ebene wählt sich selbst. Und wenn es Konflikte gibt — zwei Bibliotheken wollen verschiedene Versionen derselben dritten —, löst der Paketmanager sie nach seinen eigenen Regeln auf.

2:46 Diese Regeln sind nachvollziehbar und dokumentiert, aber sie orientieren sich an Kompatibilität, nicht an der Sicherheitslage. Der dritte Punkt ist der, der uns in Modul acht wieder begegnet: Ohne festgeschriebene Auflösung baut derselbe Quellstand morgen etwas anderes. Und der vierte ist endgültig — statisch eingebundener fremder Code lässt sich im fertigen Artefakt nicht mehr von Ihrem trennen.

3:09 Drei Stufen, und der Sprung von der zweiten zur dritten ist der interessante. Ein Versionsbereich legt fast nichts fest. Eine feste Version legt die Nummer fest — aber eben nur die Nummer. Was hinter dieser Nummer liegt, kann sich ändern: Ein Paket kann in manchen Ökosystemen nachträglich ersetzt werden, und dann bekommen Sie unter derselben Versionsnummer einen anderen Inhalt.

3:30 Erst der Hash beantwortet die Frage, ob dort noch dasselbe liegt wie gestern. Das ist genau die Bedrohung „Paket untergeschoben" aus unserer Tabelle in Modul eins — und die dritte Zeile ist das Gegenmittel. Der erste Punkt ist eine ehrliche Abwägung: Versionsbereiche bleiben stehen, weil sie Updates bequem machen. Das stimmt sogar — nur bezahlt man die Bequemlichkeit mit Unvorhersagbarkeit.

3:54 Der zweite ist ein Widerspruch, den man häufig hört: Die Auflösung ist nirgends festgehalten, und der Build gilt trotzdem als reproduzierbar. Beides zusammen geht nicht. Der dritte Punkt verschiebt Verantwortung dorthin, wo sie nicht ankommt — transitive Abhängigkeiten gelten als Sache der direkten. Und der vierte ist der einfachste zu beheben: Niemand kennt die Zahl, weil sie nie jemand gezählt hat. Der Befehl von eben dauert dreißig Sekunden.

Paketquellen absichern

4:21 Im zweiten Kapitel geht es um eine Frage, die selten gestellt wird und erstaunlich viel entscheidet: Wer darf eigentlich antworten, wenn Ihr Build nach einem Paketnamen fragt? In den meisten Projekten lautet die Antwort: mehrere Quellen, und die Reihenfolge hat vor Jahren jemand festgelegt, der längst woanders arbeitet.

4:38 Genau daraus entsteht einer der billigsten Angriffe auf die Lieferkette. Dependency Confusion nutzt einen simplen Mechanismus aus. Ihr Build fragt mehrere Quellen nach einem Namen, und wenn die höhere Versionsnummer gewinnt, genügt es, den internen Namen öffentlich mit einer höheren Version anzubieten. Kein Einbruch, kein gestohlenes Konto — nur ein öffentlich hochgeladenes Paket, das geduldig wartet.

5:02 SLSA ordnet das den Nutzungsbedrohungen zu und verweist auf verifizierte Erwartungen an die Herkunft. Das Bemerkenswerte an diesem Angriff ist, wie wenig er kostet: Der Angreifer muss nur Ihren internen Paketnamen kennen. Und der steht oft in einer öffentlichen Fehlermeldung. Vier Stationen, und keine davon ist ein Fehler im eigentlichen Sinne. Der interne Name existiert — völlig normal.

5:25 Zwei Quellen antworten — das ist die konfigurierte Rückfallebene, meist mit guter Absicht eingerichtet. Die höhere Version gewinnt — das ist die dokumentierte Regel des Paketmanagers. Und am Ende steht fremder Code im Build. Jeder einzelne Schritt ist vernünftig, das Ergebnis nicht. Solche Ketten sind typisch für Lieferkettenangriffe, und deshalb findet sie kein Werkzeug, das nach Fehlern sucht: Es gibt keinen Fehler, nur eine unglückliche Verkettung von Voreinstellungen.

5:55 Die OWASP-Empfehlungen sind hier ungewöhnlich konkret: Bezug ausschließlich aus offiziellen Quellen über sichere Verbindungen, und signierte Pakete sind vorzuziehen. Der zweite Teil ist wichtiger, als er klingt — die Quelle allein sagt nämlich nichts über den Inhalt. Der dritte Punkt ist das eigentliche Gegenmittel, und es ist unspektakulär: Ein eindeutiger Namensraum für interne Bibliotheken macht die Verwechslung schlicht unmöglich, weil kein anderer diesen Namen beanspruchen kann.

6:22 Und der vierte räumt mit einem Missverständnis auf: Ein Spiegel schützt vor Ausfall. Vor untergeschobenem Inhalt schützt er nicht. Zwei Fragen sind zu beantworten, und die zweite stellt kaum jemand. Die erste: In welcher Reihenfolge werden die Quellen befragt? Das lässt sich aus der Konfiguration ablesen. Die zweite: Welche Namen darf eine Quelle überhaupt beantworten?

6:45 Das ist die wirksamere Frage, denn eine Quelle, die nur den eigenen Namensraum beantworten darf, kann die Verwechslung gar nicht auslösen. Das Erfolgskriterium ist ein echter Test: Ein gleichnamiges öffentliches Paket mit höherer Version darf das Ergebnis nicht ändern. Probieren Sie es aus — ein Gedankenexperiment reicht hier nicht.

7:05 Der erste Punkt beschreibt die häufigste Konfiguration überhaupt: Die öffentliche Quelle steht als Rückfallebene bereit — und beantwortet damit eben auch interne Namen. Eingerichtet wurde sie, damit der Build nicht stehen bleibt, wenn die interne Quelle einmal weg ist. Der zweite ist die Spiegelfalle, die wir schon in Modul zwei hatten.

7:24 Der dritte ist eine Altlast, die wehtut: Interne Pakete ohne eigenen Namensraum, historisch gewachsen, und ein Umbenennen kostet. Und der vierte ist ein Nebenschauplatz mit eigener Sprengkraft — Zugangsdaten zur internen Quelle liegen in der Konfiguration jedes Entwicklungsrechners.

Abhängigkeiten bewerten und aktualisieren

7:41 Bleibt die Frage, die am schwersten zu automatisieren ist: Woran erkennt man, ob ein fremdes Open-Source-Projekt vertrauenswürdig genug ist, um es in die eigene Auslieferung zu lassen? Der Bauch sagt oft etwas dazu — viele Sterne, bekannter Name, wirkt gepflegt. Nur lässt sich damit keine Entscheidung begründen und erst recht keine wiederholen.

8:01 Es gibt einen besseren Ansatz, der allerdings weniger verspricht, als sein Ergebnis vermuten lässt. Die OpenSSF Scorecard ist der Versuch, diese Frage maschinell zu beantworten. Achtzehn Prüfungen in drei Blöcken: übergreifende Sicherheitspraktiken, Risiken im Quellcode und Risiken im Build-Prozess. Jede Prüfung ergibt einen Wert von zehn Punkten und zusätzlich ein Risikoniveau, das als Gewicht in den Gesamtwert eingeht.

8:25 Das ist methodisch sauber gemacht und liefert etwas, das man vorher nicht hatte: einen vergleichbaren ersten Eindruck über tausende Projekte hinweg, ohne dass jemand sie einzeln ansehen muss. Aus den achtzehn Prüfungen habe ich sechs herausgegriffen, die für unser Thema besonders sprechen. Fällt Ihnen etwas auf? Die rechte Spalte liest sich wie eine Kurzfassung der Module zwei bis sieben — angewandt auf Ihren Zulieferer.

8:51 „Ist der Hauptzweig geschützt?" ist genau die Frage, die wir gestern an uns selbst gestellt haben. „Sind Abhängigkeiten fest?" fragt, ob der Zulieferer seinerseits fremdes Risiko erbt. Und „minimale Rechte im Build?" zielt auf die Übernahme durch einen Pull Request. Sie bewerten also Ihren Lieferanten mit denselben Maßstäben, die Sie an sich selbst anlegen. Das finde ich eine gesunde Symmetrie.

9:15 Hier ist Vorsicht angebracht, denn ein Zahlenwert verführt zur Abkürzung. Geprüft wird, was maschinell prüfbar ist — nicht, ob der Code gut ist. Ein Projekt kann eine hohe Punktzahl erreichen, weil es Prüfungen erfüllt, die für Ihren Anwendungsfall bedeutungslos sind. Der dritte Punkt wird gern übersehen: Der Wert altert.

9:34 Er beschreibt den Zustand zum Zeitpunkt des Laufs, nicht den von heute. Und der vierte ist der entscheidende — die Entscheidung über Aufnahme oder Ablösung trifft weiterhin Ihr Team. Das Werkzeug sortiert die Fragen. Beantworten müssen Sie sie. Der erste Punkt ist genau die eben beschriebene Abkürzung: ein Schwellenwert wird gesetzt, ohne dass jemand die einzelnen Prüfungen gelesen hat.

9:58 Dann scheitert irgendwann ein gutes Projekt an einer Prüfung, die nichts bedeutet — und die Regel wird abgeschaltet. Der zweite ist der gefährlichste im Alltag: Automatische Update-Vorschläge werden gesammelt zusammengeführt, ohne Regressionstest. Das ist ein Lieferkettenrisiko, das man selbst erzeugt. Der dritte ist strukturell — aktualisiert wird nur bei Meldung, und der Rückstand wächst im Stillen.

10:21 Und der vierte ist ehrlich: Ein aufgegebenes Projekt bleibt im Bestand, weil ein Wechsel Arbeit bedeutet.

Übung

10:27 Zum Abschluss des ersten Tages schauen wir uns den Bestand der Deichwacht wirklich an. Nicht abstrakt, sondern mit dem Befehl von vorhin und einer Liste, die am Ende Entscheidungen enthält statt Zahlen. Planen Sie dafür ruhig etwas Zeit ein: Der erste Blick in einen vollständigen Abhängigkeitsbaum löst meistens eine längere Diskussion aus, und die ist der eigentliche Ertrag der Übung.

10:49 Drei Bibliotheken genügen, mehr schaffen Sie in der Zeit nicht, und mehr braucht es auch nicht, um die Methode zu lernen. Der Hinweis auf der Folie sagt, welche drei Sie wählen sollten: die, die niemand bewusst aufgenommen hat und die trotzdem im Artefakt stecken. Das sind die interessanten Fälle, weil dort niemand je eine Entscheidung getroffen hat — und weil sie in Modul elf wieder auftauchen, wenn eine Schwachstelle gemeldet wird und die Frage lautet, wer diese Komponente eigentlich hereingeholt hat.

11:15 Fünf Schritte, und der erste liefert die Zahl, die Sie im Team herumzeigen können. Dann die Trennung in direkte und transitive Abhängigkeiten — sie macht sichtbar, wie klein der Teil ist, über den jemand entschieden hat. Der dritte Schritt dokumentiert die Paketquellen und ihre Reihenfolge, und das schließt an das zweite Kapitel an. Erst danach kommt die Bewertung dreier Bibliotheken.

11:37 Und der fünfte Schritt ist der, der aus einer Analyse eine Arbeitsgrundlage macht: behalten, aktualisieren oder ablösen — mit einem Satz Begründung, den Sie in sechs Monaten noch verstehen. Der erste Punkt ist die häufigste Art, wie eine Bewertung wirkungslos bleibt: Sie endet beim Wert und nennt keine Konsequenz. Der zweite betrifft den Zuschnitt — nur direkte Abhängigkeiten werden betrachtet, weil die Liste sonst zu lang wird.

12:02 Verständlich, aber damit sehen Sie an dem Teil vorbei, der mengenmäßig überwiegt. Der dritte ist ein verbreiteter Denkfehler: Ein Update wird als Sicherheitsmaßnahme verbucht, ohne dass jemand die Änderungen kennt. Und der vierte fasst das ganze Kapitel zusammen — die Paketquellen bleiben unbetrachtet, weil sie zur Infrastruktur gezählt werden. Morgen beginnen wir mit der Pipeline.