Irgendwann steht im Projekt der Satz im Raum: „Für SLSA Stufe 3 brauchen wir bitgleiche Builds.” Danach vergehen Monate mit Zeitstempeln, Pfaden und Sortierreihenfolgen. Das ist wertvolle Arbeit — nur zahlt sie nicht auf die Stufe ein, die man erreichen wollte.
Gefordert ist Isolation, nicht Bitgleichheit
Der SLSA Build Track zielt auf die Echtheit der Herkunftsaussage, nicht auf das Ergebnis. Ab Level 2 dürfen sich Läufe weder zeitlich beeinflussen noch Artefakte teilen. Ab Level 3 muss für jeden Build eine neue Umgebung bereitgestellt werden, und ein Build darf die Umgebung nachfolgender Builds weder verändern noch überdauern. Reproduzierbarkeit taucht in diesen Anforderungen nicht auf.
Isoliert ist nicht hermetisch
Die zweite Annahme ist ebenso verbreitet: Der Build müsse ohne Netzzugriff auskommen. Auch das verlangt Level 3 ausdrücklich nicht — Hermetik ist aus der Anforderung herausgenommen und in künftige Überlegungen verwiesen. Dein Build darf Abhängigkeiten laden. Er muss nur ohne Reste des vorigen Laufs starten, und es darf nicht möglich sein, dass er Cache-Einträge für andere vergiftet.
Wo die Arbeit wirklich liegt
Der unbequeme Teil von Level 3 steht woanders: Das Signaturmaterial gehört aus der Umgebung heraus, in der fremder Code läuft. Und die externen Parameter eines Laufs müssen vollständig aufgezählt sein — auf Level 2 dürfen sie noch lückenhaft sein. Genau daran scheitern Aufstiege, nicht am Zeitstempel im Archiv.
Bitgleiche Builds bleiben ein lohnendes Ziel. Nur ist es ein eigenes, und es gehört eigenständig begründet.
Mehr dazu im Seminar
Wie sich ein Build nachvollziehbar machen lässt — Werkzeugversionen festschreiben, zweimal bauen, Abweichungen auf ihre Ursache zurückführen — zeigt das Modul Reproduzierbare und nachvollziehbare Builds aus dem Seminar DevSecOps und sichere Software-Lieferketten — mit Video und Kapitelübersicht.