Reproduzierbare und nachvollziehbare Builds

Reproduzierbare und nachvollziehbare Builds

0:00 Dieses Modul räumt mit einem verbreiteten Missverständnis auf, und zwar mit einem, das viele Projekte schon Zeit gekostet hat. Reproduzierbarkeit und Nachvollziehbarkeit klingen ähnlich und werden oft in einem Atemzug genannt. Sie sind aber zwei verschiedene Ziele mit verschiedenem Aufwand und verschiedenem Nutzen. Und — das wird viele überraschen — nur eines von beiden verlangt die SLSA-Spezifikation.

0:24 Wir schauen uns beide an und klären, welches Sie wirklich brauchen. Die kurze Antwort vorweg: Nachvollziehbarkeit brauchen Sie. Reproduzierbarkeit ist ein Geschenk, wenn Sie sie bekommen.

Reproduzierbare und nachvollziehbare Builds

0:35 Wir bleiben beim zweiten Tag und rücken vom Drumherum der Pipeline in den Build selbst. Drei Themen: die Build-Umgebung und was Isolation eigentlich bedeutet. Dann der Determinismus — warum zwei Bauläufe desselben Stands verschiedene Ergebnisse liefern und was man dagegen tun kann. Und schließlich die Nachweise: Was muss ein Build eigentlich mitliefern, damit Sie in einem halben Jahr noch sagen können, woraus ein Artefakt entstanden ist?

Kontrollierte Build-Umgebungen

1:00 Beginnen wir mit der Umgebung. Hier sind die SLSA-Anforderungen ungewöhnlich konkret, und sie werden von Stufe zu Stufe schärfer. Wichtig ist dabei ein Begriff, der oft zu weit ausgelegt wird: Isolation. Sie bedeutet etwas anderes, als viele annehmen — und deutlich weniger, als der erste Reflex vermuten lässt. Ab Build-Stufe zwei verlangt SLSA Isolation zwischen Builds: Läufe dürfen sich weder zeitlich beeinflussen noch Artefakte teilen.

1:27 Ab Stufe drei kommt hinzu, dass für jeden Build eine neue Umgebung bereitgestellt werden muss — und dass ein Build die Umgebung nachfolgender Builds weder verändern noch überdauern darf. Das ist eine sehr präzise Formulierung, und sie zielt genau auf die Bedrohungen aus Modul zwei: den vergifteten Cache und die Reste eines Laufs auf dem Dateisystem.

1:47 Nicht „sauber machen" ist gefordert, sondern „neu bereitstellen". Das ist ein Unterschied. Drei Schichten, die aufeinander aufbauen. Gehostet bedeutet zunächst nur: nicht auf persönlichen Arbeitsplätzen gebaut. Das klingt selbstverständlich, ist es aber nicht — in vielen Häusern gibt es genau einen Rechner, auf dem das Release entsteht, meist weil dort eine Lizenz oder ein Zertifikat liegt.

2:10 Isoliert heißt: kein geteilter Zustand zwischen Läufen. Und kurzlebig heißt: für jeden Build eine neue Umgebung. Wenn Sie diese drei Schichten in Ihrer Pipeline durchgehen, wissen Sie recht genau, wo Sie stehen — und das brauchen wir in Modul dreizehn wieder. Diesen Punkt möchte ich betonen, weil er in Projekten für viel unnötige Arbeit sorgt. Isoliert heißt: Builds können sich nicht gegenseitig beeinflussen.

2:35 Hermetisch hieße: Der Build kommt ohne Netzzugriff aus — er lädt nichts nach. Und die Spezifikation sagt ausdrücklich, dass Stufe drei das nicht verlangt; sie verweist Hermetik in künftige Überlegungen. Ihr Build darf also Abhängigkeiten laden. Er muss nur ohne Reste des vorigen Laufs starten. Wenn Ihnen jemand erklärt, für Stufe drei müsse die Build-Umgebung offline sein, dürfen Sie ihm freundlich widersprechen.

3:00 Diese Tabelle fasst zusammen, was wir gerade besprochen haben, und ergänzt die Provenance-Seite. Auf Stufe eins existiert ein Herkunftsnachweis, der das Artefakt eindeutig benennt. Auf Stufe zwei ist er signiert und stammt von der Steuerungsebene — nicht aus Ihrem Build-Skript. Auf Stufe drei ist er nicht fälschbar, weil Signaturmaterial und Build getrennt sind.

3:21 Die Fußzeile enthält eine Feinheit, die in der Praxis viel Arbeit macht: Auf Stufe zwei dürfen externe Parameter unvollständig erfasst sein, auf Stufe drei müssen sie vollständig aufgezählt werden. Das ist oft der schwierigste Teil des Aufstiegs. Der erste Punkt ist der Rechner unter dem Schreibtisch — es gibt ihn öfter, als man zugibt, und die Begründung ist fast immer eine Lizenz.

3:44 Der zweite ist die Bequemlichkeitsfalle: Ein Cache wird über Projektgrenzen geteilt, um Bauzeit zu sparen, und damit ist die Isolation dahin. Der dritte ist der Unterschied, den wir eben herausgearbeitet haben — aufräumen statt neu erzeugen. Und der vierte ist der ernsteste im Hinblick auf Modul zwölf: Der Signaturschlüssel liegt in derselben Umgebung, in der auch fremder Code läuft. Genau das schließt Stufe drei aus.

Deterministische Ergebnisse

4:08 Jetzt zum zweiten Begriff. Reproduzierbarkeit ist ein faszinierendes Ziel mit einer klaren Aussage: Wenn zwei unabhängige Bauläufe dasselbe Ergebnis liefern, kann unterwegs nichts dazugekommen sein. Nur ist der Weg dorthin steiniger, als es klingt — und er ist, wie gesagt, nicht das, was SLSA von Ihnen verlangt. Ein reproduzierbarer Build erzeugt aus demselben Quellstand und denselben Eingaben ein bitgleiches Ergebnis.

4:34 Das ist ein eigenständiges und lohnendes Ziel — und ausdrücklich keine Anforderung der SLSA-Build-Stufen. Die zielen auf Isolation und auf die Echtheit der Herkunftsaussage, nicht auf Bitgleichheit. Warum ist mir das wichtig? Weil ich schon Projekte gesehen habe, die monatelang an Bitgleichheit gearbeitet haben, um eine Stufe zu erreichen, die das nie verlangt hat. Machen Sie es, weil es Ihnen nützt.

4:58 Nicht, weil eine Spezifikation es angeblich fordert. Die Gegenüberstellung zeigt, dass beide Ziele verschiedene Fragen beantworten. Reproduzierbar heißt: Jeder kann nachbauen und damit beweisen, dass nichts dazugekommen ist. Das ist eine starke Aussage, die ohne Vertrauen in irgendjemanden auskommt. Nachvollziehbar heißt: Die Plattform bezeugt, wer woraus und womit gebaut hat.

5:22 Das ist eine schwächere Aussage, weil sie Vertrauen in die Plattform voraussetzt — dafür ist sie in jedem realen Projekt erreichbar. Deshalb ist der Build Track auf diese zweite Aussage gebaut. Er verlangt etwas, das man tatsächlich liefern kann. Die gute Nachricht für alle, die es doch versuchen wollen: Die Ursachen sind überschaubar und wiederholen sich über alle Ökosysteme.

5:45 Zeitstempel, die beim Bauen in das Artefakt geschrieben werden — der häufigste Fall. Absolute Pfade der Build-Umgebung, die im Ergebnis landen. Reihenfolgen aus dem Dateisystem oder aus nebenläufiger Verarbeitung, die nicht festgelegt sind. Und Werkzeugversionen, die mitwandern. Wenn Sie diese vier abarbeiten, sind Sie meist erstaunlich weit.

6:05 Vollständige Bitgleichheit erreichen Sie damit nicht immer — aber Sie kennen die verbleibenden Abweichungen, und das ist schon viel wert. Eine Übung, die fast immer verblüfft. Sie bauen denselben Quellstand zweimal und vergleichen die Digests. In den meisten Projekten sind sie verschieden, und dann beginnt die interessante Arbeit: Wo kommt die Abweichung her?

6:27 Der Hinweis auf der Folie nimmt den Druck heraus — wer keine Bitgleichheit erreicht, hat trotzdem gewonnen. Die Liste der Ursachen ist das eigentliche Ergebnis. Denn jede Ursache, die Sie benennen können, ist eine Stelle, an der Ihr Build heute etwas tut, das niemand beabsichtigt hat. Der erste Punkt ist der Ehrgeizfehler: Bitgleichheit wird zum Ziel erklärt, bevor jemand die Ursachen kennt. Beginnen Sie mit der Liste, nicht mit dem Ziel.

6:53 Der zweite ist ein methodischer Fehler mit ärgerlicher Wirkung — verglichen wird über Dateigrößen statt über Digests; zwei verschiedene Artefakte können durchaus gleich groß sein. Der dritte ist die falsche Begründung, über die wir eben gesprochen haben. Und der vierte ist die Voraussetzung, die oft fehlt: Werkzeugversionen stehen nirgends, und der nächste Build nimmt neuere. Dann vergleichen Sie zwei verschiedene Dinge.

Nachweise aufbewahren

7:17 Im dritten Kapitel geht es um etwas, das nach Verwaltung klingt und im Ernstfall über Stunden oder Wochen Untersuchungsdauer entscheidet. Ein Nachweis, der zum Zeitpunkt der Frage nicht mehr existiert, hat nie einen Nutzen gehabt — und Build-Protokolle haben die unangenehme Eigenschaft, genau dann zu verfallen, wenn man sie braucht.

7:35 Zwei Anforderungen greifen hier ineinander. SLSA verlangt, dass der Hersteller die Provenance an die Konsumenten des Artefakts verteilt — oder diese Aufgabe an das Paket-Ökosystem delegiert. Sie darf also nicht einfach entstehen und liegen bleiben; sie muss ankommen. Und der SSDF verlangt in seiner Praxis zur Archivierung, jedes Release samt zugehöriger Daten sicher aufzubewahren, Integritätsangaben eingeschlossen.

7:59 Zusammen ergibt das eine schlichte Regel: Was ein Build an Nachweisen erzeugt, gehört an einen Ort, der das Release überdauert und den ein Dritter erreichen kann. Fünf Nachweise, und die rechte Spalte sagt, wann Sie jeden brauchen. Die Quellrevision braucht jede Ursachensuche — ohne sie beginnt die Untersuchung mit der Frage, welcher Stand überhaupt läuft.

8:21 Die Werkzeugliste brauchen Sie in dem Moment, in dem ein Build-Werkzeug kompromittiert gemeldet wird: Betrifft uns das? Die Provenance braucht die Verifikation vor dem Deployment. Der Digest jeden Verdacht auf Austausch. Und die SBOM jede neue Schwachstelle — das ist das Thema der nächsten beiden Module. Fünf Nachweise, die im Build automatisch entstehen sollten, nicht auf Zuruf.

8:44 Wir kennen diese Trennung schon aus Modul sieben, dort als Rechtefrage. Hier kommt die zweite Begründung dazu: Sie macht den Moment sichtbar, in dem ein Artefakt die Vertrauensgrenze überschreitet. Vorher ist es ein Zwischenergebnis, danach ist es ein Produkt. Der dritte Punkt ist die härteste Regel dieses Kapitels — ein Artefakt, das nach dem Build noch angefasst wird, entwertet jede Herkunftsaussage.

9:09 Umbenennen, neu packen, Manifest anpassen: Alles, was nach dem Build passiert, steht in keiner Provenance. Und der vierte ist eine Frage, die man vorher klären sollte, nämlich die Aufbewahrungsfrist. Der erste Punkt ist häufig und ärgerlich: Die Provenance entsteht, liegt aber an keinem Ort, an dem ein Konsument sie findet. Damit ist die Arbeit gemacht und der Nutzen null.

9:31 Der zweite ist arithmetisch fast garantiert: Build-Protokolle verfallen nach dreißig Tagen, und eine Untersuchung beginnt selten in der ersten Woche. Der dritte ist die eben besprochene Nachbearbeitung. Und der vierte ist ein Denkfehler beim Aufräumen — die Aufbewahrung endet mit dem nächsten Release, obwohl das alte bei einem Kunden noch produktiv läuft.

9:51 Der Supportzeitraum ist das Maß, nicht die Release-Folge.

Übung

9:55 In der Übung bauen Sie zweimal und legen fest, was ein Build künftig immer mitliefern muss. Diese Liste ist wichtiger, als sie aussieht: Sie ist die Grundlage der Module zu SBOM, Provenance und Signaturen — dort holen wir sie wieder hervor und füllen sie mit konkreten Dateien. Zwei Ergebnisse verlangt diese Aufgabe. Erstens die erklärten Abweichungen zwischen zwei Läufen — erklärt, nicht unbedingt beseitigt.

10:19 Zweitens die Liste der Nachweise mit Aufbewahrungsfrist. Der Hinweis sagt Ihnen, warum die zweite wichtiger ist: Sie wird in Modul neun, zwölf und dreizehn wieder aufgenommen. Schreiben Sie sie deshalb so, dass ein Dritter sie versteht — also nicht „Logs aufheben", sondern welche Datei, wo abgelegt, wie lange, und wer im Zweifel Zugriff hat.

10:40 Der erste Schritt ist die Voraussetzung für alle weiteren: Werkzeug- und Basisversionen festschreiben, statt sie mitwandern zu lassen. Ohne ihn ist der Vergleich in Schritt zwei sinnlos. Dann zweimal bauen und die Digests vergleichen, die Abweichungen auf ihre Ursache zurückführen und mindestens eine beseitigen. Anschließend festlegen, welche Nachweise jeder Build mitliefert. Und zuletzt Aufbewahrungsfrist und Ablageort je Nachweis.

11:06 Die Fußzeile gibt das Maß: Die Frist richtet sich nach dem Supportzeitraum des Produkts, nicht nach dem Platz auf der Ablage. Der erste Punkt ist der Unterschied zwischen Vorsatz und Praxis: Die Nachweise werden festgelegt und nicht automatisch erzeugt — dann entstehen sie beim ersten hektischen Release nicht. Der zweite ist der Ablageort, der verfällt.

11:26 Der dritte ist die Frist nach Speicherplatz statt nach Supportzeitraum; Speicherplatz ist heute das billigste Argument, das man finden kann. Und der vierte ist ein Versuchsaufbaufehler, der die ganze Übung entwertet: Der zweite Build läuft auf einer anderen Maschine mit anderen Werkzeugversionen. Dann vergleichen Sie nicht zwei Läufe, sondern zwei Umgebungen.