Die moderne Software-Lieferkette

Die moderne Software-Lieferkette

0:00 Wenn wir über sichere Software reden, denken die meisten zuerst an den eigenen Quellcode. Das ist verständlich — er ist der Teil, den wir selbst geschrieben haben. Aber werfen Sie einmal einen Blick in das Container-Image, das Sie heute Abend ausliefern. Der weit überwiegende Teil dessen, was dort läuft, hat nie ein Mitglied Ihres Teams geschrieben. Es kam aus einer Paketquelle, aus einem Basis-Image, aus einem Build-Werkzeug.

0:24 In diesem Modul zeichnen wir zum ersten Mal auf, wie dieser Weg eigentlich verläuft — und an welchen Stellen jemand eingreifen könnte, ohne dass eine einzige Zeile Ihres Codes sich ändert.

Die moderne Software-Lieferkette

0:35 Der erste Tag beschäftigt sich mit dem, was vor dem Build liegt: mit Risiken, mit dem Entwicklungsprozess und mit den Abhängigkeiten. Wir beginnen bewusst nicht mit Werkzeugen, sondern mit einer Landkarte. Denn jede Maßnahme, die wir in den kommenden drei Tagen bauen, braucht eine Begründung — und die Begründung kommt aus dieser Landkarte.

0:54 Am Ende dieses Moduls hängt eine Skizze Ihrer eigenen Lieferkette an der Wand, und die bleibt dort bis zum letzten Modul stehen.

Stationen vom Commit bis zum produktiven System

1:01 Fangen wir ganz vorn an. Nicht beim Build, nicht beim Deployment, sondern bei der Frage: Welche Stationen durchläuft eine Änderung eigentlich, bis sie beim Nutzer ankommt? Die Antwort fällt in den meisten Teams überraschend lückenhaft aus — und genau diese Lücken sind der Stoff dieses Kapitels. Der Begriff Lieferkette ist aus der Industrie geliehen, und das Bild trägt erstaunlich weit.

1:24 Denken Sie an ein Lebensmittel im Supermarkt: Es besteht aus Zutaten verschiedener Lieferanten, wurde in einer Fabrik verarbeitet, über eine Spedition verteilt und im Regal platziert. An jeder dieser Stationen könnte etwas passieren. Bei Software ist es genauso — nur dass wir die Stationen selten aufschreiben. Wichtig ist der Zuschnitt: Die Kette beginnt nicht beim Build, sondern bei der Entwicklungsumgebung, und sie endet nicht beim fertigen Artefakt, sondern beim Update im laufenden Betrieb.

1:52 Beide Enden werden regelmäßig vergessen. Fünf Kästen, vier Pfeile — und jeder Pfeil ist interessanter als die Kästen. Denn an jedem Pfeil wechselt etwas den Besitzer. Der Quellcode wird zum Build gegeben, der Build gibt ein Artefakt heraus, das Artefakt wandert in die Registry, und von dort holt es sich das Deployment. Halten Sie sich diese Kette vor Augen, wenn wir später über Signaturen sprechen: Eine Signatur ist nichts anderes als der Versuch, einen dieser Pfeile überprüfbar zu machen.

2:21 Ohne sie nimmt jede Station einfach entgegen, was die vorige ihr gibt. Hier liegt der Kern des Problems, und er ist organisatorisch, nicht technisch. Solange niemand eine Prüfung fordert, nimmt jede Station das Ergebnis der vorigen ungeprüft entgegen. Das ist im Alltag auch völlig vernünftig — es wäre unerträglich, wenn jeder Schritt misstrauisch wäre.

2:42 Aber es lohnt sich, die Stellen zu kennen, an denen dieses Vertrauen besonders viel trägt. Der Paketmanager entscheidet, welcher fremde Code überhaupt in den Build gelangt. Der Runner führt diesen Code dann mit den Rechten Ihres Projekts aus. Und die Registry ist der Ort, an dem Ihr fertiges Artefakt am längsten unbeaufsichtigt liegt.

3:02 Diese Tabelle lässt sich auf zwei Arten lesen, und die zweite ist die spannende. Vordergründig steht hier, wer an welcher Station etwas erzeugt. Lesen Sie die mittlere Spalte aber einmal aus der Perspektive eines Angreifers: Das ist die Liste der Konten, die er gerne hätte. Jedes davon erlaubt, etwas in die Kette einzubringen, das die nachfolgenden Stationen bereitwillig weiterreichen. Und beachten Sie, dass in dieser Spalte nicht nur Menschen stehen.

3:28 Erweiterungen, Automatisierungskonten und Paketmanager schreiben ebenfalls — sie tauchen nur in keiner Berechtigungsübersicht auf, weil sie niemandem gehören. Diese vier Punkte begegnen einem in fast jedem Projekt, und sie haben eine gemeinsame Wurzel: Die Lieferkette wird enger gedacht, als sie ist. Sie beginnt gefühlt beim Build, weil dort die Pipeline anfängt — obwohl der Editor mit seinen Erweiterungen längst dazugehört.

3:53 Sie endet gefühlt beim Deployment, obwohl jedes Update denselben Weg noch einmal geht. Und der dritte Punkt ist der, der später am meisten weh tut: Wenn niemand sagen kann, welcher Commit in dem Image steckt, das gerade produktiv läuft, beginnt jede Untersuchung mit einer Woche Archäologie. Genau dagegen arbeiten wir in den Modulen acht und zwölf.

Vertrauensgrenzen und schützenswerte Werte

4:13 Wir haben jetzt die Stationen. Im zweiten Kapitel geht es um die Übergänge zwischen ihnen — und um die Frage, was an jedem Übergang eigentlich auf dem Spiel steht. Der Fachbegriff dafür lautet Vertrauensgrenze, und er klingt abstrakter, als er ist. Eine Vertrauensgrenze ist schlicht die Stelle, an der etwas Ihren Verantwortungsbereich verlässt oder betritt. Ein Bild dazu: die Rampe an der Laderampe eines Lagers.

4:38 Drinnen gelten Ihre Regeln, draußen nicht, und an der Rampe entscheidet sich, was Sie hereinlassen und worauf Sie sich dabei verlassen. Der Nutzen dieser Übung liegt nicht in der Zeichnung selbst. Er liegt darin, dass Sie hinterher aussprechen können, wem Sie warum vertrauen. Und erst wenn dieses Vertrauen ausgesprochen ist, lässt sich die spannende Frage stellen: Welcher Nachweis könnte es ersetzen?

5:01 Vier Quadranten, und jeder stellt eine Frage, die Sie beantworten können sollten. Auffällig ist, wie unterschiedlich die Antworten in der Praxis ausfallen. Beim Quellcode weiß fast jedes Team, wer schreiben darf. Bei den Zugangsdaten wird es schon dünner — Gültigkeitsdauer und Reichweite kennt oft niemand genau. Und der vierte Quadrant, die Signaturschlüssel, gehört in vielen Projekten schlicht niemandem.

5:25 Dabei ist er der heikelste: Wer über diesen Schlüssel verfügt, kann in Ihrem Namen sprechen. In Modul zwölf werden wir sehen, dass es einen eleganten Ausweg gibt — nämlich Schlüssel, die es nur für wenige Minuten gibt. Das Wort „implizit" ist hier das entscheidende. Niemand hat bewusst entschieden, dem Autor einer eingebundenen Action zu vertrauen — es war einfach die Zeile, die in der Anleitung stand.

5:49 Niemand hat entschieden, dem Basis-Image zu vertrauen — es war das erste, das funktionierte. Und der Paketmanager prüft in der Regel die Quelle, nicht den Inhalt; er fragt, woher etwas kommt, nicht ob es noch dasselbe ist wie gestern. Dieses stillschweigende Vertrauen ist nicht per se falsch. Problematisch wird es erst dadurch, dass es nirgends steht — und deshalb auch nirgends überprüft wird.

6:13 Jetzt wird es konkret. Unser Beispielprojekt heißt Deichwacht und überwacht Deiche: Es sammelt Pegelstände ein, berechnet daraus Warnstufen und benachrichtigt Einsatzkräfte. Technisch ein ganz gewöhnlicher Spring-Boot-Dienst mit Maven, gebaut in GitHub Actions, ausgeliefert als Container-Image. Ihre Aufgabe ist nicht, Lücken zu finden — dafür ist es zu früh. Ihre Aufgabe ist, das Vertrauen auszusprechen, das heute ohnehin schon gewährt wird.

6:41 Zu jeder Grenze also drei Angaben: Wem wird vertraut, worauf stützt sich das, und was könnte es ersetzen? Die dritte Frage darf ruhig offenbleiben. Sie wird uns drei Tage lang begleiten. Ein Muster, das sich in dieser Übung fast immer zeigt: Die Vertrauensgrenze wird großzügig um das eigene Team gezogen, und die Build-Plattform steht wie selbstverständlich innerhalb.

7:03 Dabei ist sie ein externer Dienstleister mit weitreichenden Rechten an Ihrem Code. Der zweite typische Fehler betrifft die Liste der schützenswerten Werte: Sie endet bei der Anwendung. Logs, Caches und Build-Nachweise stehen nicht darauf — obwohl genau diese drei Dinge es sind, die Sie nach einem Vorfall dringend brauchen.

7:21 Und schließlich: Solange die Grenzen nur in den Köpfen existieren, hat jeder im Team eine leicht andere Karte.

Angriffspfade und Abgrenzung zur Anwendungssicherheit

7:27 Im dritten Kapitel wird es unangenehm konkret. Wir schauen uns an, wie Angriffe auf die Lieferkette tatsächlich ablaufen — und warum die etablierten Werkzeuge der Anwendungssicherheit sie systematisch übersehen. Das ist keine Kritik an diesen Werkzeugen. Sie tun genau das, wofür sie gebaut wurden; sie schauen nur an einer anderen Stelle hin.

7:47 Wenn Sie am Ende dieses Kapitels einen Satz mitnehmen, dann diesen: Ein geprüfter Quellcode und ein vertrauenswürdiges Artefakt sind zwei verschiedene Aussagen. Dass dieses Thema inzwischen ernst genommen wird, lässt sich an einer Stelle gut ablesen: Die OWASP Top Ten in der Ausgabe 2025 führen Fehler in der Software-Lieferkette als eigene Kategorie A03.

8:08 Das ist eine bemerkenswerte Verschiebung. Früher stand dort „Komponenten mit bekannten Schwachstellen" — es ging also um Lücken, für die es eine Meldung und eine Nummer gab. Die neue Kategorie ist deutlich weiter gefasst: Brüche oder Kompromittierungen beim Bauen, Verteilen oder Aktualisieren von Software. Darunter fallen auch Manipulationen, zu denen es nie eine CVE gab und nie eine geben wird, weil niemand sie gemeldet hat.

8:34 Der Gegensatz auf dieser Folie ist der wichtigste Gedanke des ganzen Moduls. Anwendungssicherheit fragt: Ist der Code fehlerfrei? Lieferkettensicherheit fragt: Ist das Artefakt echt? Das sind zwei völlig verschiedene Fragen, und die zweite lässt sich nicht durch bessere Antworten auf die erste beantworten. Sie können einen makellos geprüften Quellcode haben — und trotzdem ein manipuliertes Image ausliefern, wenn zwischen beiden etwas passiert ist. Beide Disziplinen sind nötig.

9:01 Nur ersetzt eben keine die andere, und in den meisten Teams ist die linke Spalte gut besetzt und die rechte gar nicht. Diese Zahlen lohnen einen zweiten Blick, weil sie auf den ersten irritieren. Die Kategorie hat mit rund fünfeinhalb Prozent die höchste durchschnittliche Auftretensrate aller zehn Kategorien — sie ist also alles andere als ein Randthema.

9:22 Ihr sind sechs Schwachstellenklassen zugeordnet mit weit über zweihunderttausend gezählten Vorkommen. Und dann stehen dem gerade einmal elf CVEs mit passender Zuordnung gegenüber. Diese Lücke ist kein Grund zur Entwarnung. Sie ist der Hinweis darauf, dass wir hier ein Erkennungsproblem haben: Was nicht gemeldet wird, taucht in keiner Statistik auf — und in keinem Scanner.

9:44 Vier Wege, und die Fußzeile enthält die eigentliche Pointe: Nur der erste hinterlässt überhaupt eine Spur im Quellcode. Wenn ein Konto übernommen wurde, sehen Sie im Repository eine Änderung — sie trägt nur eine gültige Signatur. Bei den anderen drei ist der Quellcode makellos. Beim untergeschobenen Paket ändert sich Ihre Projektdatei nicht. Beim manipulierten Build weicht nur das Artefakt vom Code ab.

10:07 Und beim ausgetauschten Artefakt in der Registry hat sich überhaupt nichts an Ihrem Projekt geändert. Keine Codeanalyse der Welt findet diese drei — sie schaut an der falschen Stelle. Die Beispiele auf dieser Folie sind keine Gedankenspiele. Ein selbstausbreitender Wurm im Paket-Ökosystem hat 2025 über fünfhundert Paketversionen infiziert — über Skripte, die bei der Installation ausgeführt werden, also lange bevor irgendjemand den Code gelesen hat.

10:34 Der zweite Punkt beschreibt das Grundmuster: Ein kompromittierter Anbieter erreicht mit einem einzigen Update Tausende Organisationen gleichzeitig. Und der dritte ist der unangenehmste — Schadcode kann sich schlafend stellen und erst unter bestimmten Bedingungen aktiv werden. Der vierte Punkt erklärt, warum wir trotzdem beim Bekannten bleiben: Für bekannte Schwachstellen gibt es ein Werkzeug. Für den Rest braucht es einen Prozess.

Übung

10:59 Genug Theorie. Im letzten Kapitel dieses Moduls zeichnen Sie die Lieferkette der Deichwacht auf — und legen damit die Grundlage für alles, was in den nächsten drei Tagen folgt. Nehmen Sie sich die Zeit dafür wirklich. Es ist verlockend, schnell etwas hinzuskizzieren und zu den Werkzeugen überzugehen, aber diese Zeichnung ist die Referenz, an der wir später jede Maßnahme messen.

11:21 Wer hier ungenau ist, begründet in Modul dreizehn seine Reifegrade mit Erinnerung statt mit Belegen. Diese Skizze ist keine Fingerübung. Sie bleibt bis zum letzten Modul an der Wand hängen, und jedes weitere Modul trägt eine Maßnahme darin ein. Zwei Dinge sind wichtig. Erstens: Zeichnen Sie bis zum Update im laufenden Betrieb, nicht nur bis zum ersten Deployment.

11:43 Zweitens: Wenn Sie am Ende drei Stellen markieren, begründen Sie die Auswahl mit Reichweite — also mit der Frage, wie viele Konsumenten ein Eingriff erreicht, bevor ihn jemand bemerkt. Nicht mit Bauchgefühl, und ausdrücklich nicht mit dem Aufwand für den Angreifer. Der kommt im nächsten Modul dazu. Die Schritte folgen einer bewussten Reihenfolge: erst beschreiben, dann bewerten.

12:06 Zuerst listen Sie die Stationen auf — vom Arbeitsplatz bis zum laufenden Dienst, also mit beiden Enden, die sonst fehlen. Dann notieren Sie je Station, was hineingeht und was herauskommt; das klingt banal, macht aber die Übergaben erst sichtbar. Diese Übergaben markieren Sie anschließend als Vertrauensgrenzen und schreiben dazu, worauf sich das Vertrauen stützt. Erst im letzten Schritt wird bewertet.

12:29 Wer zu früh bewertet, diskutiert über Werkzeuge, bevor der Ablauf überhaupt auf dem Papier steht. Vier Fallen, alle schon gesehen. Die Skizze endet beim Deployment, weil sich das wie das Ziel anfühlt — dabei geht jedes Update denselben Weg noch einmal, und Updates sind häufiger als Erstauslieferungen. Entwicklungsrechner und Editor-Erweiterungen fehlen, weil sie nicht zur Pipeline gezählt werden.

12:53 Bei der Auswahl der kritischen Stellen schleicht sich der Aufwand ein: Was leicht zu ändern wäre, wird markiert, und was weh täte, bleibt unmarkiert. Und der letzte Punkt ist der verbreitetste — nach zehn Minuten reden alle über Werkzeuge. Halten Sie durch, bis der Ablauf steht. Im nächsten Modul machen wir daraus ein Bedrohungsmodell.