Bedrohungsmodell für die Lieferkette

Bedrohungsmodell für die Lieferkette

0:00 Im ersten Modul haben wir aufgezeichnet, wie unsere Lieferkette aussieht. Jetzt drehen wir die Perspektive um und schauen mit den Augen von jemandem darauf, der etwas hineinbringen möchte. Das klingt nach einem düsteren Nachmittag, ist aber in Wahrheit der konstruktivste Teil des ganzen Seminars. Denn ein Bedrohungsmodell ist keine Angstliste.

0:19 Es ist die Begründung dafür, welche Maßnahme zuerst kommt — und damit die Antwort auf die Frage, die in jedem Projekt irgendwann gestellt wird: Wir können nicht alles gleichzeitig machen, womit fangen wir an?

Bedrohungsmodell für die Lieferkette

0:31 Wir bleiben am ersten Tag und damit vor dem Build. Was in diesem Modul entsteht, ist eine geordnete Liste — Ihre eigene, für Ihr eigenes Projekt. Die Ordnung darin bestimmt die Reihenfolge der nächsten vierzehn Module. Als Raster nutzen wir dabei die Einteilung, die auch die SLSA-Spezifikation verwendet: Angriffe an der Quelle, Angriffe im Build, Angriffe an der Verteilung.

0:53 Drei Ansatzpunkte, die sich sauber trennen lassen — und für die es jeweils andere Gegenmittel gibt.

Angriffe auf Konten, Commits und Releases

1:00 Beginnen wir ganz vorn, an der Quelle. Alles, was in diesem Kapitel vorkommt, passiert, bevor der Build überhaupt startet — und hinterlässt deshalb eine Spur im Repository. Das ist die gute Nachricht. Die schlechte ist, dass diese Spur täuschen kann. SLSA ordnet Bedrohungen danach, wo sie ansetzen, und das ist eine nützliche Disziplin. Für die Quellcode-Seite ergeben sich vier Gruppen: Änderungen, die ohne Review hineinkommen.

1:27 Änderungen, die den Prozess umgehen. Reviews, die zwar stattfinden, aber wirkungslos sind. Und Änderungsmetadaten, die in die Irre führen. Dahinter steht immer dieselbe Frage, und sie ist erstaunlich schwer zu beantworten: Ist der Stand, den wir ausliefern, wirklich der Stand, den jemand geprüft hat? In vielen Projekten lautet die ehrliche Antwort: vermutlich ja.

1:50 Drei Schichten, und sie werden nach unten hin subtiler. Ganz oben das Offensichtliche: direkt pushen, mit einem zweiten Konto genehmigen, einen Bot missbrauchen. Darunter das Umgehen des Prozesses — ein Force-Push, ein umgehängter Tag, ein übersprungener Check. Und ganz unten das Fälschen von Metadaten: ein fremder Name als Autor, ein manipulierter Zeitstempel. Beachten Sie, dass die Wirksamkeit der Gegenmittel genau umgekehrt verläuft.

2:17 Gegen die oberste Schicht hilft eine Schutzregel, die in fünf Minuten gesetzt ist. Gegen die unterste hilft nur eine Signatur — und die will eingerichtet sein. Dieser Punkt überrascht in Seminaren regelmäßig, deshalb stehen wir hier einen Moment. Ein Release-Tag fühlt sich an wie etwas Festes — die Version eins Punkt vier, für immer.

2:38 Technisch ist er aber nur ein Zeiger, und Zeiger lassen sich umhängen, ohne dass sich am Quellcode irgendetwas ändert. Ähnlich beim Force-Push: Er kann einen bösartigen Commit im Verlauf unsichtbar machen. Und der vierte Punkt ist der menschlich interessanteste — wer mehrere Konten kontrolliert, erfüllt das Vier-Augen-Prinzip formal ganz allein.

2:57 Die Regel ist eingehalten, ihr Zweck nicht. Diese Tabelle zeigt etwas, das ich an guten Spezifikationen schätze: Sie zieht ausdrücklich ihre eigenen Grenzen. Die ersten beiden Zeilen adressiert SLSA — Freigabe vor Übernahme, Sperre für Force-Pushes und Tags. Das sind technische Kontrollen, und technische Kontrollen lassen sich erzwingen. Die dritte Zeile aber nicht: Wenn ein Review nur abgenickt wird, hilft keine Konfiguration.

3:24 Das ist ein Personal- und Kulturthema, und die Spezifikation sagt das offen. Ebenso bei Schwachstellen in der Plattform selbst. Nehmen Sie das als Einladung, ehrlich zu sein: Ein Modell, das alles abzudecken behauptet, hat meist nur ungenau hingesehen. Der erste Punkt ist der mit Abstand häufigste Fund, wenn man in ein Repository schaut: Der Hauptzweig ist ordentlich geschützt, die Release-Tags sind es nicht.

3:50 Damit ist genau der Stand beweglich, der ausgeliefert wird. Der zweite Punkt betrifft Automatisierungskonten, die den Freigabezwang umgehen dürfen — meist mit guter Begründung, meist ohne Ablaufdatum. Der dritte ist unscheinbar: Ein Commit trägt einen Namen, aber keine Signatur; die Zuschreibung ist also geraten. Und der vierte ist tückisch — wenn der Review am Branch hängt und nicht am geprüften Stand, kann nach der Freigabe noch nachgeschoben werden.

Angriffe über Abhängigkeiten und Paketquellen

4:17 Im zweiten Kapitel verlassen wir das eigene Repository. Jetzt geht es um den Code, den niemand im Team geschrieben hat — und der trotzdem mit vollen Rechten im Build läuft. Das ist zahlenmäßig der größte Teil dessen, was Sie ausliefern, und gleichzeitig der Teil mit der geringsten Aufmerksamkeit. Wir schauen uns zwei Angriffsformen an, die oft verwechselt werden, und einen dritten Fall, der die beiden an Wirkung deutlich übertrifft.

4:41 Das entscheidende Wort auf dieser Folie heißt „rekursiv". Jede Bibliothek und jedes Build-Werkzeug, das Sie einbinden, ist selbst ein Artefakt mit einer eigenen Lieferkette — mit eigenen Abhängigkeiten, einem eigenen Build und einer eigenen Registry. Ihre Lieferkette ist also nicht eine Kette, sondern ein Baum, der sich nach unten verzweigt.

5:01 SLSA zieht daraus eine unbequeme, aber ehrliche Konsequenz: Dieselben Anforderungen, die Sie an sich selbst stellen, gehören auf alle Build-Abhängigkeiten angewendet, bevor sie in den Build gelangen. Das ist in der Praxis eine Frage des Maßes — aber der Gedanke ist richtig. Zwei Angriffe, die oft in einem Atemzug genannt werden und doch grundverschieden sind.

5:23 Bei der Dependency Confusion ist der Name gleich, die Quelle eine andere: Ihre Auflösung zieht das falsche Paket, weil zwei Quellen denselben Namen beantworten können. Das ist ein technisches Problem und deshalb technisch lösbar — über Namensräume und die Priorität der Quellen. Beim Typosquatting hingegen vertippt sich ein Mensch einmal.

5:42 SLSA sagt ausdrücklich, dass es dagegen kein technisches Mittel anbietet. Hier hilft nur die Prüfung vor der Aufnahme — also ein Mensch, der zweimal hinsieht. Dieser Gedanke ist der unangenehmste des Kapitels, und die Spezifikation illustriert ihn mit einem drastischen Beispiel: Ein kompromittiertes Archivierungswerkzeug kann eine Hintertür in jedes damit gebaute Binärartefakt legen.

6:05 Nicht in eines — in alle. Der Grund ist einfach: Build-Plugins und Werkzeuge laufen mit den Rechten des Builds, nicht mit denen Ihrer Anwendung. Dazu kommt der Zeitpunkt. Skripte, die bei der Installation ausgeführt werden, laufen, bevor überhaupt jemand den Code gelesen hat. Und ist eine Bibliothek erst statisch eingebunden, lässt sie sich im fertigen Artefakt nicht mehr von Ihrem eigenen Code trennen.

6:29 Eine Übung, die in fast jedem Projekt eine Überraschung bereithält. Sie schauen nach, aus welchen Quellen Ihre Abhängigkeiten tatsächlich kommen — nicht welche konfiguriert sind, sondern welche antwortet. Besonders lohnend ist bei der Deichwacht die interne Bibliothek für die Pegel-Anbindung. Sie trägt einen Namensraum, den auch eine öffentliche Quelle beantworten könnte, und genau daraus entsteht die Verwechslung.

6:53 Zwei Fragen sind zu klären: In welcher Reihenfolge werden die Quellen befragt, und — die wichtigere — welche Namen darf eine Quelle überhaupt beantworten? Die zweite Frage stellt kaum jemand, dabei ist sie die wirksamere. Der erste Punkt ist der Klassiker: Interne Bibliotheken tragen Namen ohne eigenen Namensraum, weil es historisch so gewachsen ist — und niemand ändert das, weil ein Umbenennen wehtut.

7:16 Der zweite betrifft die Werkzeuge selbst; sie gelten als Umgebung und tauchen in keiner Abhängigkeitsliste auf, obwohl wir gerade gesehen haben, wie mächtig sie sind. Der dritte ist eine Feinheit aus der Spezifikation: Laufzeitabhängigkeiten sind eine eigene Lieferkette und gehören hier nicht mitgezählt. Und der vierte ist die Spiegelfalle — ein Paketarchiv wird eingerichtet, um Ausfälle abzufangen, und übernimmt danach ungeprüft alles, was oben ankommt.

Angriffe auf Build, Artefakt und Registry

7:42 Im dritten Kapitel sind wir an dem Punkt angekommen, an dem der Quellcode geprüft ist und alle Abhängigkeiten in Ordnung sind. Zwischen diesem Zustand und dem laufenden Dienst liegen trotzdem noch vier Angriffsflächen — und auf keine davon schaut ein Werkzeug, das Code analysiert. SLSA teilt diesen Abschnitt in vier Stationen: die Parameter, mit denen ein Build startet. Der Build-Vorgang selbst. Die Veröffentlichung des Ergebnisses. Und der Verteilungsweg.

8:08 Für zwei Begriffe, die uns die nächsten Tage begleiten, hier schon die Einordnung: Ab Build-Stufe zwei erzeugt die Steuerungsebene der Plattform die Herkunftsangaben selbst — und nicht das Build-Skript, das Sie geschrieben haben. Ab Stufe drei ist die Plattform zusätzlich gegen kompromittierte Arbeitsknoten gehärtet. Der Unterschied klingt fein, ist aber entscheidend: Es geht darum, wer die Aussage macht.

8:33 Vier Quadranten, vier Gelegenheiten. Bei den Parametern: ein Build aus einem fremden Fork oder von einem ungeschützten Branch. Beim Prozess: ein Eingriff im laufenden Build, ein vergifteter Cache, ein abgeflossenes Geheimnis. Bei der Veröffentlichung: ein Artefakt ohne Herkunftsnachweis — oder mit einem gefälschten. Und bei der Verteilung: ein ausgetauschtes Paket in der Registry.

8:56 Was diese vier verbindet: In keinem Fall ändert sich Ihr Quellcode. Wenn Sie sich für die Skizze aus Modul eins nur eine Erkenntnis merken wollen, dann diese vier Punkte — sie liegen alle rechts vom Commit. Der Cache ist in fast jedem Projekt eine reine Effizienzfrage: Er macht den Build schneller, also nimmt man ihn. Sicherheitstechnisch ist er aber geteilter Zustand zwischen Läufen, und die SLSA-Spezifikation adressiert das ausdrücklich — auf Stufe drei darf es schlicht nicht möglich sein, dass ein Build Cache-Einträge für andere vergiftet.

9:28 Der Grund leuchtet sofort ein: Ein vergifteter Eintrag wirkt in jedem folgenden Build, ohne je im Quellcode zu stehen. Ähnlich beim Zugriff auf den laufenden Build — wer dort eine Sitzung öffnen kann, verändert das Ergebnis, ohne einen Commit zu hinterlassen. Drei Zeilen, und die rechte Spalte ist die interessante, weil sie die Stufen erst verständlich macht.

9:48 Stufe eins wehrt Irrtum und schlampige Ablage ab — es gibt überhaupt einen Herkunftsnachweis. Stufe zwei wehrt die Fälschung durch Dritte ab, weil die Plattform signiert. Und Stufe drei wehrt den Eingriff aus dem Build heraus ab, also den Innentäter oder den kompromittierten Schritt. Die Fußzeile ist mir wichtig: Diese Stufen sind kein Produktzertifikat. Sie sagen nur, wem die Herkunftsaussage ihre Glaubwürdigkeit verdankt.

10:14 In Modul dreizehn nehmen wir sie ausführlich auseinander. Der erste Punkt ist der gefährlichste und begegnet einem oft: Ein Pull Request aus einem fremden Fork startet einen Build, der Zugriff auf Ihre Geheimnisse hat. Damit bringt ein Außenstehender Code zur Ausführung — in einem privilegierten Kontext. In Modul sieben bauen wir das sauber auseinander.

10:35 Der zweite Punkt: Auf Experimentierbranches gelten keine Schutzregeln, weil es dort schneller gehen soll — und aus einem davon wird dann gebaut. Der dritte ist subtil: Die Verifikation prüft die Signatur, aber nicht, aus welchem Repository gebaut wurde. Eine gültige Signatur für ein Artefakt aus der falschen Quelle nützt nichts.

Übung

10:55 Jetzt schreiben Sie Ihr eigenes Bedrohungsmodell. Das Ergebnis ist nicht die Vollständigkeit — die erreicht man ohnehin nie, und wer es versucht, hört nach zwei Stunden entmutigt auf. Das Ergebnis ist eine Reihenfolge, die Sie in vier Wochen noch begründen können, auch wenn dann jemand fragt, warum ausgerechnet diese Maßnahme zuerst kommt.

11:14 Sechs Bedrohungen genügen dafür völlig. Sechs Bedrohungen, zwei je Ansatzpunkt — das ist bewusst klein gehalten. Zu jeder gehören drei Angaben: Was muss der Angreifer vorher besitzen, was erreicht er damit, und würden wir es heute überhaupt bemerken. Vor allem die dritte Angabe verändert die Reihenfolge oft erheblich. Eine Bedrohung mit mittlerem Schaden, die niemand bemerken würde, ist gefährlicher als eine mit hohem Schaden, die sofort auffällt.

11:41 Und die entstandene Reihenfolge ist keine Fingerübung: Sie bestimmt, welche Maßnahme wir in den folgenden Modulen zuerst bauen. Die Schritte bauen aufeinander auf. Sie nehmen die Skizze aus Modul eins und markieren die drei Ansatzpunkte — Quelle, Build, Verteilung. Dann formulieren Sie je Ansatzpunkt zwei Bedrohungen, und zwar konkret: nicht „Abhängigkeiten sind ein Risiko", sondern was genau wer genau täte.

12:06 Anschließend die Voraussetzung, die der Angreifer braucht; das relativiert manches. Dann die Erkennbarkeit, und hier bitte ehrlich bleiben. Zum Schluss die Ordnung nach Schaden und Aufwand. Die Fußzeile fasst den wichtigsten Effekt zusammen: Was niemand bemerken würde, rückt allein dadurch nach oben. Der häufigste Fehler ist der erste: Das Modell bleibt bei Begriffen stehen. „Supply-Chain-Angriff" ist keine Bedrohung, sondern eine Kategorie — beschreiben Sie einen Ablauf.

12:35 Der zweite betrifft die Ehrlichkeit: Die Erkennbarkeit wird optimistisch eingeschätzt, weil ein Protokoll existiert. Die Frage ist aber nicht, ob etwas protokolliert wird, sondern ob jemand hinsieht. Der dritte Punkt: Bedrohungen ohne Gegenmaßnahme werden gestrichen, weil sie unangenehm sind — sie gehören stattdessen als Restrisiko notiert.

12:56 Und der vierte ist der stille Tod jedes Modells: Es entsteht einmal, und dann fasst es niemand mehr an. Im nächsten Modul geben wir ihm einen Rahmen.