Software Supply Chain und Artifact Attestations

Software Supply Chain und Artifact Attestations

0:00 Die Frage vor jedem Deployment lautet: Stammt dieses Artefakt wirklich aus meinem Build — oder nur aus meiner Registry? Das ist ein Unterschied, den man leicht übersieht. Wer in Ihre Registry schreiben darf, kann dort ein Image mit dem richtigen Namen ablegen, und Ihr Deployment würde es anstandslos ausrollen. Genau diese Lücke schließen Artifact Attestations: kryptografisch signierte Aussagen darüber, welcher Workflow aus welchem Commit dieses Artefakt gebaut hat.

0:26 In diesem Modul erzeugen wir solche Nachweise, hängen eine Stückliste daran und machen die Prüfung zur Bedingung für das Ausrollen.

Software Supply Chain und Artifact Attestations

0:35 Viertes Modul des dritten Tages. Erst der Herkunftsnachweis, dann die Stückliste und die Prüfung, zuletzt die Reifegrade und die Frage, wie aus einem Nachweis eine durchgesetzte Regel wird. Am Ende verweigert das Deployment der Beetkarte ein Image ohne gültigen Nachweis — und das ist der Punkt, an dem aus Dokumentation Schutz wird.

Herkunft von Artefakten nachweisen

0:54 Beginnen wir mit dem Nachweis selbst. Was genau wird da signiert — und woher weiß GitHub, dass die Aussage stimmt? Eine Attestation ist eine signierte Aussage über ein Artefakt: welcher Workflow es gebaut hat, aus welchem Repository und welcher Organisation, aus welchem Commit und durch welches Ereignis ausgelöst. Diesen Nachweis der Herkunft nennt man Build Provenance.

1:17 Das Bemerkenswerte daran ist, wer die Aussage machen kann: nur der Build selbst, während er läuft — über dasselbe OIDC-Verfahren, das wir im letzten Modul für die Cloud-Anmeldung genutzt haben. Niemand kann eine solche Aussage nachträglich für ein Artefakt erfinden, das er nicht gebaut hat. Zwei Rechte und ein Schritt — mehr ist es nicht.

1:37 Das Recht für das OIDC-Token brauchen wir, weil der Nachweis über dieses Verfahren signiert wird; das Recht für Attestationen, um ihn zu hinterlegen. Und jetzt das Wichtigste: Der Nachweis bezieht sich auf den Digest, nicht auf den Tag. Deshalb brauchten wir in Modul acht die Ausgabe des Push-Schritts. Das hat eine schöne Konsequenz — verschiebt später jemand den Tag, bleibt der Nachweis für das ursprüngliche Image gültig, und das untergeschobene Image hat schlicht keinen.

2:05 Diese Einordnung ist mir wichtig, weil hier oft zu viel versprochen wird. Der Nachweis belegt die Herkunft — er sagt nichts über die Qualität des Inhalts. Ein Build mit fehlerhaftem oder bösartigem Code erzeugt eine völlig gültige Attestation. Was er leistet: Ein untergeschobenes Artefakt fällt auf, weil ihm der Nachweis fehlt.

2:24 Und was er wert ist, hängt daran, wie gut der Workflow abgesichert ist, der ihn ausstellt. Genau deshalb kam Modul dreizehn vorher — ein kompromittierter Workflow stellt ordnungsgemäße Nachweise für kompromittierte Artefakte aus. Der erste Punkt ist ein Reihenfolgefehler mit stiller Wirkung: Wird der Nachweis vor dem Push erzeugt, bezieht er sich womöglich auf einen anderen Digest, und die spätere Prüfung schlägt fehl — oder schlimmer, sie prüft etwas anderes.

2:52 Der zweite ist der häufigste überhaupt: Nachweise werden erzeugt und nie geprüft. Dann haben Sie Dokumentation, keinen Schutz. Der dritte beschreibt genau die Lücke, um die es hier geht. Und der vierte ist ärgerlich, weil er spät auffällt — die fehlenden Rechte bemerken Sie erst am Ende eines langen Builds.

SBOM und Verifikation

3:10 Jetzt der zweite Teil: die Stückliste — und vor allem die Prüfung, ohne die der ganze Aufwand nur Papier ist. Eine Software Bill of Materials ist die Zutatenliste Ihres Artefakts: welche Bibliotheken in welcher Version darin stecken. Als eigene Attestation gebunden, reist sie zusammen mit dem Herkunftsnachweis am Artefakt mit.

3:29 Der Nutzen zeigt sich am Tag, an dem eine Schwachstelle in einer verbreiteten Bibliothek bekannt wird: Statt in fünfzig Repositories zu suchen, fragen Sie die Stücklisten ab. Geprüft wird beides mit der GitHub-Kommandozeile — und das ist ein gewöhnlicher Befehl, den Sie in jeden Workflow einbauen können. Zwei Befehle, einer für eine Datei, einer für ein Image aus der Registry. Beide nennen ausdrücklich das Repository, gegen das geprüft wird — und das ist der entscheidende Teil.

3:58 Ohne diese Angabe würden Sie nur prüfen, ob irgendein gültiger Nachweis existiert; mit ihr prüfen Sie, ob er von Ihnen stammt. Und der Hinweis in der Fußzeile ist der Kern des Moduls: Schlägt die Prüfung fehl, endet der Befehl mit einem Fehler. In einem Deployment-Job bedeutet das: Der Lauf hält an, und nichts wird ausgerollt.

4:18 Vier Punkte, und der erste ist der praktische Nutzen im Ernstfall — die Frage nach den betroffenen Ständen ist ohne Suche beantwortbar. Der zweite ist technisch: Die Prüfung lässt sich auf einen bestimmten Nachweistyp einschränken, also gezielt auf die Stückliste. Der dritte ist eine Frage des Zeitpunkts und wichtiger, als er klingt: Die Stückliste entsteht beim Build, wo die tatsächlich verwendeten Stände bekannt sind.

4:42 Nachträglich erstellt beschreibt sie einen Wunschzustand. Und der vierte nennt die technische Grundlage, die GitHub für Signatur und Nachvollziehbarkeit verwendet. Der erste Punkt ist der Zeitpunktfehler von eben. Der zweite ist die stille Entwertung, die man in echten Projekten leider oft findet: Die Prüfung läuft mit dem Schalter, der Fehler durchgehen lässt — dann steht sie da und hält nichts auf.

5:05 Der dritte ist subtil und deshalb gefährlich: Wird gegen das falsche Repository geprüft, kann der Befehl formal erfolgreich sein, ohne die Frage zu beantworten, die Sie stellen wollten. Und der vierte ist organisatorisch: Eine Stückliste, die im Vorfall niemand abfragt, war die Mühe nicht wert.

SLSA-Level und Deployment Policies

5:22 Zum Schluss die Einordnung. Es gibt einen anerkannten Rahmen für die Reifegrade solcher Absicherung — und eine konkrete Antwort, wie man das nächste Level erreicht. SLSA beschreibt Stufen für die Absicherung von Bauprozessen. GitHub ordnet einfache Artifact Attestations dem Build Level 2 zu — das bekommen Sie also mit dem Schritt, den wir eben gesehen haben.

5:43 Level 3 verlangt mehr: die Trennung von Bauvorgang und aufrufendem Workflow. Genau das leistet ein geteilter, abgesicherter wiederverwendbarer Workflow, wie wir ihn in Modul neun gebaut haben. Damit schließt sich ein Kreis — die Wiederverwendung war nicht nur eine Frage der Pflege, sie hat auch eine Sicherheitsdimension.

6:03 Die Kette zeigt den Weg vom Erzeugen zum Durchsetzen, und der dritte Kasten ist der, den die meisten Projekte auslassen. Ohne ihn haben Sie eine gut dokumentierte Lieferkette, die niemanden aufhält. Mit ihm wird die Herkunft zur Voraussetzung: Was nicht aus dem erwarteten Workflow stammt, wird nicht ausgerollt. Beachten Sie außerdem die Reihenfolge — die Prüfung sitzt vor der Freigabe, nicht danach.

6:25 Ein Mensch soll nicht über ein Artefakt entscheiden müssen, dessen Herkunft die Maschine noch gar nicht bestätigt hat. Vier Punkte zum Scharfschalten. Der Deployment-Job prüft vor dem Ausrollen und bricht ab, wenn der Nachweis fehlt — das ist die Grundregel. Aber prüfen Sie richtig: gegen Repository und erwarteten Workflow, nicht nur auf Vorhandensein irgendeines Nachweises.

6:48 Ein zentraler, abgesicherter Build-Workflow macht diese Aussage über alle Teams hinweg gleich belastbar. Und der letzte Punkt bleibt wichtig, damit die Erwartungen stimmen: Signaturen beantworten die Herkunftsfrage, nicht die Frage nach der Qualität des Inhalts. Der erste Punkt ist die halbe Prüfung, die wir eben besprochen haben — sie fühlt sich sicher an und ist es nicht.

7:10 Der zweite ist eine Selbstüberschätzung, die in Audits auffällt: Level 3 lässt sich nicht beanspruchen, wenn jedes Team seinen Build selbst zusammenstellt. Der dritte ist eine typische Lücke im Ablauf — die Regel gilt für Produktion, aber der Weg über Staging bleibt offen, und über den kommt man erfahrungsgemäß auch irgendwohin.

7:28 Und der vierte ist der menschliche: Ein Notfall-Deployment umgeht die Prüfung, und aus der Ausnahme wird die Praxis.

Übung

7:35 In der Übung erzeugen Sie Nachweis und Stückliste — und weisen nach, dass ein Image ohne Nachweis tatsächlich nicht ausgerollt wird. Der zweite Teil ist der eigentliche: der Gegenbeweis. Ein Image mit dem richtigen Namen von Hand in die Registry zu schieben, dauert eine Minute — und ist genau das Szenario, gegen das wir uns absichern.

7:55 Wenn Ihr Deployment dieses Image ausrollt, obwohl alle Nachweise eingerichtet sind, wissen Sie, dass die Prüfung an der falschen Stelle sitzt oder zu großzügig gefasst ist. Ohne diesen Test bleibt die Absicherung eine Vermutung. Und denken Sie daran, das Testimage danach wieder zu entfernen. Die Schritte eins bis drei bauen die Nachweise auf, Schritt vier setzt die Prüfung an die richtige Stelle: vor dem Ausrollen.

8:19 Achten Sie dabei auf die Reihenfolge im Workflow — nach dem Push, vor dem Deployment. Und Schritt fünf ist der Gegenbeweis. Ich lege Ihnen ans Herz, diesen letzten Schritt wirklich zu machen, auch wenn die Zeit knapp wird. Er ist der einzige Teil der Übung, der Ihnen sagt, ob das Gebaute funktioniert. Der erste Punkt ist der häufigste technische Fehler: Geprüft wird der Tag statt des Digests, und damit passt der Nachweis nicht mehr — oder er passt zufällig noch, was nicht besser ist.

8:47 Der zweite ist ein Reihenfolgefehler, der die Prüfung sinnlos macht. Der dritte ist die ausgelassene Kontrolle. Und der vierte ist der Aufräumpunkt, den man nach jeder solchen Übung braucht: Das eingeschleuste Testimage gehört gelöscht, sonst liegt in Ihrer Registry ein Artefakt unklarer Herkunft — ausgerechnet nach dem Modul über Lieferkettensicherheit.