SLSA 1.2 in der Praxis

SLSA 1.2 in der Praxis

0:00 Willkommen zum dritten Tag. SLSA hat uns seit Modul zwei begleitet — mal als Bedrohungsmodell, mal als Stufenangabe. Jetzt nehmen wir die Spezifikation systematisch auseinander und wenden sie auf unser eigenes Projekt an. Und ich möchte vorweg eine Erwartung dämpfen, weil das sonst am Ende dieses Moduls zu Enttäuschung führt: Eine Stufe ist kein Siegel, das man sich an die Wand hängt.

0:22 Sie ist die Antwort auf die Frage, wem die Herkunftsaussage ihre Kraft verdankt. Das ist weniger schmückend und dafür brauchbar.

SLSA 1.2 in der Praxis

0:31 Der dritte Tag führt zusammen, was wir gebaut haben, und ergänzt die Auslieferung und die regulatorische Seite. Wir beginnen mit SLSA in drei Schritten: der Aufbau mit seinen zwei Spuren, die Stufen des Build Track im Detail, und schließlich die ehrliche Bewertung der eigenen Lieferkette samt Verbesserungsplan. Das Ergebnis dieses Moduls fließt direkt in die Roadmap ein, die wir im letzten Modul erstellen.

Zielsetzung und Aufbau

0:53 Beginnen wir mit dem Aufbau, denn hier gibt es eine Trennung, die oft übersehen wird. SLSA hat nicht eine Skala, sondern zwei — und sie messen verschiedene Dinge. Wer nur die eine kennt, wundert sich später über Anforderungen, die er nirgends unterbringen kann. Die beiden Spuren heißen Build Track und Source Track. Der Build Track befasst sich mit der Herstellung von Artefakten, der Source Track mit der Integrität von Quellrevisionen.

1:19 Beide liefern Attestierungen, aber auf verschiedenen Ebenen der Lieferkette — und, das ist der entscheidende Satz, sie stehen nebeneinander und ersetzen einander nicht. Sie können also eine hervorragend abgesicherte Build-Plattform haben und trotzdem eine ungeschützte Quelle. Dann ist Ihr Artefakt nachweislich aus einem Stand gebaut, über dessen Zustandekommen niemand etwas sagen kann.

1:40 Die Gegenüberstellung macht den Unterschied greifbar. Links die Frage: Wie entstand die Revision — wer änderte was, wann, und welche Kontrollen galten dabei? Rechts: Wie entstand das Artefakt — wer baute woraus und womit? Beachten Sie die letzte Zeile: Der Source Track hat vier Stufen, der Build Track drei. Das ist ein Detail, an dem man erkennt, ob jemand die Spezifikation gelesen hat oder nur Schlagworte kennt.

2:05 Und es hat einen inhaltlichen Grund, der uns gleich begegnet — die vierte Stufe betrifft eine Kontrolle, die über die reine Technik hinausgeht. Vier Stufen. Die erste verlangt nur ein modernes Versionskontrollsystem — die haben Sie. Die zweite verlangt eine gesicherte Historie und einen Herkunftsnachweis je Revision, zeitnah erzeugt.

2:26 Die dritte verlangt, dass das Quellkontrollsystem organisatorische Kontrollen an bestimmten Branches technisch erzwingt — das ist genau die Arbeit aus Modul vier. Und die vierte verlangt die Freigabe durch zwei verschiedene Personen. Die Fußzeile enthält eine Feinheit, die viele überrascht: Technische Kontrollen wirken erst ab ihrer Aktivierung.

2:46 Eine Lücke setzt die bezeugte Historie zurück — man kann sie also nicht rückwirkend behaupten. Das klingt nach einem technischen Detail und ist das Fundament. Eine Revisionskennung muss im Repository eindeutig und unveränderlich sein. Und ein Branch darf nur auf Revisionen zeigen, die von der aktuellen abstammen — bei einer Verzweigung ist also kein Umschreiben erlaubt.

3:08 Damit ist das nachträgliche Verändern der Historie technisch ausgeschlossen, und genau das war die Bedrohung „Verlauf manipuliert" aus Modul zwei. Der vierte Punkt ergänzt die menschliche Seite: Das Quellkontrollsystem muss eine Identitätsverwaltung bereitstellen und die handelnden Akteure ausweisen. Ohne Identität keine Zuschreibung.

3:28 Der erste Punkt begegnet einem in Vertriebsunterlagen: Die Stufe wird für das Unternehmen beansprucht statt für ein konkretes Repository. Stufen gelten je Artefakt und je Repository, nicht je Firma. Der zweite ist die verbreitete Schieflage — der Source Track wird übersprungen, weil der Build Track greifbarer wirkt. Der dritte ist die eben besprochene Rückwirkungsfalle: Kontrollen werden aktiviert und die Historie davor gilt als bezeugt.

3:53 Und der vierte ist ein technischer Fehler mit weitreichender Folge — ein Umschreiben über eine Verzweigung hinweg macht die Abstammungskette unbrauchbar.

Die Stufen des Build Track

4:02 Jetzt zum Build Track, den wir in Teilen schon kennen. Ich möchte ihn hier vollständig und in der Sprache der Spezifikation durchgehen — auch deshalb, weil diese Formulierungen in Ausschreibungen und Kundenfragebögen auftauchen und man dann wissen sollte, was genau zugesagt wird. Auf Stufe eins wählt der Hersteller eine geeignete Plattform, folgt einem einheitlichen Bauprozess und verteilt die Provenance.

4:25 Das klingt bescheiden und ist trotzdem mehr, als viele Projekte heute haben. Auf Stufe zwei kommt hinzu, dass die Provenance signiert und von der Steuerungsebene erzeugt ist — nicht vom Auftraggeber des Builds. Auf Stufe drei ist sie nicht fälschbar: Signaturmaterial bleibt vom Build getrennt, und für jeden Build wird eine neue Umgebung bereitgestellt.

4:44 Die Steigerung folgt also einer Logik — es geht schrittweise darum, wer die Aussage nicht mehr beeinflussen kann. Drei Schichten, und man kann sie als Antwort auf drei verschiedene Angreifer lesen. Stufe eins schützt gegen Schlamperei — es gibt überhaupt einen Nachweis. Stufe zwei schützt gegen Dritte, die etwas behaupten — die Signatur der Plattform macht die Fälschung schwer.

5:06 Und Stufe drei schützt gegen den Angreifer, der bereits im Build ist: Weil die Geheimnisse außerhalb liegen und die Umgebung kurzlebig ist, kann er die Aussage über sich selbst nicht fälschen. Diese Lesart hilft bei der Auswahl des Zielniveaus, gleich im dritten Kapitel. Drei Rollen, und die dritte fehlt in den meisten Diskussionen. Der Hersteller wählt die Plattform, baut einheitlich und verteilt die Provenance.

5:30 Die Plattform erzeugt die Provenance, sorgt für Isolation und verwahrt das Signaturmaterial — das ist der Teil, den Sie einkaufen und nicht selbst bauen. Und der Prüfer bestätigt Echtheit und Identität der Plattform. Der letzte Satz ist mir wichtig: Fehlt der Prüfer, ist die gesamte Kette nur Dokumentation. Genau deshalb haben wir in Modul zwölf so viel Zeit auf die Verifikationsregel verwendet — sie ist die Rolle des Prüfers in Softwareform.

5:56 Diese Tabelle ist der Grund, warum ich dieses Modul mag. Zwei verbreitete Annahmen, beide falsch, beide teuer. Erstens: Stufe drei verlange Bitgleichheit. Tut sie nicht — Reproduzierbarkeit ist nicht gefordert, und wer das Projektziel danach ausrichtet, arbeitet an der Spezifikation vorbei. Zweitens: Stufe drei verlange Netzfreiheit.

6:18 Tut sie ebenfalls nicht — Hermetik ist ausdrücklich ausgenommen. Die Fußzeile sagt, was tatsächlich gefordert ist: Isolation. Kein geteilter Zustand, kein vergifteter Cache, keine Nachwirkung auf den Folgelauf. Das ist anspruchsvoll genug und deutlich erreichbarer. Der erste Punkt ist der häufigste echte Mangel: Die Provenance entsteht im Build-Skript statt durch die Plattform — und ist damit von genau der Partei beeinflussbar, über die sie Auskunft gibt.

6:47 Der zweite ist die Hürde auf dem Weg zu Stufe drei, die am meisten Arbeit macht: Externe Parameter bleiben unvollständig erfasst. Der dritte ist der Schlüssel in der Build-Umgebung, den wir aus Modul acht kennen. Und der vierte ist die Bequemlichkeit, die Stufe drei kostet — die Umgebung wird wiederverwendet, weil das Bereitstellen Zeit braucht.

Bewertung und Verbesserungsplanung

7:06 Im dritten Kapitel wird es persönlich: Sie stufen Ihre eigene Lieferkette ein. Und ich gebe Ihnen dafür einen Rat mit, der gegen jeden Instinkt geht — stufen Sie im Zweifel niedriger ein. Eine ehrliche Zwei ist mehr wert als eine geschönte Drei, weil nur die ehrliche Einstufung Ihnen sagt, wo Sie arbeiten müssen. Eine Bewertung ordnet die vorhandene Lieferkette den Stufen zu und belegt jede Aussage mit einem Nachweis.

7:31 Das Wort Nachweis ist hier das entscheidende — nicht Absicht, nicht Vorhaben, sondern etwas, das man vorzeigen kann. Die Spezifikation selbst formuliert ihren Zweck unmissverständlich: Die Stufen sind kein Produktzertifikat, sondern ein Rahmen für technische Bewertung und Verbesserung. Der Nutzen entsteht also nicht aus der Zahl, sondern aus der Lücke, die sie sichtbar macht. Wer das umdreht und die Zahl zum Ziel macht, optimiert am Zweck vorbei.

7:58 Fünf Schritte. Je Artefakt bestimmen, welche Stufe heute belegbar ist. Zu jeder Aussage den Nachweis benennen — Konfiguration, Attestierung, Protokoll. Ein realistisches Zielniveau wählen und begründen. Die Lücken auflisten. Und nach Wirkung und Aufwand ordnen, mit Terminen. Die Fußzeile enthält zwei Sätze, die ich in vielen Projekten zitiert habe: Ein Zielniveau ohne Termin ist eine Absichtserklärung.

8:24 Und ein Termin ohne Verantwortliche ist ein Wunsch. Beides ist nicht schlimm, solange man es weiß — schlimm wird es, wenn man es für einen Plan hält. Hier schließt sich der Kreis zu Modul zwei. Stufe zwei lohnt überall dort, wo ein Konsument die Herkunft prüfen soll — das ist der Regelfall für alles, was Ihr Haus verlässt.

8:43 Stufe drei lohnt dort, wo ein Eingriff aus dem Build heraus ernsthaft droht; das hängt davon ab, wie viel fremder Code in Ihrem Build läuft und wer Zugriff auf die Plattform hat. Der dritte Punkt ist eine Erlaubnis, die selten ausgesprochen wird: Eine höhere Stufe für ein internes Werkzeug kann schlicht Verschwendung sein.

9:01 Und der vierte rät zur Dokumentation, sonst führen Sie diese Diskussion jedes Quartal neu. Das Erfolgskriterium ist hart und absichtlich so: Die Einstufung nennt je Anforderung einen Beleg — Konfiguration, Attestierung oder Protokoll —, keine Absichtserklärung. Der Hinweis nimmt den Druck heraus: Wer sich nicht sicher ist, stuft niedriger ein. Die Lücke ist das Ergebnis, nicht die Note.

9:24 Das ist keine Bescheidenheitsübung, sondern Pragmatismus — eine zu hohe Einstufung fällt spätestens dann auf, wenn ein Kunde nach Belegen fragt, und dann ist der Vertrauensschaden größer als der Gewinn aus der schönen Zahl. Der erste Punkt ist der häufigste Bewertungsfehler: Die Stufe wird aus der verwendeten Plattform abgeleitet statt aus der eigenen Konfiguration.

9:46 Die Plattform kann Stufe drei ermöglichen — ob Sie sie erreichen, hängt davon ab, wie Sie sie nutzen. Der zweite ist verwandt: Belege sind Verweise auf fremde Dokumentation statt auf den eigenen Aufbau. Der dritte ist die Zahlenverlockung — das Zielniveau wird auf drei gesetzt, weil es die höchste Zahl ist. Und der vierte ist das übliche Schicksal von Analysen: eine Liste ohne Reihenfolge und ohne Termine.

Übung

10:10 In der Übung erstellen Sie Bewertung und Verbesserungsplan für die Deichwacht. Halten Sie den Plan knapp und konkret — er wandert im letzten Modul in die Gesamt-Roadmap, und dort konkurriert er mit den offenen Punkten aus den Modulen fünf, sechs und fünfzehn um Platz und Aufmerksamkeit. Drei Ergebnisse: die belegte heutige Stufe, ein begründetes Zielniveau und die nach Wirkung und Aufwand geordneten, terminierten Lücken.

10:33 Achten Sie beim Zielniveau auf die Begründung aus dem Bedrohungsmodell — nicht „weil drei besser ist als zwei", sondern „weil in unserem Build fremder Code mit Zugriff auf Signaturmaterial läuft". Solche Sätze überstehen auch die Rückfrage aus der Geschäftsführung, warum diese Arbeit eingeplant werden soll. Die Anforderungen des Build Track als Liste aufschreiben. Je Anforderung den heutigen Zustand mit Beleg eintragen.

10:58 Denselben Durchgang für den Source Track — beide getrennt, sonst wird die Bewertung unbrauchbar. Ein Zielniveau je Spur wählen und mit dem Bedrohungsmodell begründen. Und die Lücken ordnen, terminieren, mit Verantwortlichen versehen. Die Fußzeile nennt das Ordnungsprinzip, das seit Modul zwei gilt: Die Reihenfolge folgt der Wirkung gegen Ihre Bedrohungen — nicht der Nummerierung der Stufen.

11:22 Der erste Punkt macht die Bewertung wertlos: Beide Spuren werden vermengt, und am Ende steht eine Zahl, die nichts bezeichnet. Der zweite ist der Beleg aus der Erinnerung — er hält keiner Nachfrage stand. Der dritte ist eine Schieflage, die bei Technikern häufig vorkommt: Der Plan enthält nur technische Maßnahmen und lässt Prozesse aus, obwohl gerade die vierte Source-Stufe eine Prozessfrage ist.

11:44 Und der vierte ist die Verwandlung, die jede Arbeitsliste tötet — sie wird zum Statusbericht nach oben weitergereicht und hört auf, eine Arbeitsliste zu sein.